Brian Fox wrote:
On Mon, May 18, 2009 at 8:57 AM, Ate Douma <a...@douma.nu> wrote:
Brian Fox wrote:
It's been a little slow going, but here's an update of where I'm at:
I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and
renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been
added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor
bundle[2]
to be used for the asf source releases. Initially this is a copy of the
default project.xml with the bz2 removed. Having it separate will give us
more flexibility to make updates w/o having to re-release the plugin.
The configuration for making a bundle with this setup currently looks like
this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-4-SNAPSHOT</version>
<executions>
<execution>
<goals>
<goal>single</goal>
</goals>
<phase>validate</phase>
<configuration>
<runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
<descriptorRefs>
<descriptorRef>
source-release
</descriptorRef>
</descriptorRefs>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache</groupId>
<artifactId>apache-source-release-assembly-descriptor</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</plugin>
Once I test and work out any kinks, this will be added to the maven pom
and
released.
There is one bug that David Jenks found in the beta-3 code that needs to
be
addressed since it affects the bundle content (MASSEMBLY-405). I hope to
have the bug fixed and assembly staged by tuesday, followed by the
descriptor bundle and then the maven/shared/plugin/etc parents later this
week.
Hi Brian,
I just created issue MASSEMBLY-409 which describes two other problems we
encountered by using the "project" assembly for our recent Apache Portals
releases.
It would be great if you can take that issue and the recommended
fixes/solutions into consideration for the next release too:
http://jira.codehaus.org/browse/MASSEMBLY-409
I don't see those as being problems with the approach I'm taking. The asf
descriptor will be separate from the plugin so we can tweak it as needed,
and projects can introduce their own descriptors instead of the default if
they want.
Well, yes. But with the current restrictions (no configuration overrides) it might result in a lot (most) ASF projects needing to provide
their own which makes the whole point of this "project" descriptor a bit useless IMO.
The current descriptor produces tar.gz and zip, does anyone have strong
feelings if this is ok or should we go with only one of them? (and which
one?)
Why drop .bz2 in the first place?
The source archives for everything are going to significantly increase the
bandwidth to mirror and disk to store millions of artifacts. We should be
conservative and use the minimum, which imo is zip and bz2.
We have been using .bz2, .tar.gz and .zip based distro releases always and
AFAIK most other ASF projects too.
With this change, we'll be forced to build the missing ones manually
ourselves and/or won't be able to use *only* the new "project" assembly
within our release procedures.
But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies
can be modified to accept additional configuration settings/overrides,
*then* this would not be a problem as we can configure the needed formats
ourselves then.
I'll talk with John to see what might be possible to introduce wrt
configurability for the asf descriptor.
If you can enable that, all issues I described in MSASSEMBLY-409 would be
"solvable" automatically too :)
Also, I used source-release as the id which would produce bundles like
foo-1.0-source-release.zip. Any strong feelings on this?
That is a "workaround" for the second issue I described in MASSEMBLY-409,
but I'd still prefer being able to configure the "classifier" ourselves. We
have been using -src as "standard" extension to indicate a source
distribution for all our previous releases, just as most other ASF projects
AFAIK, and very much prefer being able to continue to do so.
Regards,
Ate
[1]
https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4
[2]
https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor
On Mon, May 4, 2009 at 9:01 PM, Brian Fox <bri...@infinity.nu> wrote:
There have been a few threads spawned on various ASF lists lately about
the
release process at the ASF and Maven projects and other Apache projects
that
use Maven being compliant.
A documentation patch for the release page at
http://www.apache.org/dev/release.html is pending, but it's close enough
that I can summarize it here. The ASF produces Open _Source_ releases.
The
primary artifact that is to be released and voted upon is a source
archive
that is sufficient for others to use to produce the product. Binaries
that
are also released have additional requirements such as NOTICE and LICENSE
files, but these are not considered to be the primary release -- the
source
archive is.
Part of the default release profile in Maven is to generate sources jars.
These sources jars contain the java packages only and not the pom.xml or
any
resources or test resources actually used to build the project. In short,
they aren't really close at all to what you might find in an svn tag for
the
same release. The primary use of these jars is by IDEs for debugging
purposes. The Maven Core releases do produce source archives using the
assembly plugin. Plugins, Shared, and other smaller releases do not. This
part is not in compliance with the ASF release process and needs to be
fixed
before the next release.
A simple solution to this problem is to bind the assembly plugin using a
src descriptor to the pom. This will work in the short term for releases
ready to go like the archetype plugin. However, it won't be very
maintainable since we have over 60 modules (i stopped counting after
plugins
and shared) that are individually released. If we bind the plugin in the
Maven pom, it would produce source archives for every single module
recursively, which is not what we want here.
To solve this, I've added a new flag to the Assembly plugin that will
tell
the plugin to only run in the Execution Root folder and skip everything
else. The enforcer plugin tree is a good example of how this will work.
The
plugin binding would be defined in the Maven pom and thus inherited down
to
the Enforcer. The Enforcer tree looks like this:
\
+---enforcer-api
+---enforcer-rules
+---maven-enforcer-plugin
\---pom.xml
Normally I would do a release of the enforcer from the top and release
the
parent, the api, rules and plugin all at once. In this case I want the
source archive to zip up the entire tree. However, I may do a release of
the
plugin only. In this case I would run from the
\enforcer\maven-enforcer-plugin subfolder. In this case, I want the just
maven-enforcer-plugin source archive because that's what I'm releasing.
The new flag in the assembly plugin would allow both cases to work
without
changing the poms, because the goal would skip in any project that
doesn't
match where Maven was executed
(!session.getExecutionRootDir().equals(basedir))
Eventually if we get this perfected, it would be appropriate to bump up
to
the Apache pom so it would just work out of the box for most projects.
Since
we may have to adjust the archive contents down the road, we should make
the
descriptor separate from the plugin itself. This can be done by producing
a
jar that contains an Apache Source Bundle descriptor, and adding this to
the
assembly plugin classpath in the execution. This will allow us to release
this independent and it would also make it easier for projects to
override
the descriptor in their projects as needed.
I'll also add a skip property specific to this execution in the release
profile to allow projects that have existing source archives to be
unaffected.
To make this happen relatively quickly, I'll take finish my patch by
adding
tests, and then stage a release of the assembly plugin 2.2-beta-3.1 by
applying only this patch to the existing beta-3 tag so we can cut a
release
without a bunch of hand wrangling over what needs to be fixed in beta-4.
Any concerns or objections to the above plan?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
