I don't know what would be causing this, but the jira should allow us
to take a look. I've done most of the development on the assembly
plugin in the past year or so, but I don't think this has anything to
do with my changes, since I haven't committed anything on the plugin
in a month or more...
At any rate, we can track this via your JIRA.
Thanks,
-john
On Nov 26, 2007, at 4:58 AM, Grégory Joseph wrote:
On 23/11/2007, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Please report this in JIRA, as attachment to mailing lists have a
nasty
habit of being forgotten.
Done,
http://jira.codehaus.org/browse/MASSEMBLY-250
I was hoping for some preliminary discussion, so as to be able to
create more precise and effective reports ;)
Cheers,
greg
Grégory Joseph wrote:
Hi,
I painfully discovered recently that the trunk of the assembly
plugin
seems to be broken. I'd been using the snapshot (20071017.162810)
from
http://people.apache.org/repo/m2-snapshot-repository happily for a
while, but since I had to do releases, I went the hardcore way
and did
an internal deploy against the trunk.
I can't use the 2.2-beta-1 version because I need, amongst other
things, fileSet filtering (more on that later), and the artifact
type.
Here's what I found broken with the trunk:
- I can't build multiple artifacts from the same assembly
descriptor
(i.e zip and tgz), only one. This works smoothly with the
aforementioned snapshot.
- Severe issue: filtering a fileSet empties these files. (0 byte in
the resulting zip or tgz). This also works nicely with the snapshot.
It only works on the trunk if I disable filtering and lineending.
- Less critical : pom properties are apparently not interpolated in
assembly descriptors.
I attached a small testcase the shows the issue. Unpack it and do:
mvn clean install
unzip -l target/assembly-trunkbuggy-1.2.3-SNAPSHOT-test.zip
You should see that both copies of the test.txt file have a
length of 337 bytes.
Now move your local repo away for a moment, build the trunk, comment
out the repositories in my test's pom, build it again, and you
should
see that the test.txt copies in the zip are empty.
As far as I can tell, there has not been any commit since the
timestamp of the snapshot that could have an obvious impact on these
problems.
I also tried doing deploy:deploy-file with the snapshot itself, to
deploy it internally, but somehow that triggered a whole
different set
of problems. (ClassNotFoundExceptions etc)
I'll happily report this on Jira, but I thought I'd poke here first,
since it doesn't seem clear how the regression could have
happened. At
some point I vaguely suspected the snapshot could have been built
against uncommitted code ... ?
Can someone shed some light on this? Also, since it doesn't seem
that
the plugin is ready for a beta-2 release just yet (or is it? can
anyone do it ?), could anyone assist in changing the current
snapshot
dependencies it has, so I could do an internal release of it, in
order
to proceed with our own releases ?
Thanks a bunch !
-greg
--------------------------------------------------------------------
----
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
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]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
