Harmonize Maven ArtifactId with Glassfish, too?

[keilw]

Given the license headers were harmonized with the Glassfish umbrella of Java EE, since we have this discussion in the JSR 362 (Portlet 3) EG (only based on Java EE, not even under its umbrella;-), another thing all Java EE JSRs tend to adopt is a unified Maven GroupId and ArtifactId. Instead of

javax.cache cache-api 1.0.0

for a new release it would be

javax.cache javax.cache-api 1.0.0

see http://mvnrepository.com/artifact/javax.faces/javax.faces-api or http://mvnrepository.com/artifact/javax.json/javax.json-api

Please check with @brianoliver and Oracle, if they wish to do it for a new release to be in sync with the rest of Java EE.

[cruftex]

-1

Changing the artifact-id in a minor release is not a good idea. That causes more confusion and frustration then does anything good.

Thanks for your hint. I would like to be it that way, too.

[keilw]

Depends on what a "minor release" contains. If some of the newly planned features for "JCache.next" even went into a MR that would be more than just a "minor release", so anything "1.1" like or higher could incorporate it if all parties involved think it's a good idea. I just say many EE JSRs follow that pattern.

[cruftex]

There is a lot of documentation and examples already out. That change would just be a lot of pain. We are working on a real minor release, not JCache.next.

[keilw]

Which of the companies in the EG do you represent btw? https://jcp.org/en/jsr/detail?id=107 Just curious because it's up to the Spec Leads, at most EG members to close such tickets, not somebody who isn't even in the EG at the moment;-) @gregrluck @brianoliver any answer to that? @cruftex has not made contributions to the spec/API according to GitHub. Also this should go into a "JCache.next" backlog, not just be brushed away. Whichever version of this JSR is meant to be included in Java EE 8 if any, would face this issue. If it's a "1.1" or "1.2" it'll matter. Unless the "bridge" scenario would only create a rather lose connection between JCache and Java EE? ;-)

[cruftex]

Your last comment is of course valid, but unrelated to the issue.

Your hint is welcome, but as I said, it is not planned to add any new features. Is it okay to close or should I reopen it?

[keilw]

If you have labels or another mechanism for "future releases" then please reopen it and label it accordingly. I'm not sure, which version or even JSR number that might be, but in the last EC meeting we heard about potential plans e.g. for "async" which has a separate branch here. So whenever that's tackled, such questions shall also be discussed ;-)

[cruftex]

Whichever version of this JSR is meant to be included in Java EE 8 if any, would face this issue.

Reopening.

Please elaborate how this affects EE 8. AFIAK if it is included in the EE API it would be included in the EE API jar.

[keilw]

There is no Java EE API with JCache included. It missed the EE 7 "release train" and EE 8 is merely starting right now (glad to see, @brianoliver can still work on this JSR to some extent, but we heard in the EC and elsewhere, not every Oracle led JSR is in the same position) The Maven artifact harmonization seems a desire by the Java EE 8 Umbrella Spec Lead(s) who also authored a naming recommendation or convention for them. JSR 362 (Portlet 3) although it is only based on Java EE (7) not part of it (or EE 8) decided it wants to adopt this for the 3.0 release after it had been different (more like JCache 1.0) until version 2. So it may be voluntary, unless those JSRs considered for inclusion in Java EE 8 must follow such convention. I cannot say but it certainly can't hurt.

[cruftex]

Created label "EE", to keep an eye on it.

I am still not in favor of doing this change in a next MR unless we know there is a strong need for it. If we really need it, the worst thing that can happen, is that we need to do a new MR, isn't it?

[keilw]

Unless the next MR was required and demanded for Java EE 8 (that was mentioned in Berlin) those could probably remain like that at least under the existing JSR number. Unless the Umbrella JSR for EE 8 demands anything that went into the umbrella to be in sync...? I think the Spec Leads are still undecided, if a new JSR or MR(s) of this one was better for going into Java EE 8. Unfortunately the GitHub orga and repos are strictly named "jsr107" not "JCache" (for the next major full update one might reconsider that, see JavaMoney, UnitsOfMeasurement etc. without a strict JSR number;-)

[keilw]

At least "JCache" itself is taken (https://github.com/jcache) and that user shows reasonable activity in his repos, so it's not like he's a time-waster who blocked that account ages ago, but some way I guess an account or organization could be found if there was a new JSR number for this project some day;-)

[cruftex]

Thanks for your input.

Please mind that this is an issue tracker and not a chat system.

Since there is a lot of noise in this issue I created a new one with the relevant information.

352