gmane.comp.lang.scala.simple-build-tool

Re: package task with arguments to create a file

Matthieu Taggiasco — 2013-05-22T18:32:46

Hi,

I finally managed to create the Input Task.

But I don't really get how to depend on "mappings in (packageBin,Compile)". 
For the moment, my Input Task is defined with an InputKey[Unit]. Should it 
be something else ?
How do I write the dependency ?

Thanks !!
Matt



Le lundi 20 mai 2013 15:11:43 UTC+2, Fluffy a écrit :

[ANN] sbt-platform-executing-plugin 0.4.0

Stephen Compall — 2013-05-22T13:11:21

This plugin simplifies the process of writing an sbt build that captures
native binaries for later use with platform-executing, a Scala library
for dealing with native binary executables.

The plugin is described at
<http://nocandysw.com/sbt-platform-executing-plugin>.

The description of the library may be helpful
<http://nocandysw.com/platform-executing>, as might the sample project
using the plugin
<https://bazaar.launchpad.net/~scompall/platform-executing/phantomjs/files>.

I made it because packaging such things is sometimes useful; hopefully
it will be useful for others.  Any feedback is appreciated, especially
with regard to the sbt settings, which just sort of grew onto it.

Greetings,

Re: Is it possible to re-launch and test xsbti.AppMain derived application from sbt?

Radzislaw Galler — 2013-05-22T08:02:43

Thanks for the hint. Tried to look into the activator code, but couldn't 
find it. Looks like Typesafe didn't publish it. Could you point me where to 
look for an example/docs of forking?
Or maybe a little snippet paste here?

Thanks,


On Tuesday, May 21, 2013 10:40:53 PM UTC+2, Fluffy wrote:

Re: Re: Using relative file paths in sub module of multi module project

2013-05-22T00:46:23

[Sbt is not forking to run your tests, although you could do so and it 
would most likely fix your immediate issue.]  

I've tried this using 

fork in Test := true,
baseDirectory in Test := file("correct subdirectory")  //This shouldn't 
even be needed because my subproject defines the base directory

At the console I check test:base-directory and get the correct value and 
test:fork and get the correct value.  

