I don't know much about these assembly changes etc so I can't comment on any of that. Perhaps search the dev@ list to find more details.
Here's another idea you might not have considered... You could find out the version number for the old (working) assembly plugin and specify it directly in your pom.xml as a plugin dependency... This would allow you to keep using your old mvn assembly etc as you are used to, without these recent changes affecting your build process. Not saying this is a great solution, but it might make you happier for the short term, until these issues with assembly are worked out in a new release. Wayne On 4/10/06, Stephen Duncan <[EMAIL PROTECTED]> wrote: > I know I'm a bit slow here, as it appears these changes were released > quite a while ago. But still, I've just noticed today the issue > (discussed before, but since I didn't realize it was affecting ME, I > didn't pay attention!) regarding the assembly plugin forking the > lifecycle, causing my existing setup to run everything twice because I > have assembly attached to the package phase. > > I really don't get that decision. What I think I understand is that > now you can run "mvn assembly:assembly", and you get the same behavior > you would have gotten before running "mvn package assembly:assembly"? > Was this "gain" really worth breaking existing builds, and now > requiring features for the ability to run assembly:assembly and > assembly:directory in non-lifecycle-forking mode? > > Also, it's really hard to tell what's going on, because the site for > the assembly plugin doesn't seem to have been updated for quite some > time (in fact, it still has "m2" as the Maven command, not "mvn"). > Also, shouldn't there be somewhere in the site that states the version > number the site is associated with? (Please indicate if these are > known issues, or I'll plan to put them in JIRA tomorrow). > > My use case for the assembly plugin is this: > > 1) I want to be able to generate the whole thing easily in one command. > 2) I want to use assembly:assembly to create a zip of my source. > 3) I want to do assembly:directory to create a directory of files I > will then upload into a another system where my file releases go. > 4) In that directory I want the sources and javadoc jars included, as > well as the src zip. > > I see where forking the lifecycle fulfills item #1 but it makes it > very confusing for users of my project that, instead of running mvn > with a lifecycle phase to do a release, run "assembly:assembly". I > think this breaks the normal usage model. > > I haven't tested how the forking of the lifecycle works. I get the > javadoc and sources jars to be created by passing > -DperformRelease=true. If I run "mvn -DperformRelease=true > assembly:assembly" will the property be passed along, causing > javadoc:jar and source:jar to be run? If so, then that could solve 4. > > My solution prior to these changes in the plugin was to put > configuration for execution of assembly:assembly and > assembly:directory attached to the package phase into a profile > activated by performRelease=true, and simply have the assembly be run > when a user ran "mvn -DperformRelease=true package". > > What would be the right way now? Since I would need two > configurations of the assembly plugin, I would have to have all the > configuration on the command-line and run two separate commands. And > how do you specify multiple descriptors on the command-line? Are > lists comma-separated, or what? > > Or I guess I have to wait for another release of the assembly plugin. > In that case would I just use newly created goals that avoid the > forked-lifecycle and go back to how it was before, or would I only use > the non-forking assembly:assembly in a profile, and then run > assembly:directory from the command-line? What exactly is the new > use-case idea here? > > I apologize for the lengthe here, but I found the experience quite > frustrating. I know I saw several e-mails about either infinite-loops > or just the repeated-builds after these changes were released, but did > I just miss my opportunity (here or on the dev list) to comment on > these changes before they were made? > > -- > Stephen Duncan Jr > www.stephenduncanjr.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
