On 28 Feb 2013, at 16:30, Sahoo wrote: > Again any change that causes pain to our users should be avoided. We don't > want any negative publicity about our stuff no matter how trivial they are. > Imagine someone doing a google search and finding two different plugin > coordinates. It does not help a new comer and that's where we have been > struggling as a community.
<devils-advocate> Except that having OSGi packaging supported in Maven out-of-the-box could be worth any short-term confusion, especially if we use a Maven relocation reference to redirect people to the migrated plugin. In such cases new users would just change their project packaging from jar->bundle to get OSGi support and not need anything else unless they needed to override the defaults. Existing users could still continue to use current plugin releases, this is just looking at future options - and if we did decide to contribute the plugin to Maven then they'd just need to remove/change the groupId when changing the version. Not trivial, although the pom.xml relocation option could help ease the pain, but also not as ground-shaking as requiring users to completely rewrite their configuration. </devils-advocate> If we do decide to keep the status quo then at least I have a thread to point the Maven folks to next time they remind me to update the name... > Thanks, > Sahoo > On Thursday 28 February 2013 07:48 PM, Richard S. Hall wrote: >> I am fine with this option as well. >> >> -> richard >> >> On 2/28/13 08:35 , Stuart McCulloch wrote: >>> During the "[DISCUSS] rename maven-bundle-plugin to bnd-maven-plugin" >>> thread Marcel and Guillaume came up with counter-suggestions involving >>> contributing the maven-bundle-plugin to Apache Maven. >>> >>> This idea has certain advantages - the plugin name would not be an issue >>> (assuming the Maven team were ok with 'bundle'==OSGi, as there are other >>> interpretations of 'bundle' such as resource bundles) and there's then a >>> chance we could get the 'bundle' packaging type recognized by default by >>> Maven (though this wouldn't necessarily be a done deal). It would also mean >>> that people wouldn't need to specify a groupId when adding the plugin to >>> their pom.xml and you could use the short form of the plugin name from the >>> command-line. >>> >>> The disadvantages are this would still involve a change of plugin >>> coordinates (org.apache.felix -> org.apache.maven.plugins) and any changes >>> or improvements would have to go through the Apache Maven project. >>> >>> There's also a question of whether the Apache Maven team would accept the >>> contribution... >>> >>> WDYT? >>> >>> -- >>> Cheers, Stuart >>> >>> On 28 Feb 2013, at 13:03, Marcel Offermans wrote: >>> >>>> On Feb 28, 2013, at 13:43 , Stuart McCulloch <[email protected]> wrote: >>>>> On 28 Feb 2013, at 07:05, fbalicchia wrote: >>>>> >>>>>> I think it is the best choice to follow the naming convention. >>>>>> What I do not understand is why plugins can't be hosted by Apache >>>>> The Apache Maven team prefer to keep the maven-NNN-plugin naming for >>>>> plugins developed and maintained by them (ie. those with groupId >>>>> org.apache.maven.plugins) whereas Maven plugins developed by other Apache >>>>> (or non-Apache) projects are encouraged to use NNN-maven-plugin naming. >>>>> The idea is to help avoid confusion about which plugins are directly >>>>> supported by Apache Maven team and which are supported elsewhere: >>>>> >>>>> http://www.mail-archive.com/[email protected]/msg128850.html >>>>> >>>>> While renaming the plugin would be a courtesy to the Apache Maven team, >>>>> it is not mandatory if it would cause problems for downstream users - >>>>> hence this discussion thread. >>>> I would say, our users come first. Renaming the plugin causes them >>>> problems for no reason (to them) so let's not do that. >>>> >>>> Instead, we could also solve this by donating the plugin to the Apache >>>> Maven project. >>>> >>>> Greetings, Marcel >> >
