On 6/28/2010 9:52 AM, Marshall Schor wrote: > The Apache common top-level pom ( > http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) has a > profile activated when doing "releases", which invokes the > maven-assembly-plugin to build the source-release.zip artifact. > I meant to include that Apache source releases are supposed to have what is needed to build the artifact from sources. > For single module (non-aggregate projects) this seems fine. > > For multi-module (aggregator-pom) projects, I think this only builds the > source-release for the aggregator project by itself, unless the maven Sorry for the bad English caused by cut/paste - should say "unless the maven convention of ... is followed" > convention of having the directory layout have the aggregator pom in a > directory which contains all the sub-projects. > > In our case, we have a "flat" hierarchy (actually, not exactly - we > collect various "parent-poms" into one directory). > > My first attempt to alter our release -build process was to include in > the maven-assembly-plugin descriptor a <moduleSets> section, to use the > information in the aggregator <modules> element to locate and include > all the subprojects. This kind of worked, but not quite, because it > imposed a particular directory layout on the result, which didn't > exactly match the SVN and working copy directory layout. (This was > because I had put all of our parent-poms under one additional directory, > just to keep things nicely "organized" ... ) > > After thinking more about this, it seems that the source-release.zip > package should include just exactly what is in the SVN, starting with a > directory there which is common among all the parts (the aggregating > pom, and all of the projects being aggregated), but filtered to exclude > all those things not in the set of artifacts being released. > > For example, in this layout (SVN and working copy): > > some-top-lvl-common-dir > | > +- aggregate-project > | | > | +- aggregate-pom.xml > +- parent-poms > | | > | +- parent1-project > | | | > | | +- parent1.xml > | +- parent2-project > | | | > | | +- parent2.xml > +- some-non-released-thing > > the some-non-released-thing would be filtered, since it wasn't a module > or the aggregate project. > > Does this sound like the right way to package source-releases for > arbitrary layout SVN multi-module Apache projects? > > If so, is there a plugin which does this? >
(In this note, filtering just means including or excluding subtrees of files, not running the maven filtering software). I think the release plugin put in already the code to discover a common parent directory, as described above. (I don't think it has "filtering" code though). And the release process is already checking out into the target/checkout directory the SVN directory - so before it does any changes beyond the fresh checkout, could it build the source-release.zip from the (filtered) version of what's there? -Marshall > -Marshall Schor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