However, when I run my tests, which specify test configuration files using 
relative paths (e.g. "./conf/config.file), the files are not found.  

Further, I've added 

println(new File(".").getCanonicalPath())

to one of test fixtures just to see what's up and it returns the 
(incorrect) parent folder instead of the subdirectory which holds my 
subproject.

Any help would be appreciated.

On Tuesday, May 21, 2013 7:32:47 AM UTC-4, Fluffy wrote:

Re: Re: sbt-pgp should be part of sbt 0.13

Josh Suereth — 2013-05-21T20:42:11

Yeah, I think not.  The key issue is specifically in how sbt plugins hook
into (a) sbt projects (b) other sbt plugins.   It's less about how to
specify them as dependencies and more about how to *use* them as
dependencies.


On Mon, May 20, 2013 at 10:56 PM, nafg <naftoligug< at >gmail.com> wrote:

Re: Is it possible to re-launch and test xsbti.AppMain derived application from sbt?

Josh Suereth — 2013-05-21T20:40:53

When testing the typesafe-activator project, we actually just fork new
applications to test the launcher (using new sbt.boot.directory).   I'd
actually recommend going that approach, as it'll be more robust for you in
the long term.

If you reboot (via the launcher) into another application, you'd need to
have that application reboot back into SBT which means it would have to
reload and fill new classloaders with classfiles.  Not really a great user
experience.  Forking is probably safer, faster and easier to work with.


On Tue, May 21, 2013 at 3:23 AM, Radzislaw Galler <gradzislaw< at >gmail.com>wrote:

Re: Re: SFTP and transitive dependencies

Josh Suereth — 2013-05-21T20:39:06

I haven't seen anything reported against Ivy itself.  Why don't you check
sbt's issues and open a ticket if no one else has.


On Tue, May 21, 2013 at 5:20 AM, Peter Robinett <peter.robinett< at >gmail.com>wrote:

Re: [sbteclipse] getting sbteclipse to add source-managed in the source paths of the generated project

Patrick Mahoney — 2013-05-21T13:59:42

I am also generating some code, and would appreciate the addition of
sourceManaged to the source paths. +1.




On 21 May 2013 06:53, Viktor Hedefalk <hedefalk< at >gmail.com> wrote:

Re: Re: Using relative file paths in sub module of multi module project

Josh Suereth — 2013-05-21T11:32:47

So.  I believe using relative paths is always a danger, as I don't think
you can change current working directory in java.

Sbt is not forking to run your tests, although you could do so and it would
most likely fix your immediate issue.

Another possibility is to try to use the classsloader to pull in resources
instead of file paths.

Hope that helps!
On May 20, 2013 9:53 PM, <ericdreichert< at >gmail.com> wrote:

Re: SFTP and transitive dependencies

Peter Robinett — 2013-05-21T09:20:05

Hello all,

I'm having the example same issue that Andreas mentioned a year ago, where 
my dependency is fetched from my SFTP repository but its dependencies are 
not. Am I missing something or is this a known issue? I'd prefer to use 
SFTP, though switching to HTTP is a possibility if that will resolve the 
problem.

Thank you,
Peter Robinett

On Thursday, May 24, 2012 11:28:33 AM UTC+2, Andreas Kübler wrote:

Re: [sbteclipse] getting sbteclipse to add source-managed in the source paths of the generated project

Viktor Hedefalk — 2013-05-21T10:53:09

Did any of this ever get in there? Would be nice!

I'm using scalaxb to generate some code and definitely think that the 
suggested change in default makes sense. I mean - without Managed my 
eclipse project doesn't compile. Had to google to find this thread and I 
feel like I'm having a simultaneous case of amnesia and déjà vu - I think I 
have forgotten this before :)

Thanks,
Viktor

On Tuesday, March 6, 2012 7:44:03 AM UTC+1, Heiko Seeberger wrote:

Is it possible to re-launch and test xsbti.AppMain derived application from sbt?

Radzislaw Galler — 2013-05-21T07:23:35


Hi,

I've posted this question originally to StackOverflow<http://stackoverflow.com/q/16645931/29576>, 
but this group seems to be better suited for that.

I'm developing an sbt launched application<http://www.scala-sbt.org/release/docs/Detailed-Topics/Launcher.html#creating-a-launched-application> with 
custom command line interface<http://www.scala-sbt.org/release/docs/Extending/Command-Line-Applications.html>. 
The problem is that every time I want to test it I have to remove the 
previously published boot directory and then recompile and publish locally 
the artefacts, and then finally run the app and test it manually. Part of 
this is accomplished by running external shell scripts.

