Change artifact-id for EE inclusion?

[cruftex]

Werner Keil pointed out:

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

Jens' statement: I am not in favor of doing this change in a next MR unless we know there is a strong need for it. The artifact-ids need to be changed wherever used, that is a big amount of work that JCache users will hate us for. If we really need it, the worst thing that can happen is that we need to do a new MR.

Suggest not scheduling for upcoming MR unless new information.

[keilw]

Thanks, no problem cloning the ticket, but I see no problem with constructive comments here rather than a mailing list like Google Groups;-) I agree, GitHub may be a bit less structured and organized than e.g. JIRA but some projects like C# I follow and see almost daily updates to their issues or "stories" (that's what many of these tickets are;-)

[keilw]

One of the most notable exceptions under Java EE is CDI btw, it (led by JBoss) does not follow the Oracle-recommended (also not so common in other places, e.g. Apache) prefix to the artifact ID even with 2.0. Since Oracle is Co Spec Lead and (see the license question;-) has some say, please have them clarify if it's necessary or not.

[cruftex]

Added 1.1 to discuss about it.

A possible solution could be to release the same artifact twice. Under cache-api and javax.cache-api. This allows a smoother transition and satisfies both: It doesn't break existing dependencies but EE can have a proper artifact id.

[gregrluck]

A couple of thoughts. This is now widely used so changing the artifactId is an unnecessary inconvenience to users. I see Werner points out that JBoss does not follow the convention. We had Bill Shannon review all this three years ago and this convention was never mentioned so I am going to conclude it was a not a big deal and close.

[keilw]

Given it is far from certain, if JCache would even be an official part of Java EE 8 or 9, I see this as not such a big deal as well.

[gregrluck]

Werner

We would very much like this to be part of EE8 or 9.

If you would like to be then please vote for it in the survey.

[keilw]

We heard Linda say what's necessary to make that happen. Just a survey is not enough;-)

[gregrluck]

I just emailed her to ask her.

Regards

Greg Luck

web: http://gregluck.com http://gregluck.com/ skype: gregrluck mobile US: +1 650 924 6244 mobile Australia: +61 408 061 622

On 3 Oct. 2016, at 1:52 pm, Werner Keil notifications@github.com wrote:

We heard Linda say what's necessary to make that happen. Just a survey is not enough;-)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jsr107/jsr107spec/issues/352#issuecomment-251192470, or mute the thread https://github.com/notifications/unsubscribe-auth/AANyhEbYmrUKAfw43CTGABukx4rXkJ4Vks5qwU7fgaJpZM4Igedz.

[gregrluck]

What is that? I do not know and have not heard.

Regards

Greg Luck

web: http://gregluck.com http://gregluck.com/ skype: gregrluck mobile US: +1 650 924 6244 mobile Australia: +61 408 061 622

On 3 Oct. 2016, at 1:52 pm, Werner Keil notifications@github.com wrote:

We heard Linda say what's necessary to make that happen. Just a survey is not enough;-)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/jsr107/jsr107spec/issues/352#issuecomment-251192470, or mute the thread https://github.com/notifications/unsubscribe-auth/AANyhEbYmrUKAfw43CTGABukx4rXkJ4Vks5qwU7fgaJpZM4Igedz.

[keilw]

Check the EC F2F Minutes, it should be there;-)