On Thu, 2020-09-24 at 12:08 +0200, Carsten Ziegeler wrote: > 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've now removed all traces of 'OSGi Feature Maven Plugin' from the versions and moved to 'slingfeature-maven-plugin XXX' format. Thanks, Robert > > 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] > > > > > > >
