On 15/09/2011, at 10:07 PM, Adam Murdoch wrote:
> So, if we work around the problem for the war plugin, we still have exactly
> the same problem in the ear plugin, and the c++ plugin, and when you publish
> a source jar and javadoc jars (and the signing plugin, to some extent).
>
> There are some simple solutions to this problem, I think:
>
> Option 1: artifact type filtering
> * Change configurations so that they support filtering on an artifact's type
> when resolving.
> * Change the various compile and runtime configurations to accept artifacts
> of type 'jar'.
> * Change the war and ear plugins so that they do not disable and remove the
> jar.
> * Probably change the signing plugin so that it add the signatures to '*' (ie
> signatures are cross-cutting).
>
> Option 2: bust up archives configuration
> * Add 'jars', 'sources', 'javadocs', 'wars', 'ears', etc configurations.
> * Change the 'runtime' configuration to extend from 'jars' instead of
> 'archives'.
> * Add a 'publications' configuration which extends 'jars', 'sources',
> 'javadocs', 'wars', 'ears', 'signatures', etc.
> * Change the java plugin to add the jar to the 'jars' configuration.
> * Change the war plugin to add the war to the 'wars' configuration.
> * Change the ear plugin to add the ear to the 'ears' configuration.
> * Change the war and ear plugins so that they do not disable and remove the
> jar.
>
> User runs 'gradle uploadPublications' instead of 'gradle uploadArchives'. We
> might keep the 'archives' configuration, have it extend from 'publications',
> and deprecate 'archives' and 'uploadArchives'.
>
> Option 3: artifacts in multiple configurations
> * Change the ArtifactHandler so that it adds artifacts of type 'jar' to both
> the 'archives' and 'runtime' configurations.
> * Change the 'default' configuration so that it no longer extends from
> 'archives'.
> * Change the war and ear plugins so that they do not disable and remove the
> jar.
>
> We could potentially combine both options 2 and 3. For me, option 3 is the
> way to go, followed at some point by option 2. Later, we will need option 1,
> for more sophisticated resolution (eg for fixing how we treat transitive
> dependencies, and for dealing with native variants).
I think the ideal solution is 2 with some extra work.
* Rework the java plugin so it does not create a jar, but adds the tools for
java projects in general
* Add a “jars” plugin that provides a dsl for configuring jars to be built
(applies “java” plugin)
* Add a “jar” plugin that applies “jars” and preconfigures to create one jar.
* Follow this same pattern for the current war and ear plugins (e.g. “wars”
plugin adds the capability, “war” plugin preconfigures a single war).
* Add a model element for each kind of thing in a container (e.g. jars.main,
wars.main)
* Add a top level element that is a synonym for jars.main (e.g. jar {} ==
jars.main {})
* Expose the configurations used by each thing through that element (e.g.
jars.main.dependencies.runtime instanceof Configuration)
* Allow assignment of configurations (e.g. jars.main.dependencies.runtime =
configurations.someConfiguration)
* Expose the publication for wiring into other configurations via some
interface that Configuration knows about that is implemented by the model
objects (i.e. jar, war, ear)
war {
dependencies {
compile jars.main
}
}
I think that should still give us the flexibility to dig into the jar model and
do things like just use the class files when compiling instead of using the jar
I think.
But, that's probably too much to achieve pre 1.0 and it's breaking as applying
the java plugin would no longer get you a jar. I would love to get this done
before 1.0 though as we are going to have to make this breaking change at some
point so this is my preference.
But if we agree that's not possible to get done in time (or not desirable)…
Instead of 3 I think we should at least add the model elements for things
produced during the build and use them for wiring project dependencies instead
of configurations (like my last “point” above).
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
