+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]
>

Reply via email to