For bundles the artifact id is not that visible but the BSN is. This is not necessarily the same. So if we do a rename in JIRA we should take BSN for bundles and artifact ID for Maven plugins. Konrad
> On 23. Sep 2020, at 08:08, David Bosschaert <[email protected]> > wrote: > > +1 to using Artifact IDs in JIRA. As mentioned by others, if for example > someone finds a bug running the slingfeature-maven-plugin they would > probably have a hard time finding the component named 'OSGi Feature Maven > Plugin'. To be sure they would have to go to the pom.xml of the original > codebase and look for the name tag, which is: > <name>Apache Sling OSGi Feature Maven Plugin</name> > Then they'd have to take off the 'Apache Sling' prefix. > > Another problem is that the name is not required to be unique. It _should_ > be, but with the ID you're sure that it's unique. > > My 2c, > > David > > On Wed, 23 Sep 2020 at 06:09, Carsten Ziegeler <[email protected]> wrote: > >> Just to state it again, artifact name is really not useful for our users >> out there trying to file a bug against a module. Artifact id is in their >> face when they use these things, being it the plugin name, the maven >> coordinates or the symbolic name. Everything is based on ids. >> Ids are stable - names might change >> >> Renaming the existing artifact ids in Jira to names, makes it worse. >> >> We didn't have any problem with this for years, and I don't understand >> why a new tool developed by ourselves should force us now to change >> things. Why can't the tool simply look for both, id and name - and we're >> done with this? >> >> Regards >> Carsten >> >> Am 22.09.2020 um 20:38 schrieb Konrad Windszus: >>> I would also personally prefer artifact id instead of name in JIRA. But >> the majority of version names in JIRA is right now named after the artifact >> name ( >> https://issues.apache.org/jira/projects/SLING?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released). >> Also our releases section currently uses artifact names ( >> https://sling.apache.org/releases.html). >>> We should do it consistently and I am not sure it is worth the effort to >> migrate all the release version names (would require some scripting). I >> would tend to say, for consistency and simplicity: Just turn the few which >> use artifact id right now into artifact name >>> >>> Konrad >>> >>>> On 22. Sep 2020, at 18:59, Carsten Ziegeler <[email protected]> >> wrote: >>>> >>>> >>>> I personally think its ok if we use the artifact name in jira, like in >> this case - especially as the name might change. Whatever we decide, it >> needs to be consistent across a module- meaning if we start to rename with >> version 1.4.0 then we also need to rename all previous versions. >>>> >>>> >>>> Now from a customer perspective, if someone wants to file a bug against >> the slingfeature-maven-plugin (which is what is used and what is visable in >> the error from maven), I think someone finds >> slingfeature-maven-plugin-1.4.0 much easier than 'OSGi Feature Maven Plugin >> 1.4.0' which is nowhere visible in maven output. >>>> >>>> Regards >>>> Carsten >>>> >>>> Am 22.09.2020 um 17:07 schrieb Robert Munteanu: >>>>> Hi, >>>>> I am in a middle of a release (and using the committer cli [1]) and I >>>>> got stuck due to an unexpected (for the tool) version: >>>>> java.lang.IllegalArgumentException: No releases found in >>>>> 'slingfeature-maven-plugin-1.4.0' >>>>> To go for the quick fix, I renamed that version to 'OSGi Feature Maven >>>>> Plugin 1.4.0', matching the module name. This is quickly reversible so >>>>> I just did the change. >>>>> Of course, the tool can be changed, but there is some value IMO in >>>>> having module names and Jira version names aligned, namely: >>>>> - it is clear for users and tools what release maps to which module >>>>> - we don't have to invent a second name for the same thing :-) >>>>> I'm open to saying that version names can be arbitrary, but then we can >>>>> simplify our life by having matching names. >>>>> Thanks, >>>>> Robert >>>>> [1]: https://github.com/apache/sling-org-apache-sling-committer-cli/ >>>> >>>> -- >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> [email protected] >>> >> >> -- >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] >>
