How about an option trueexcludeBuildDirectories> that uses the list of build directories from
all projects in the reactor an applies that to the fileset excludes?
It could be either descriptor-wide, or per-fileset I guess.
Short of that, I'd say to get it off the ground to tell projects they
need to alter the descriptor when using it to explicitly include their
non-build target directories.
- Brett
On 21/05/2009, at 7:14 AM, Brian Fox wrote:
Introducing the configurability in the descriptor itself requires more
changes to the assembly code than I think we should tackle right
now. I also
think we should strive to build a descriptor that works for all
projects to
the extent possible. That said, I'll make a property in the plugin
config to
make it easier for projects to disable this execution and/or use a
different
descriptor of their choosing.
Now, I solved the MASSEMBLY-405 issue, but this causes a few more
problems
we need to look into. It causes us to need something like **\target
\** to
exclude the build artifacts from the assembly, but several projects
in maven
use target folders in their test resources (archetype, install,
deploy). The
solution to this yet is still undefined.
On Mon, May 18, 2009 at 11:36 AM, Ate Douma wrote:
Brian Fox wrote:
On Mon, May 18, 2009 at 8:57 AM, Ate Douma 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:
maven-assembly-plugin
2.2-beta-4-SNAPSHOT
single
validate
true
source-release
org.apache
apache-source-release-assembly-descriptor
1.0-SNAPSHOT
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 config