How could I make sbt doing the job for me? I've already made the skeleton 
command for it:

  lazy val root = Project(
    id       = "app",
    base     = file("."),
    settings = buildSettings ++ Seq( resolvers := rtResolvers,
      libraryDependencies ++= libs,
      scalacOptions  ++= Seq("-encoding", "UTF-8", "-depre

Re: sbt-pgp should be part of sbt 0.13

nafg — 2013-05-21T02:56:47

I haven't followed this discussion too closely, just wondering if it should 
inform the design of adept at all.

Re: Using relative file paths in sub module of multi module project

2013-05-21T01:53:16

Sebastian:

Did you figure this out?  I'm having the same problem.

On Wednesday, October 3, 2012 5:32:34 PM UTC-4, Sebastian wrote:

Re: Re: problem upgrading to scala 2.10

Russ P. — 2013-05-20T19:39:58

Yeah, that was it. Thanks.

On Sunday, May 19, 2013 12:50:08 AM UTC-7, Eugene Vigdorchik wrote:

Re: package task with arguments to create a file

Matthieu Taggiasco — 2013-05-20T19:21:50

Hi,

Thanks for both answers. I'll have a look at the links you provided. 
However that's not just the name of the jar file I want to rename. I need 
to create a ressource file in the jar.
Then I'll have a look on the suggestion of the dependency on the mappings, 
even if I'm not sure yet to understand what it really means. 

I'll put some info as soon as I get something working or almost working. 
Matt



Le lundi 20 mai 2013 15:11:43 UTC+2, Fluffy a écrit :

Re: Re: sbt-pgp should be part of sbt 0.13

eugene yokota — 2013-05-20T18:24:54

Is plugin system such pain point?
For the most part, I think it's doing a good job of providing popular
features like pgp signing
and IDE integration without blocking on sbt dev cycle.
And allowing advanced users to customize or experiment with build
environment.

In addition to "add, minimally configure, WORK," the ability to fix
problems when it happens could make or break the user experience
(e.g. dynamic vs static typing). Often it's to do with the gap in the
mental model of what the user thinks build is doing vs what sbt implements.
Here's an example.

A user recently open an issue on sbt-assembly saying he can't disable the
test during assembly.
He created a repro project, which had:

  ....


test in assembly := {}

assemblySettings


I thought this was interesting because to as a plugin author, it's
self-evident that assemblySetting needs to come before rewiring "test in
assembly" because I read between the lines, and imagine some m**adic
context passed around. To the users, it's innocent mutable var

Re: Re: sbt-pgp should be part of sbt 0.13

Josh Suereth — 2013-05-20T17:09:29

Yeah.   that's why I personally feel the "uber-key-plugin" may be a red
herring here.  The focus should be on what do users want from plugins.
 (add, minimally configure, WORK), and what plugin authors need (this has
some ??? here) and then use that to decide what SBT provides.

Like I said, I think the PGP issue is the tip of the iceberg we've all
planted our flags on and called "iceland".   I'm pretty sure the iceberg is
melting and our users are sinking their ships against it.


On Mon, May 20, 2013 at 1:00 PM, Doug Tangren <d.tangren< at >gmail.com> wrote:

Re: Re: sbt-pgp should be part of sbt 0.13

Doug Tangren — 2013-05-20T17:00:03

I'd be a little worried about a key library and friction  that would arise
for the maintenance of granting access and administration. It's really cool
that someone can just roll up their sleeves, writing a plugin to solve a
problem, push it out there, and having others use it with just the *little*
amount of friction it is to post to sonatype. Adding more friction can
cause a rash. I guess the flip side of that is that user's need to be
strapped with more knowledge of what can and may happen when they install a
plugin.

Re: sbt-pgp should be part of sbt 0.13

Josh Suereth — 2013-05-20T16:55:36

This may be true.   However, I firmly disagree on the plugin aspect
specifically.   I've been doing a good bit of research, especially given
the conflation of Play plugins into the mix of sbt plugins.   Basically, I
have not seen plugins done 'well' in any scenario, however there is a level
of 'adequate' that I think we can attain.

As much as we can solve plugin issues on the plugin author side of things,
so users only need to declare them, would be ideal.   However, this means
we need SBT to provide the right hooks that plugin authors can *anticipate*
problems that their own users may encounter when mixing plugins.
All-in-all, it's a teneous fiber that connects us all, and I think there's
still room in the world for a better system.  I just don't know what that
would be.


When it comes to other areas where sbt deviates and would not need to,
perhaps we're in agreement that less of that is better.   The key line
being "When does an existing solution show enough pain points that you
should try to improve th

Re: sbt-pgp should be part of sbt 0.13

Paul Phillips — 2013-05-20T16:36:05


At the tree branch level I don't have any viable suggestions. My
observation, and I didn't mean it as criticism so much as a general
acknowledgement, is that it often seems as if we do little but reimplement
existing mechanisms in slightly variant contexts. And sbt does seem, to me
at least, to be especially prone to this.