There definitely should be support for both options.

This may just be bias from the environment I'm used to, but the act of
applying the WAR plugin signals to me that the primary use of a project is
as a WAR.  While it is useful to use that same code in other contexts
(namely the JAR context), that doesn't seem like it should be the default.

But, if there ends up being support as you described, that may render my
point moot.

Andrew Oberstar


On Fri, Jan 6, 2012 at 4:02 PM, Spencer Allain <spencer_all...@yahoo.com>wrote:

> Replacing the jar from the runtime messes up scenarios where the jar is
> depended upon by other wars/jars.   A more optimal solution is to put wars
> (and jars when applying a new ejb-jar plugin) into a new configuration
> (ear-components or some other name) that is automatically picked up by an
> ear depending upon it.
>
> :-(  Unfortunately, I've been unable to devote any time to implementing
> such a solution over the past month and a half.  I'm hoping that changes in
> a couple of weeks, but no promises.
>
> -Spencer
>
>   ------------------------------
> *From:* "andrew.obers...@securian.com" <andrew.obers...@securian.com>
> *To:* user@gradle.codehaus.org
> *Sent:* Friday, January 6, 2012 2:03 PM
> *Subject:* Re: [gradle-user] Re: Can't access war artifact from
> dependencies in 1.0?
>
> Personally, it seems that applying the WAR plugin should put the WAR
> artifact in the runtime configuration (replacing the JAR).  Since we are
> wrapping all of the Gradle plugins for other reasons, we have the following
> workaround in place.  Another hack approach, but this allows us to use
> simple project dependencies and get the intended effect.
>
> project.configurations.each { Configuration configuration ->
>         def jarArtifact = configuration.artifacts.find {
>                 it.file == jar.archivePath
>         }
>         if (jarArtifact != null) {
>                 configuration.artifacts.remove(jarArtifact)
>                 project.artifacts.add(configuration.name, task)
>         }
> }
>
> Here's the link to the issue Bryan references: *
> http://issues.gradle.org/browse/GRADLE-1912*<http://issues.gradle.org/browse/GRADLE-1912>
>
> Andrew Oberstar
>
>
>
> From:        bryan <brya...@gmail.com>
> To:        user@gradle.codehaus.org
> Date:        01/06/2012 12:52 PM
> Subject:        [gradle-user] Re: Can't access war artifact from
> dependencies in 1.0?
> ------------------------------
>
>
>
> FWIW, the solution above isn't entirely complete. I also wanted to package
> the transitive dependencies for the war that were not embedded in the war
> itself. Thus in addition to above, I also specified:
>
> compile project(":mywar")
>
> ...and in mywar's build.grade I set jar.enabled=false. Kind of a hack but
> gets the job done until GRADLE-1912 is fixed.
>
> --
> View this message in context:
> http://gradle.1045684.n5.nabble.com/Can-t-access-war-artifact-from-dependencies-in-1-0-tp5124737p5126375.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
>
>

Reply via email to