maven-assembly-plugin, built-in/shared descriptors and custom classifier
Hello Maven users, It seems that when using built-in descriptors there is no way to specify custom classifier for produced assembly. single mojo has classifier parameter but it is marked as deprecated. http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html If this can not be overridden, then it impacts use of custom shared descriptors ( http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html ) classifier seems to have been deprecated in favor of using assembly id but one can not specify assembly id of built-in or shared descriptors. Is there maybe a workaround to inherit somehow built-in or shared assembly descriptor? I know about component descriptors, but AFAIK assembly descriptors (built-in or shared) can not be referenced as component descriptors. Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Plugin built and used in the same build
Hi, It's been brought up in Geronimo dev mailing list and I'm asking for clarification. Geronimo build is migrating to M2 and we run into a problem with a Geronimo M2 plugin that's an integral part of the build itself. Geronimo provides its own tailor-made M2 plugins that are part of the build. Is it true that a plugin that's built in a M2 execution and is part of the build (is used later in the build) is not used but the one that's been downloaded? If so, how should a project proceed where it provides its own M2 plugin that's an integral part of the M2-based build? Since the build blows up when the plugin is not found, but its sources are about to be built during M2 execution, what is the trick to build it before M2 will need it? Any help appreciated. Jacek -- Jacek Laskowski http://www.laskowski.net.pl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Plugin built...
Omair-Inam Abdul-Matin wrote: Gilles Dodinet wrote: Omair-Inam Abdul-Matin wrote: I followed the link provided by Gilles and am trying to build the eclipse plugin. All goes well until the final step. I chang into the mevenide-master directory and issue the maven mevenide-eclipse:build command. Maven chugs along for a while, then chokes and dies :( I have attached the final few pages of output given by maven. Can anyone guide me as to what the problem is? Note that my setup environment is correctly set up (I have ECLIPSE_HOME set to point to my Eclipse installation directory) Omair, problem is that youve built against M9. Oh (:-0) i havent yet committed the changes i made for M9. i just committed changes so it will at least compile, however M9 seems to _really_ break runtime.. if you're interested i can upload a M8 compatible update site. -- gd I would definitely be interested in an M8 compatible website. So if I understand correctly this would allow me to go through the Help-Software Updates-Find and Install option in Eclipse 3.0M8 to install the plugin... right? Omair I managed to build the plugin against 3.0M8. Now what is the configuration directory mentioned in the wiki that I have to delete. By that are you referring to the /path/to/my/workspace/.metadata directory? If not then which directory? Omair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mevenide - eclipse 3.0 M8 (was: Plugin built...)
Omair-Inam Abdul-Matin wrote: I see the directory. actually that is useful when upgrading feature - seems 3.0 Mx have some troubles with managing feature versions (ive experimented it and read similar experiences on o.e.platform newsgroup). anyway ive uploaded a zip archive here : http://dist.codehaus.org/mevenide/release/. you can use it to install from a local update site. please report any problems to mevenide user-list. thanks, -- gd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
