THanks Robert,
now if I get it right you're proposing to change
'slingfeature-maven-plugin-1.4.0'
to
'slingfeature-maven-plugin 1.4.0'
in Jira, correct?
And revert the renaming to "OSGi Feature Maven Plugin" ?
I'm fine with that
Regards
Carsten
Am 24.09.2020 um 11:58 schrieb Robert Munteanu:
First of all, just to restate the intent: I don't suggest renaming the
Jira versions because of the tool limitations. I think it makes sense
to use something that is aligned with the module name and that problem
was exposed by the tooling.
We created Jira versions in the form of 'Artifact Name' 'Version' for
quite some time, only one of them stands out by being different. Just a
note, not something bad by itself.
On the idea that artifact names are opaque to our users, I think we're
focusing too much on the slingfeature-maven-plugin vs 'OSGi Feature
Maven Plugin' discussion. In this particular instance I think the
artifact name is wrong. It should be 'SlingFeature Maven Plugin', which
would make it obvious for users what version to report bugs against. In
my mind the rule that Georg proposed is basically how we generate
artifact names, e.g.
- org.apache.sling.jcr.base -> 'JCR Base'
- org.apache.sling.api -> 'API'
etc
I personally am not proposing a big change where we rename historically
released versions, I am not sure if it is helpful and if it justifies
the effort.
I would however suggest that we at least keep the 'name' 'version'
convention, e.g. 'slingfeature-maven-plugin 1.4.0' instead of
'slingfeature-maven-plugin-1.4.0' format, as it nicely separates the
artifact from the version itself.
Thanks,
Robert
On Wed, 2020-09-23 at 10:22 +0200, Georg Henzler wrote:
Generally I'm also in favor of the artifactId because it
makes a proper id (as already stated). However it is a lot
of noise because all versions in JIRA project "SLING" will
start with "org.apache.sling.". So why not just use the
rule
substringAfter(artifactId, "org.apache.sling.") + "-" + version
That would give us versions like api-2.23.0, auth.core-1.5.1 etc.
The big advantage of this is that you see the actual version
number in JIRA UI (if the version string is very long, you only
see the prefix and the actual version is cut off, this really
has to be avoided and hence IMHO we cannot just use the
artifactID)
We don't need to change the past, we can just use the name
convention for the future for all releases... (and Robert can
fix the tooling to exactly one well-defined release name)
WDYT?
-Georg
On 2020-09-23 09:52, Carsten Ziegeler wrote:
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]
