Thanks. I had briefly considered it yesterday, but promptly forgot about as I attempted to remember everything else I wanted to say.
I suppose this will be a chance to test out pluginManagement in the parent POM, as the current configuration for this is in several projects... -Stephen On 4/11/06, Wayne Fay <[EMAIL PROTECTED]> wrote: > 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] > > > > > -- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
