On 16/09/2011, at 9:26 PM, Luke Daley wrote: > > 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.
Options 2 and 3 are really about grouping the artifacts in different ways. Option 2 groups artifacts by type: jar, war, signature, javadoc, etc. Option 3 groups artifacts by their meaning, or purpose. At the moment, we only have one such grouping: the artifacts I need to construct a Java runtime classpath. However, we want to add more, such as, java compile-time classpath, C/C++ compile-time, link-time and runtime groupings. Or when we get further along, groupings such as client side runtime and server side deployment artifacts. The groupings we use in a publication are there for the consumer of the publication. Grouping by type does not communicate anything to the consumer. In general, you don't use all the artifacts of a given type for every purpose. Sometimes you do, but not always. It is the same with dependencies. For example, say we have a project which publishes an api and impl jar. The project needs some way to declare: a consumer should use the api jar plus dependency 'a' to compile against me, and should use the api and impl jars plus dependencies 'a', 'b' and 'c' at runtime. Grouping by type doesn't solve this problem, and the consumer has to use some other mechanism to decide which artifacts it needs at compile time vs run-time. Grouping by purpose solves this problem quite nicely. Grouping by type is the approach that got us into the situation in the first place. All option 2 does is make the groupings more fine-grained, but doesn't tackle the basic problem: Consumers are interested in the meaning or purpose of an artifact, not what type an artifact has (of course, type implies a certain set of possible purposes an artifact might have). Thinking about it, I can't really see a reason for grouping by type from the producer's point of view, either. You could make a case that sometimes you might want to publish just the jars and not the wars of a project. Which is probably true. However, grouping by type doesn't really work here, either, because some artifacts are cross cutting: such as the documentation or source for an artifact, or the signatures for an artifact. That is, when I publish just my Jars, I want the source archive and signatures uploaded as well. I need to shuffle things around so that I have some additional grouping that includes the Jars, source archive, and the signatures for those artifacts (and only those artifacts). That is, you need a grouping by purpose (to publish some meaningful subset of artifacts). So, I think we want to tackle option 3, and ditch option 2. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
