Our base rule is that the BSN is the same as the artifact ID.
There might be some exceptions, sure, but that's probably neglectable.
At least I'm not arguing for doing a rename at this point in time - but
rather keep things just as they are. If someone feels strongely to
rename in Jira, that's fine.
Regards
Carsten
Am 23.09.2020 um 08:23 schrieb Konrad Windszus:
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]
--
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
