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]
