Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"dist" command should package all jars #535

Closed
wants to merge 1 commit into from
Closed

"dist" command should package all jars #535

wants to merge 1 commit into from

Conversation

deansher
Copy link

This pull request addresses lighthouse ticket #851:

Play's current "dist" implementation takes its input from the packageBin task, which is defined as "produces a main artifact, such as a binary jar," and which only returns a single File. This is sometimes insufficient. For example, it does not work if a Play project wants to publish a separate jar with convenience functionality for its clients, while also consuming that separate jar itself at runtime.

I believe a better approach is for the "dist" command to take its input from the packagedArtifacts task, which is defined as "packages all artifacts for publishing and maps the Artifact definition to the generated file" and returns a Map[Artifact,File].

I have discussed this with Guillaume.

…the packagedArtifacts task, instead of just the packageBin artifact.
@jroper
Copy link
Member

jroper commented Nov 13, 2012

Could you sign our CLA?

http://www.typesafe.com/contribute/cla

@deansher
Copy link
Author

Done.

@jroper
Copy link
Member

jroper commented Nov 13, 2012

Looks good to me. Great to see that you implemented tests for it :)

@guillaumebort
Copy link
Contributor

Good for me too. It's great to have tests on this.

@pk11
Copy link
Contributor

pk11 commented Nov 13, 2012

@deansher could you please send a new pull request which could be cleanly merged? Thanks

@deansher
Copy link
Author

Done: #538

From: Peter Hausel notifications@github.com
Reply-To: playframework/Play20
<reply+i-8295858-f65618eb7aa3fab0ca875cb882192a499f710902-237535@reply.githu
b.com>
Date: Tuesday, November 13, 2012 5:30 AM
To: playframework/Play20 Play20@noreply.github.com
Cc: Dean Thompson deansherthompson@gmail.com
Subject: Re: [Play20] "dist" command should package all jars (#535)

@deansher https://github.com/deansher could you please send a new pull
request which could be cleanly merged? Thanks


Reply to this email directly or view it on GitHub
#535 (comment) .

@pk11 pk11 closed this Nov 13, 2012
@denouche
Copy link

There is a problem with this new implementation :

In play 2.0.4, when I wanted to publish the zip file containing all the jars, I just had to add the following setting to my build.scala :
.settings(addArtifact(Artifact (appName, "dist", "zip"), dist).settings: _*)

"I believe a better approach is for the "dist" command to take its input from the packagedArtifacts"

So now the dist command is calling the playPackageEverything command which try to build all the artifacts (including my dist zip) -> ERROR :

[error] java.lang.AssertionError: assertion failed: Internal task engine error: nothing running. This usually indicates a cycle in tasks.
[error] Calling tasks (internal task engine state):

@see my post on the google group :
https://groups.google.com/forum/#!topic/play-framework/BoWw65F6vg8

So how to publish the zip file ?

I'm using play 2.1-RC2 java.
Thank you for your help.

@guillaumebort
Copy link
Contributor

Yeah there is a cycle here. But I don't see how to avoid it.

For me the zip file itself is not an project artifact. Where do you want to publish it?

@denouche
Copy link

I want to publish it on a nexus repo

@guillaumebort
Copy link
Contributor

Why the zip file, and not the project jar itself along with the ivy or pom file describing the jar dependencies?

@denouche
Copy link

I would like to use the standalone application on my production server. Don't want to install play on this server.
Can I achieve this using the project jar ?

@denouche
Copy link

Moreover, adding the code :

docs: Seq[File] <- taskInAllDependencies(packageDoc in Compile)

will bypass the setting :

.settings(
publishArtifact in (Compile, packageDoc) := false
)

This is very annoying because I encounter a problem during documentation generation

(compile:doc) Scaladoc generation failed

which prevent me to use the 'dist' command.

@guillaumebort
Copy link
Contributor

Yes, with either Ivy, Maven or sbt on the server, you can fetch the project artifact along with its dependencies. The zip file is nothing but a file containing all the jars files.

Now you can always use the zip file, but it's difficult to let sbt publish it to a Maven repository automatically for you. You can push it yourself using an HTTP request, SSH or whatever you want.

Just write a deploy task that depends of dist and then get the generated zip file and push it somewhere.

@denouche
Copy link

Ok I will try this. Thank you.
What about the
docs: Seq[File] <- taskInAllDependencies(packageDoc in Compile)
How to disable the doc generation during dist task ?

@guillaumebort
Copy link
Contributor

Well you can also override the task definition in your Build file, and back to the previous implementation. Something like:

playPackageEverything <<= (state, thisProjectRef, crossTarget) flatMap { (s, r, crossTarget) =>     
   inAllDependencies(r, (packageBin in Compile).task, Project structure s).join     
}

@denouche
Copy link

It's working.
So this way I can avoid the documentation generation, and create my standalone zip.
I do not like overriding the default implementation, but this is the simplest way to resolve my problem.
Thank you so much for your help.

@david-grandes
Copy link

Hello, we are struggling with the same problem as described here. We posted a question on stackoverflow. If you would be so kind as to help us with an answer for the community, and us, that would be great!

http://stackoverflow.com/questions/17473088/play-2-1-sbt-publish-a-dist-cycle-in-tasks-error

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants