Re: [DISCUSS] implement jakarta spec apis
Btw, found a good example for hierarchic structures: JsonValue. And one more question: how to deal with annotations if he javax package is essentially sealed? How can you add a value to an annotation or change some meta annotation like eg the Target? LieGrue, Strub > Am 05.05.2019 um 21:03 schrieb Romain Manni-Bucau : > > I see, makes sense. > > Personally i strongly think we dont need a strong toggle and that future > compat can rely on javax, this is what javaee was about after all. > > But no issue testing things, we can even use sandbox/ for that. > >> Le dim. 5 mai 2019 à 20:49, Mark Struberg a écrit : >> Of course there will be no releases until the EF has a common understanding >> how to proceed on their side. After all the main goal is compatibility >> amongst vendors. >> >> I'd actually even would avoid to push snapshots to our repository.apache.org >> ... >> >> This is mainly for understanding how far we come, what the limits are and >> what other options we have. >> >> LieGrue, >> strub >> >> >> > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau : >> > >> > Ok. >> > >> > Can we agree to take this discussion back and hold any release - no issue >> > with snaps - until it is clarified? >> > >> > Le dim. 5 mai 2019 à 18:45, Mark Struberg a écrit : >> > I'm not even sure whether they yet got all the necessary IP to release >> > anything. >> > >> > LieGrue, >> > strub >> > >> > >> > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau >> > > : >> > > >> > > >> > > >> > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : >> > > I'm not mandating jakarta in the groupId, but it should something else >> > > than the current one. >> > > Because otw we would have them completely mixed up in the same folder. >> > > That's not nice. >> > > >> > > Depends, that said happy to just replace specs by jakarta if it works >> > > for you better (org.apache.geronimo.jakarta). I just dont want >> > > jakarta-specs or _spec-xxx as before, always looked fishy and almost >> > > wrong even if I get where it comes from. >> > > >> > > Btw, what is our status on having eclipse releasing api under asf2 >> > > license? >> > > >> > > I dont want us to invest in something we drop like in 2 weeks and sounds >> > > it can be for most of specs. Any page tracking that? >> > > >> > > >> > > LieGrue >> > > strub >> > > >> > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau >> > > > : >> > > > >> > > > We dont need jakarta in the gav at all. >> > > > >> > > > Why not org.apache.geronimo.spec:servlet:4.0.1? >> > > > >> > > > As a reminder specs means jakarta already and there id jo ambiguity >> > > > between jakarta and javaee thanks the version. >> > > > >> > > > That said if we move to git it id even physically clearer. >> > > > >> > > > Finally servlet is a bad example cause owned at tomcat for apache i >> > > > think. We should absolutely stop duplicating them, it pollutes user >> > > > land for no gain IMHO. >> > > > >> > > > >> > > > >> > > > >> > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : >> > > > Eclipse itself probably doesn't yet have all the IP themselves. This >> > > > first needs to be clarified. Since all those legal questions have been >> > > > dealt with behind closed doors we simply have no idea. >> > > > >> > > > But we do have clean-room implemented APIs under ALv2 over here at >> > > > Geronimo. >> > > > And we can move this ourselves without having to wait for anybody. >> > > > >> > > > LieGrue, >> > > > strub >> > > > >> > > > >> > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels >> > > > > : >> > > > > >> > > > > I wonder if you need that going forward for Jakarta Specs, they >> > > > > could just be distributed by Eclipse directly? Having said that, if >> > > > > this is not the case I would at least remove „geronimo-“ from the >> > > > > artifact Id? >> > > > > >> > > > > >> > > > > -- >> > > > > http://bernd.eckenfels.net >> > > > > >> > > > > Von: Mark Struberg >> > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM >> > > > > An: geronimo-dev >> > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis >> > > > > >> > > > > For now I've used the following patterns: >> > > > > >> > > > > org.apache.geronimo.jakarta-specs >> > > > > because specs and jakarta-specs should be in a clearly separated >> > > > > folder. >> > > > > >> > > > > geronimo-jakarta-servlet_spec >> > > > > because 'jakarta' should be in the jar name >> > > > > >> > > > > 4.0_1-SNAPSHOT >> > > > > 4.0 is for servlet-4.0, 1 is the patch level. >> > > > > >> > > > > I'd NOT do a release or push to our snapshots repo until in about 2 >> > > > > weeks when the modus operandi is clear within the Jakarta community. >> > > > > >> > > > > LieGrue, >> > > > > strub >> > > > > >> > > > > >> > > > > >> > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau >> > > > > > : >> > > > > > >> > > > > > Do we also want to clean our
Re: [DISCUSS] implement jakarta spec apis
Btw, the limit so far has been hit whenever some internal JDK class did return some javax class. It appears that the JDK ships many old EE parts. E.g. old common-annotations which still miss @Priority. Or even worse an ancient javax.transaction package. And then some javax.sql classes from the JDK return some transaction stuff :( Here subclassing would make perfect sense as you noted on Twitter. So we could leave the existing javax.* classes and if we need some change then we introduce a subclass in a corresponding jakarta.*. This might work in many cases. But we need to check if it als works for hierarchies. You cannot add something in a root class in jakarta as the original,classes would not extend you. Need. A bit more time to think about that. LieGrue, Strub > Am 05.05.2019 um 21:03 schrieb Romain Manni-Bucau : > > I see, makes sense. > > Personally i strongly think we dont need a strong toggle and that future > compat can rely on javax, this is what javaee was about after all. > > But no issue testing things, we can even use sandbox/ for that. > >> Le dim. 5 mai 2019 à 20:49, Mark Struberg a écrit : >> Of course there will be no releases until the EF has a common understanding >> how to proceed on their side. After all the main goal is compatibility >> amongst vendors. >> >> I'd actually even would avoid to push snapshots to our repository.apache.org >> ... >> >> This is mainly for understanding how far we come, what the limits are and >> what other options we have. >> >> LieGrue, >> strub >> >> >> > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau : >> > >> > Ok. >> > >> > Can we agree to take this discussion back and hold any release - no issue >> > with snaps - until it is clarified? >> > >> > Le dim. 5 mai 2019 à 18:45, Mark Struberg a écrit : >> > I'm not even sure whether they yet got all the necessary IP to release >> > anything. >> > >> > LieGrue, >> > strub >> > >> > >> > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau >> > > : >> > > >> > > >> > > >> > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : >> > > I'm not mandating jakarta in the groupId, but it should something else >> > > than the current one. >> > > Because otw we would have them completely mixed up in the same folder. >> > > That's not nice. >> > > >> > > Depends, that said happy to just replace specs by jakarta if it works >> > > for you better (org.apache.geronimo.jakarta). I just dont want >> > > jakarta-specs or _spec-xxx as before, always looked fishy and almost >> > > wrong even if I get where it comes from. >> > > >> > > Btw, what is our status on having eclipse releasing api under asf2 >> > > license? >> > > >> > > I dont want us to invest in something we drop like in 2 weeks and sounds >> > > it can be for most of specs. Any page tracking that? >> > > >> > > >> > > LieGrue >> > > strub >> > > >> > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau >> > > > : >> > > > >> > > > We dont need jakarta in the gav at all. >> > > > >> > > > Why not org.apache.geronimo.spec:servlet:4.0.1? >> > > > >> > > > As a reminder specs means jakarta already and there id jo ambiguity >> > > > between jakarta and javaee thanks the version. >> > > > >> > > > That said if we move to git it id even physically clearer. >> > > > >> > > > Finally servlet is a bad example cause owned at tomcat for apache i >> > > > think. We should absolutely stop duplicating them, it pollutes user >> > > > land for no gain IMHO. >> > > > >> > > > >> > > > >> > > > >> > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : >> > > > Eclipse itself probably doesn't yet have all the IP themselves. This >> > > > first needs to be clarified. Since all those legal questions have been >> > > > dealt with behind closed doors we simply have no idea. >> > > > >> > > > But we do have clean-room implemented APIs under ALv2 over here at >> > > > Geronimo. >> > > > And we can move this ourselves without having to wait for anybody. >> > > > >> > > > LieGrue, >> > > > strub >> > > > >> > > > >> > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels >> > > > > : >> > > > > >> > > > > I wonder if you need that going forward for Jakarta Specs, they >> > > > > could just be distributed by Eclipse directly? Having said that, if >> > > > > this is not the case I would at least remove „geronimo-“ from the >> > > > > artifact Id? >> > > > > >> > > > > >> > > > > -- >> > > > > http://bernd.eckenfels.net >> > > > > >> > > > > Von: Mark Struberg >> > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM >> > > > > An: geronimo-dev >> > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis >> > > > > >> > > > > For now I've used the following patterns: >> > > > > >> > > > > org.apache.geronimo.jakarta-specs >> > > > > because specs and jakarta-specs should be in a clearly separated >> > > > > folder. >> > > > > >> > > > > geronimo-jakarta-servlet_spec >> > > > > because 'jakarta' should be
Re: [DISCUSS] implement jakarta spec apis
I see, makes sense. Personally i strongly think we dont need a strong toggle and that future compat can rely on javax, this is what javaee was about after all. But no issue testing things, we can even use sandbox/ for that. Le dim. 5 mai 2019 à 20:49, Mark Struberg a écrit : > Of course there will be no releases until the EF has a common > understanding how to proceed on their side. After all the main goal is > compatibility amongst vendors. > > I'd actually even would avoid to push snapshots to our > repository.apache.org ... > > This is mainly for understanding how far we come, what the limits are and > what other options we have. > > LieGrue, > strub > > > > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau >: > > > > Ok. > > > > Can we agree to take this discussion back and hold any release - no > issue with snaps - until it is clarified? > > > > Le dim. 5 mai 2019 à 18:45, Mark Struberg a écrit : > > I'm not even sure whether they yet got all the necessary IP to release > anything. > > > > LieGrue, > > strub > > > > > > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > > > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit > : > > > I'm not mandating jakarta in the groupId, but it should something else > than the current one. > > > Because otw we would have them completely mixed up in the same folder. > That's not nice. > > > > > > Depends, that said happy to just replace specs by jakarta if it works > for you better (org.apache.geronimo.jakarta). I just dont want > jakarta-specs or _spec-xxx as before, always looked fishy and almost wrong > even if I get where it comes from. > > > > > > Btw, what is our status on having eclipse releasing api under asf2 > license? > > > > > > I dont want us to invest in something we drop like in 2 weeks and > sounds it can be for most of specs. Any page tracking that? > > > > > > > > > LieGrue > > > strub > > > > > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > We dont need jakarta in the gav at all. > > > > > > > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > > > > > > > As a reminder specs means jakarta already and there id jo ambiguity > between jakarta and javaee thanks the version. > > > > > > > > That said if we move to git it id even physically clearer. > > > > > > > > Finally servlet is a bad example cause owned at tomcat for apache i > think. We should absolutely stop duplicating them, it pollutes user land > for no gain IMHO. > > > > > > > > > > > > > > > > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a > écrit : > > > > Eclipse itself probably doesn't yet have all the IP themselves. This > first needs to be clarified. Since all those legal questions have been > dealt with behind closed doors we simply have no idea. > > > > > > > > But we do have clean-room implemented APIs under ALv2 over here at > Geronimo. > > > > And we can move this ourselves without having to wait for anybody. > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels < > e...@zusammenkunft.net>: > > > > > > > > > > I wonder if you need that going forward for Jakarta Specs, they > could just be distributed by Eclipse directly? Having said that, if this is > not the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > > > > > > > > > > -- > > > > > http://bernd.eckenfels.net > > > > > > > > > > Von: Mark Struberg > > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > > > > An: geronimo-dev > > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > > > > > > > For now I've used the following patterns: > > > > > > > > > > org.apache.geronimo.jakarta-specs > > > > > because specs and jakarta-specs should be in a clearly separated > folder. > > > > > > > > > > geronimo-jakarta-servlet_spec > > > > > because 'jakarta' should be in the jar name > > > > > > > > > > 4.0_1-SNAPSHOT > > > > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > > > > > > > I'd NOT do a release or push to our snapshots repo until in about > 2 weeks when the modus operandi is clear within the Jakarta community. > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor > version =spec version > > > > > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau < > rmannibu...@gmail.com> a écrit : > > > > > > > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a > écrit : > > > > > > The problem is that in a git repo you can only release all at > once. That means we would need to have a single git repo for each and every > spec. That will be quite many... > > > > > > > > > > > > No, maven plugins was a monorepo for years and then they split. > > >
Re: [DISCUSS] implement jakarta spec apis
Of course there will be no releases until the EF has a common understanding how to proceed on their side. After all the main goal is compatibility amongst vendors. I'd actually even would avoid to push snapshots to our repository.apache.org ... This is mainly for understanding how far we come, what the limits are and what other options we have. LieGrue, strub > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau : > > Ok. > > Can we agree to take this discussion back and hold any release - no issue > with snaps - until it is clarified? > > Le dim. 5 mai 2019 à 18:45, Mark Struberg a écrit : > I'm not even sure whether they yet got all the necessary IP to release > anything. > > LieGrue, > strub > > > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau : > > > > > > > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : > > I'm not mandating jakarta in the groupId, but it should something else than > > the current one. > > Because otw we would have them completely mixed up in the same folder. > > That's not nice. > > > > Depends, that said happy to just replace specs by jakarta if it works for > > you better (org.apache.geronimo.jakarta). I just dont want jakarta-specs or > > _spec-xxx as before, always looked fishy and almost wrong even if I get > > where it comes from. > > > > Btw, what is our status on having eclipse releasing api under asf2 license? > > > > I dont want us to invest in something we drop like in 2 weeks and sounds it > > can be for most of specs. Any page tracking that? > > > > > > LieGrue > > strub > > > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau : > > > > > > We dont need jakarta in the gav at all. > > > > > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > > > > > As a reminder specs means jakarta already and there id jo ambiguity > > > between jakarta and javaee thanks the version. > > > > > > That said if we move to git it id even physically clearer. > > > > > > Finally servlet is a bad example cause owned at tomcat for apache i > > > think. We should absolutely stop duplicating them, it pollutes user land > > > for no gain IMHO. > > > > > > > > > > > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : > > > Eclipse itself probably doesn't yet have all the IP themselves. This > > > first needs to be clarified. Since all those legal questions have been > > > dealt with behind closed doors we simply have no idea. > > > > > > But we do have clean-room implemented APIs under ALv2 over here at > > > Geronimo. > > > And we can move this ourselves without having to wait for anybody. > > > > > > LieGrue, > > > strub > > > > > > > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels : > > > > > > > > I wonder if you need that going forward for Jakarta Specs, they could > > > > just be distributed by Eclipse directly? Having said that, if this is > > > > not the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > > > > > > > -- > > > > http://bernd.eckenfels.net > > > > > > > > Von: Mark Struberg > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > > > An: geronimo-dev > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > > > > > For now I've used the following patterns: > > > > > > > > org.apache.geronimo.jakarta-specs > > > > because specs and jakarta-specs should be in a clearly separated > > > > folder. > > > > > > > > geronimo-jakarta-servlet_spec > > > > because 'jakarta' should be in the jar name > > > > > > > > 4.0_1-SNAPSHOT > > > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > > > > > I'd NOT do a release or push to our snapshots repo until in about 2 > > > > weeks when the modus operandi is clear within the Jakarta community. > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau > > > > > : > > > > > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor version > > > > > =spec version > > > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau > > > > > a écrit : > > > > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit > > > > > : > > > > > The problem is that in a git repo you can only release all at once. > > > > > That means we would need to have a single git repo for each and every > > > > > spec. That will be quite many... > > > > > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > > > > > That said i proposed that exactly for that. At the end the release > > > > > process is more on jira dev etc, one or N repos does not compress > > > > > that time. Release prepare/perform is very fast on these repo so one > > > > > or 100 is likely the same for release manager and seems it will also > > > > > enable better osgi support and probably - hopefully - enable > > > > > servicemix to stop forking the for
Re: [DISCUSS] implement jakarta spec apis
Ok. Can we agree to take this discussion back and hold any release - no issue with snaps - until it is clarified? Le dim. 5 mai 2019 à 18:45, Mark Struberg a écrit : > I'm not even sure whether they yet got all the necessary IP to release > anything. > > LieGrue, > strub > > > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau >: > > > > > > > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : > > I'm not mandating jakarta in the groupId, but it should something else > than the current one. > > Because otw we would have them completely mixed up in the same folder. > That's not nice. > > > > Depends, that said happy to just replace specs by jakarta if it works > for you better (org.apache.geronimo.jakarta). I just dont want > jakarta-specs or _spec-xxx as before, always looked fishy and almost wrong > even if I get where it comes from. > > > > Btw, what is our status on having eclipse releasing api under asf2 > license? > > > > I dont want us to invest in something we drop like in 2 weeks and sounds > it can be for most of specs. Any page tracking that? > > > > > > LieGrue > > strub > > > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > We dont need jakarta in the gav at all. > > > > > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > > > > > As a reminder specs means jakarta already and there id jo ambiguity > between jakarta and javaee thanks the version. > > > > > > That said if we move to git it id even physically clearer. > > > > > > Finally servlet is a bad example cause owned at tomcat for apache i > think. We should absolutely stop duplicating them, it pollutes user land > for no gain IMHO. > > > > > > > > > > > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit > : > > > Eclipse itself probably doesn't yet have all the IP themselves. This > first needs to be clarified. Since all those legal questions have been > dealt with behind closed doors we simply have no idea. > > > > > > But we do have clean-room implemented APIs under ALv2 over here at > Geronimo. > > > And we can move this ourselves without having to wait for anybody. > > > > > > LieGrue, > > > strub > > > > > > > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels < > e...@zusammenkunft.net>: > > > > > > > > I wonder if you need that going forward for Jakarta Specs, they > could just be distributed by Eclipse directly? Having said that, if this is > not the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > > > > > > > -- > > > > http://bernd.eckenfels.net > > > > > > > > Von: Mark Struberg > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > > > An: geronimo-dev > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > > > > > For now I've used the following patterns: > > > > > > > > org.apache.geronimo.jakarta-specs > > > > because specs and jakarta-specs should be in a clearly separated > folder. > > > > > > > > geronimo-jakarta-servlet_spec > > > > because 'jakarta' should be in the jar name > > > > > > > > 4.0_1-SNAPSHOT > > > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > > > > > I'd NOT do a release or push to our snapshots repo until in about 2 > weeks when the modus operandi is clear within the Jakarta community. > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor > version =spec version > > > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau < > rmannibu...@gmail.com> a écrit : > > > > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a > écrit : > > > > > The problem is that in a git repo you can only release all at > once. That means we would need to have a single git repo for each and every > spec. That will be quite many... > > > > > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > > > > > That said i proposed that exactly for that. At the end the release > process is more on jira dev etc, one or N repos does not compress that > time. Release prepare/perform is very fast on these repo so one or 100 is > likely the same for release manager and seems it will also enable better > osgi support and probably - hopefully - enable servicemix to stop forking > the fork ;). > > > > > > > > > > I also see svn as legacy now gitbox is mainstream and people > contributing like to see their name in - I expect maybe some help for new > spec as we got for each new version. > > > > > Fixed are generally trivial there and a good reason to use github. > > > > > > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > > > > AFAIK we dont have limitations there and can do share stuff > outside with jgit - but it is very rare - so probably
Re: [DISCUSS] implement jakarta spec apis
I'm not even sure whether they yet got all the necessary IP to release anything. LieGrue, strub > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau : > > > > Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : > I'm not mandating jakarta in the groupId, but it should something else than > the current one. > Because otw we would have them completely mixed up in the same folder. That's > not nice. > > Depends, that said happy to just replace specs by jakarta if it works for you > better (org.apache.geronimo.jakarta). I just dont want jakarta-specs or > _spec-xxx as before, always looked fishy and almost wrong even if I get where > it comes from. > > Btw, what is our status on having eclipse releasing api under asf2 license? > > I dont want us to invest in something we drop like in 2 weeks and sounds it > can be for most of specs. Any page tracking that? > > > LieGrue > strub > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau : > > > > We dont need jakarta in the gav at all. > > > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > > > As a reminder specs means jakarta already and there id jo ambiguity between > > jakarta and javaee thanks the version. > > > > That said if we move to git it id even physically clearer. > > > > Finally servlet is a bad example cause owned at tomcat for apache i think. > > We should absolutely stop duplicating them, it pollutes user land for no > > gain IMHO. > > > > > > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : > > Eclipse itself probably doesn't yet have all the IP themselves. This first > > needs to be clarified. Since all those legal questions have been dealt with > > behind closed doors we simply have no idea. > > > > But we do have clean-room implemented APIs under ALv2 over here at Geronimo. > > And we can move this ourselves without having to wait for anybody. > > > > LieGrue, > > strub > > > > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels : > > > > > > I wonder if you need that going forward for Jakarta Specs, they could > > > just be distributed by Eclipse directly? Having said that, if this is not > > > the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > > > > -- > > > http://bernd.eckenfels.net > > > > > > Von: Mark Struberg > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > > An: geronimo-dev > > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > > > For now I've used the following patterns: > > > > > > org.apache.geronimo.jakarta-specs > > > because specs and jakarta-specs should be in a clearly separated folder. > > > > > > geronimo-jakarta-servlet_spec > > > because 'jakarta' should be in the jar name > > > > > > 4.0_1-SNAPSHOT > > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > > > I'd NOT do a release or push to our snapshots repo until in about 2 weeks > > > when the modus operandi is clear within the Jakarta community. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau > > > > : > > > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor version > > > > =spec version > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau > > > > a écrit : > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > > > > The problem is that in a git repo you can only release all at once. > > > > That means we would need to have a single git repo for each and every > > > > spec. That will be quite many... > > > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > > > That said i proposed that exactly for that. At the end the release > > > > process is more on jira dev etc, one or N repos does not compress that > > > > time. Release prepare/perform is very fast on these repo so one or 100 > > > > is likely the same for release manager and seems it will also enable > > > > better osgi support and probably - hopefully - enable servicemix to > > > > stop forking the fork ;). > > > > > > > > I also see svn as legacy now gitbox is mainstream and people > > > > contributing like to see their name in - I expect maybe some help for > > > > new spec as we got for each new version. > > > > Fixed are generally trivial there and a good reason to use github. > > > > > > > > > > > > LieGrue, > > > > strub > > > > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau > > > > > : > > > > > > > > > > AFAIK we dont have limitations there and can do share stuff outside > > > > > with jgit - but it is very rare - so probably sane to unify all repo > > > > > to git. In particular since we will not do all specs probably. Cxf > > > > > already moved to jakarta spec so we dont need jaxrs stack for > > > > > instance, same for cdi, bval,... So we wil reduce a lot what we fork > > > > > IMHO. > > > > > > > > > > Le sam. 4 mai
Re: [DISCUSS] implement jakarta spec apis
Le dim. 5 mai 2019 à 18:30, Mark Struberg a écrit : > I'm not mandating jakarta in the groupId, but it should something else > than the current one. > Because otw we would have them completely mixed up in the same folder. > That's not nice. > Depends, that said happy to just replace specs by jakarta if it works for you better (org.apache.geronimo.jakarta). I just dont want jakarta-specs or _spec-xxx as before, always looked fishy and almost wrong even if I get where it comes from. Btw, what is our status on having eclipse releasing api under asf2 license? I dont want us to invest in something we drop like in 2 weeks and sounds it can be for most of specs. Any page tracking that? > LieGrue > strub > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau >: > > > > We dont need jakarta in the gav at all. > > > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > > > As a reminder specs means jakarta already and there id jo ambiguity > between jakarta and javaee thanks the version. > > > > That said if we move to git it id even physically clearer. > > > > Finally servlet is a bad example cause owned at tomcat for apache i > think. We should absolutely stop duplicating them, it pollutes user land > for no gain IMHO. > > > > > > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : > > Eclipse itself probably doesn't yet have all the IP themselves. This > first needs to be clarified. Since all those legal questions have been > dealt with behind closed doors we simply have no idea. > > > > But we do have clean-room implemented APIs under ALv2 over here at > Geronimo. > > And we can move this ourselves without having to wait for anybody. > > > > LieGrue, > > strub > > > > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels >: > > > > > > I wonder if you need that going forward for Jakarta Specs, they could > just be distributed by Eclipse directly? Having said that, if this is not > the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > > > > -- > > > http://bernd.eckenfels.net > > > > > > Von: Mark Struberg > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > > An: geronimo-dev > > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > > > For now I've used the following patterns: > > > > > > org.apache.geronimo.jakarta-specs > > > because specs and jakarta-specs should be in a clearly separated > folder. > > > > > > geronimo-jakarta-servlet_spec > > > because 'jakarta' should be in the jar name > > > > > > 4.0_1-SNAPSHOT > > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > > > I'd NOT do a release or push to our snapshots repo until in about 2 > weeks when the modus operandi is clear within the Jakarta community. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor version > =spec version > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau < > rmannibu...@gmail.com> a écrit : > > > > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a > écrit : > > > > The problem is that in a git repo you can only release all at once. > That means we would need to have a single git repo for each and every spec. > That will be quite many... > > > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > > > That said i proposed that exactly for that. At the end the release > process is more on jira dev etc, one or N repos does not compress that > time. Release prepare/perform is very fast on these repo so one or 100 is > likely the same for release manager and seems it will also enable better > osgi support and probably - hopefully - enable servicemix to stop forking > the fork ;). > > > > > > > > I also see svn as legacy now gitbox is mainstream and people > contributing like to see their name in - I expect maybe some help for new > spec as we got for each new version. > > > > Fixed are generally trivial there and a good reason to use github. > > > > > > > > > > > > LieGrue, > > > > strub > > > > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > > AFAIK we dont have limitations there and can do share stuff > outside with jgit - but it is very rare - so probably sane to unify all > repo to git. In particular since we will not do all specs probably. Cxf > already moved to jakarta spec so we dont need jaxrs stack for instance, > same for cdi, bval,... So we wil reduce a lot what we fork IMHO. > > > > > > > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a > écrit : > > > > > I’d keep that in svn because of the tons of modules. > > > > > > > > > > Lg, > > > > > Strub > > > > > > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > > >> We mainly fork for legal reasons and defaults so name is probably > not critical w
Re: [DISCUSS] implement jakarta spec apis
I'm not mandating jakarta in the groupId, but it should something else than the current one. Because otw we would have them completely mixed up in the same folder. That's not nice. LieGrue strub > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau : > > We dont need jakarta in the gav at all. > > Why not org.apache.geronimo.spec:servlet:4.0.1? > > As a reminder specs means jakarta already and there id jo ambiguity between > jakarta and javaee thanks the version. > > That said if we move to git it id even physically clearer. > > Finally servlet is a bad example cause owned at tomcat for apache i think. We > should absolutely stop duplicating them, it pollutes user land for no gain > IMHO. > > > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : > Eclipse itself probably doesn't yet have all the IP themselves. This first > needs to be clarified. Since all those legal questions have been dealt with > behind closed doors we simply have no idea. > > But we do have clean-room implemented APIs under ALv2 over here at Geronimo. > And we can move this ourselves without having to wait for anybody. > > LieGrue, > strub > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels : > > > > I wonder if you need that going forward for Jakarta Specs, they could just > > be distributed by Eclipse directly? Having said that, if this is not the > > case I would at least remove „geronimo-“ from the artifact Id? > > > > > > -- > > http://bernd.eckenfels.net > > > > Von: Mark Struberg > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > An: geronimo-dev > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > For now I've used the following patterns: > > > > org.apache.geronimo.jakarta-specs > > because specs and jakarta-specs should be in a clearly separated folder. > > > > geronimo-jakarta-servlet_spec > > because 'jakarta' should be in the jar name > > > > 4.0_1-SNAPSHOT > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > I'd NOT do a release or push to our snapshots repo until in about 2 weeks > > when the modus operandi is clear within the Jakarta community. > > > > LieGrue, > > strub > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau > > > : > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor version > > > =spec version > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau a > > > écrit : > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > > > The problem is that in a git repo you can only release all at once. That > > > means we would need to have a single git repo for each and every spec. > > > That will be quite many... > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > That said i proposed that exactly for that. At the end the release > > > process is more on jira dev etc, one or N repos does not compress that > > > time. Release prepare/perform is very fast on these repo so one or 100 is > > > likely the same for release manager and seems it will also enable better > > > osgi support and probably - hopefully - enable servicemix to stop forking > > > the fork ;). > > > > > > I also see svn as legacy now gitbox is mainstream and people contributing > > > like to see their name in - I expect maybe some help for new spec as we > > > got for each new version. > > > Fixed are generally trivial there and a good reason to use github. > > > > > > > > > LieGrue, > > > strub > > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau > > > > : > > > > > > > > AFAIK we dont have limitations there and can do share stuff outside > > > > with jgit - but it is very rare - so probably sane to unify all repo to > > > > git. In particular since we will not do all specs probably. Cxf already > > > > moved to jakarta spec so we dont need jaxrs stack for instance, same > > > > for cdi, bval,... So we wil reduce a lot what we fork IMHO. > > > > > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a écrit : > > > > I’d keep that in svn because of the tons of modules. > > > > > > > > Lg, > > > > Strub > > > > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau > > > > : > > > > > > > >> We mainly fork for legal reasons and defaults so name is probably not > > > >> critical while we respect module names. > > > >> > > > >> Btw do we do it in gitbox? Svn had some limitations by the past for > > > >> contributions. > > > >> > > > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge a > > > >> écrit : > > > >> One thing to consider is there may be cases where it is desirable to > > > >> retain the javax API alongside some extra jakarta packages & types. > > > >> > > > >> For example, for JAX-RS you may wish to add some newly defined jakarta > > > >> types (part of a new spec) which interact over the original javax API. > > > >> > > > >> The result might be that "Jakarta EE
Re: [DISCUSS] implement jakarta spec apis
We dont need jakarta in the gav at all. Why not org.apache.geronimo.spec:servlet:4.0.1? As a reminder specs means jakarta already and there id jo ambiguity between jakarta and javaee thanks the version. That said if we move to git it id even physically clearer. Finally servlet is a bad example cause owned at tomcat for apache i think. We should absolutely stop duplicating them, it pollutes user land for no gain IMHO. Le dim. 5 mai 2019 à 16:28, Mark Struberg a écrit : > Eclipse itself probably doesn't yet have all the IP themselves. This first > needs to be clarified. Since all those legal questions have been dealt with > behind closed doors we simply have no idea. > > But we do have clean-room implemented APIs under ALv2 over here at > Geronimo. > And we can move this ourselves without having to wait for anybody. > > LieGrue, > strub > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels : > > > > I wonder if you need that going forward for Jakarta Specs, they could > just be distributed by Eclipse directly? Having said that, if this is not > the case I would at least remove „geronimo-“ from the artifact Id? > > > > > > -- > > http://bernd.eckenfels.net > > > > Von: Mark Struberg > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > > An: geronimo-dev > > Betreff: Re: [DISCUSS] implement jakarta spec apis > > > > For now I've used the following patterns: > > > > org.apache.geronimo.jakarta-specs > > because specs and jakarta-specs should be in a clearly separated folder. > > > > geronimo-jakarta-servlet_spec > > because 'jakarta' should be in the jar name > > > > 4.0_1-SNAPSHOT > > 4.0 is for servlet-4.0, 1 is the patch level. > > > > I'd NOT do a release or push to our snapshots repo until in about 2 > weeks when the modus operandi is clear within the Jakarta community. > > > > LieGrue, > > strub > > > > > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > Do we also want to clean our gav? Artifact=spec, major.minor version > =spec version > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau > a écrit : > > > > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit > : > > > The problem is that in a git repo you can only release all at once. > That means we would need to have a single git repo for each and every spec. > That will be quite many... > > > > > > No, maven plugins was a monorepo for years and then they split. > > > > > > That said i proposed that exactly for that. At the end the release > process is more on jira dev etc, one or N repos does not compress that > time. Release prepare/perform is very fast on these repo so one or 100 is > likely the same for release manager and seems it will also enable better > osgi support and probably - hopefully - enable servicemix to stop forking > the fork ;). > > > > > > I also see svn as legacy now gitbox is mainstream and people > contributing like to see their name in - I expect maybe some help for new > spec as we got for each new version. > > > Fixed are generally trivial there and a good reason to use github. > > > > > > > > > LieGrue, > > > strub > > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > > AFAIK we dont have limitations there and can do share stuff outside > with jgit - but it is very rare - so probably sane to unify all repo to > git. In particular since we will not do all specs probably. Cxf already > moved to jakarta spec so we dont need jaxrs stack for instance, same for > cdi, bval,... So we wil reduce a lot what we fork IMHO. > > > > > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a > écrit : > > > > I’d keep that in svn because of the tons of modules. > > > > > > > > Lg, > > > > Strub > > > > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > >> We mainly fork for legal reasons and defaults so name is probably > not critical while we respect module names. > > > >> > > > >> Btw do we do it in gitbox? Svn had some limitations by the past for > contributions. > > > >> > > > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge > a écrit : > > > >> One thing to consider is there may be cases where it is desirable > to retain the javax API alongside some extra jakarta packages & types. > > > >> > > > >> For example, for JAX-RS you may wish to add some newly defined > jakarta types (part of a new spec) which interact over the original javax > API. > > > >> > > > >> The result might be that "Jakarta EE REST" (a fictitious name for > next JAX-RS) might contain a subset of packages which, in combination with > JAXRS v2.1, also qualifies as "Jakarata EE Rest". > > > >> > > > >> - Ray > > > >> > > > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge < > raymond.a...@liferay.com> wrote: > > > >> so is this a matter of forking all the current specs into the new > namespace? Or is the intention to completely change the packages in-place? > >
Re: [DISCUSS] implement jakarta spec apis
Eclipse itself probably doesn't yet have all the IP themselves. This first needs to be clarified. Since all those legal questions have been dealt with behind closed doors we simply have no idea. But we do have clean-room implemented APIs under ALv2 over here at Geronimo. And we can move this ourselves without having to wait for anybody. LieGrue, strub > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels : > > I wonder if you need that going forward for Jakarta Specs, they could just be > distributed by Eclipse directly? Having said that, if this is not the case I > would at least remove „geronimo-“ from the artifact Id? > > > -- > http://bernd.eckenfels.net > > Von: Mark Struberg > Gesendet: Sonntag, Mai 5, 2019 4:09 PM > An: geronimo-dev > Betreff: Re: [DISCUSS] implement jakarta spec apis > > For now I've used the following patterns: > > org.apache.geronimo.jakarta-specs > because specs and jakarta-specs should be in a clearly separated folder. > > geronimo-jakarta-servlet_spec > because 'jakarta' should be in the jar name > > 4.0_1-SNAPSHOT > 4.0 is for servlet-4.0, 1 is the patch level. > > I'd NOT do a release or push to our snapshots repo until in about 2 weeks > when the modus operandi is clear within the Jakarta community. > > LieGrue, > strub > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau : > > > > Do we also want to clean our gav? Artifact=spec, major.minor version =spec > > version > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau a > > écrit : > > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > > The problem is that in a git repo you can only release all at once. That > > means we would need to have a single git repo for each and every spec. That > > will be quite many... > > > > No, maven plugins was a monorepo for years and then they split. > > > > That said i proposed that exactly for that. At the end the release process > > is more on jira dev etc, one or N repos does not compress that time. > > Release prepare/perform is very fast on these repo so one or 100 is likely > > the same for release manager and seems it will also enable better osgi > > support and probably - hopefully - enable servicemix to stop forking the > > fork ;). > > > > I also see svn as legacy now gitbox is mainstream and people contributing > > like to see their name in - I expect maybe some help for new spec as we got > > for each new version. > > Fixed are generally trivial there and a good reason to use github. > > > > > > LieGrue, > > strub > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau > > > : > > > > > > AFAIK we dont have limitations there and can do share stuff outside with > > > jgit - but it is very rare - so probably sane to unify all repo to git. > > > In particular since we will not do all specs probably. Cxf already moved > > > to jakarta spec so we dont need jaxrs stack for instance, same for cdi, > > > bval,... So we wil reduce a lot what we fork IMHO. > > > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a écrit : > > > I’d keep that in svn because of the tons of modules. > > > > > > Lg, > > > Strub > > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau > > > : > > > > > >> We mainly fork for legal reasons and defaults so name is probably not > > >> critical while we respect module names. > > >> > > >> Btw do we do it in gitbox? Svn had some limitations by the past for > > >> contributions. > > >> > > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge a > > >> écrit : > > >> One thing to consider is there may be cases where it is desirable to > > >> retain the javax API alongside some extra jakarta packages & types. > > >> > > >> For example, for JAX-RS you may wish to add some newly defined jakarta > > >> types (part of a new spec) which interact over the original javax API. > > >> > > >> The result might be that "Jakarta EE REST" (a fictitious name for next > > >> JAX-RS) might contain a subset of packages which, in combination with > > >> JAXRS v2.1, also qualifies as "Jakarata EE Rest". > > >> > > >> - Ray > > >> > > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge > > >> wrote: > > >> so is this a matter of forking all the current specs into the new > > >> namespace? Or is the intention to completely change the packages > > >> in-place? > > >> > > >> - Ray > > >> > > >> On Fri, May 3, 2019 at 1:58 PM Romain Manni-Bucau > > >> wrote: > > >> Hmm > > >> > > >> My understanding was it was getting under eclipse license as well and > > >> was fully donated but can have missed some details. > > >> > > >> If we cant reuse them let's just create new ones and fix module name for > > >> others. > > >> > > >> specs/ is fine since it is the same for us IMHO > > >> > > >> Le ven. 3 mai 2019 à 18:24, Mark Struberg a écrit : > > >> No, it is not the same. microprofile specs are licensed under AL
Re: [DISCUSS] implement jakarta spec apis
I wonder if you need that going forward for Jakarta Specs, they could just be distributed by Eclipse directly? Having said that, if this is not the case I would at least remove „geronimo-“ from the artifact Id? -- http://bernd.eckenfels.net Von: Mark Struberg Gesendet: Sonntag, Mai 5, 2019 4:09 PM An: geronimo-dev Betreff: Re: [DISCUSS] implement jakarta spec apis For now I've used the following patterns: org.apache.geronimo.jakarta-specs because specs and jakarta-specs should be in a clearly separated folder. geronimo-jakarta-servlet_spec because 'jakarta' should be in the jar name 4.0_1-SNAPSHOT 4.0 is for servlet-4.0, 1 is the patch level. I'd NOT do a release or push to our snapshots repo until in about 2 weeks when the modus operandi is clear within the Jakarta community. LieGrue, strub > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau : > > Do we also want to clean our gav? Artifact=spec, major.minor version =spec > version > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau a > écrit : > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > The problem is that in a git repo you can only release all at once. That > means we would need to have a single git repo for each and every spec. That > will be quite many... > > No, maven plugins was a monorepo for years and then they split. > > That said i proposed that exactly for that. At the end the release process is > more on jira dev etc, one or N repos does not compress that time. Release > prepare/perform is very fast on these repo so one or 100 is likely the same > for release manager and seems it will also enable better osgi support and > probably - hopefully - enable servicemix to stop forking the fork ;). > > I also see svn as legacy now gitbox is mainstream and people contributing > like to see their name in - I expect maybe some help for new spec as we got > for each new version. > Fixed are generally trivial there and a good reason to use github. > > > LieGrue, > strub > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau : > > > > AFAIK we dont have limitations there and can do share stuff outside with > > jgit - but it is very rare - so probably sane to unify all repo to git. In > > particular since we will not do all specs probably. Cxf already moved to > > jakarta spec so we dont need jaxrs stack for instance, same for cdi, > > bval,... So we wil reduce a lot what we fork IMHO. > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a écrit : > > I’d keep that in svn because of the tons of modules. > > > > Lg, > > Strub > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau : > > > >> We mainly fork for legal reasons and defaults so name is probably not > >> critical while we respect module names. > >> > >> Btw do we do it in gitbox? Svn had some limitations by the past for > >> contributions. > >> > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge a > >> écrit : > >> One thing to consider is there may be cases where it is desirable to > >> retain the javax API alongside some extra jakarta packages & types. > >> > >> For example, for JAX-RS you may wish to add some newly defined jakarta > >> types (part of a new spec) which interact over the original javax API. > >> > >> The result might be that "Jakarta EE REST" (a fictitious name for next > >> JAX-RS) might contain a subset of packages which, in combination with > >> JAXRS v2.1, also qualifies as "Jakarata EE Rest". > >> > >> - Ray > >> > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge > >> wrote: > >> so is this a matter of forking all the current specs into the new > >> namespace? Or is the intention to completely change the packages in-place? > >> > >> - Ray > >> > >> On Fri, May 3, 2019 at 1:58 PM Romain Manni-Bucau > >> wrote: > >> Hmm > >> > >> My understanding was it was getting under eclipse license as well and was > >> fully donated but can have missed some details. > >> > >> If we cant reuse them let's just create new ones and fix module name for > >> others. > >> > >> specs/ is fine since it is the same for us IMHO > >> > >> Le ven. 3 mai 2019 à 18:24, Mark Struberg a écrit : > >> No, it is not the same. microprofile specs are licensed under ALv2 and we > >> know all the legal details. > >> For the EE specs this is by far not the same. We don't even know exactly > >> what parts did yet get donated by Oracle to the EF. > >> > >> LieGrue, > >> strub > >> > >> > >> > Am 03.05.2019 um 18:12 schrieb Romain Manni-Bucau > >> > : > >> > > >> > Hi > >> > > >> > Idnt it the exact same as for microprofile? So we dont do? > >> > > >> > Le ven. 3 mai 2019 à 16:21, Mark Struberg a écrit : > >> > I've started tinkering something under specs/branches/jakarta. > >> > It's wip but have to rush out for a few hours now. > >> > Will continue later today. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > Am 03.05.2019 um 15:50 schrieb Mark Struberg : > >> > > > >> >
Re: [DISCUSS] implement jakarta spec apis
For now I've used the following patterns: org.apache.geronimo.jakarta-specs because specs and jakarta-specs should be in a clearly separated folder. geronimo-jakarta-servlet_spec because 'jakarta' should be in the jar name 4.0_1-SNAPSHOT 4.0 is for servlet-4.0, 1 is the patch level. I'd NOT do a release or push to our snapshots repo until in about 2 weeks when the modus operandi is clear within the Jakarta community. LieGrue, strub > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau : > > Do we also want to clean our gav? Artifact=spec, major.minor version =spec > version > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau a > écrit : > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > The problem is that in a git repo you can only release all at once. That > means we would need to have a single git repo for each and every spec. That > will be quite many... > > No, maven plugins was a monorepo for years and then they split. > > That said i proposed that exactly for that. At the end the release process is > more on jira dev etc, one or N repos does not compress that time. Release > prepare/perform is very fast on these repo so one or 100 is likely the same > for release manager and seems it will also enable better osgi support and > probably - hopefully - enable servicemix to stop forking the fork ;). > > I also see svn as legacy now gitbox is mainstream and people contributing > like to see their name in - I expect maybe some help for new spec as we got > for each new version. > Fixed are generally trivial there and a good reason to use github. > > > LieGrue, > strub > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau : > > > > AFAIK we dont have limitations there and can do share stuff outside with > > jgit - but it is very rare - so probably sane to unify all repo to git. In > > particular since we will not do all specs probably. Cxf already moved to > > jakarta spec so we dont need jaxrs stack for instance, same for cdi, > > bval,... So we wil reduce a lot what we fork IMHO. > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg a écrit : > > I’d keep that in svn because of the tons of modules. > > > > Lg, > > Strub > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau : > > > >> We mainly fork for legal reasons and defaults so name is probably not > >> critical while we respect module names. > >> > >> Btw do we do it in gitbox? Svn had some limitations by the past for > >> contributions. > >> > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge a > >> écrit : > >> One thing to consider is there may be cases where it is desirable to > >> retain the javax API alongside some extra jakarta packages & types. > >> > >> For example, for JAX-RS you may wish to add some newly defined jakarta > >> types (part of a new spec) which interact over the original javax API. > >> > >> The result might be that "Jakarta EE REST" (a fictitious name for next > >> JAX-RS) might contain a subset of packages which, in combination with > >> JAXRS v2.1, also qualifies as "Jakarata EE Rest". > >> > >> - Ray > >> > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge > >> wrote: > >> so is this a matter of forking all the current specs into the new > >> namespace? Or is the intention to completely change the packages in-place? > >> > >> - Ray > >> > >> On Fri, May 3, 2019 at 1:58 PM Romain Manni-Bucau > >> wrote: > >> Hmm > >> > >> My understanding was it was getting under eclipse license as well and was > >> fully donated but can have missed some details. > >> > >> If we cant reuse them let's just create new ones and fix module name for > >> others. > >> > >> specs/ is fine since it is the same for us IMHO > >> > >> Le ven. 3 mai 2019 à 18:24, Mark Struberg a écrit : > >> No, it is not the same. microprofile specs are licensed under ALv2 and we > >> know all the legal details. > >> For the EE specs this is by far not the same. We don't even know exactly > >> what parts did yet get donated by Oracle to the EF. > >> > >> LieGrue, > >> strub > >> > >> > >> > Am 03.05.2019 um 18:12 schrieb Romain Manni-Bucau > >> > : > >> > > >> > Hi > >> > > >> > Idnt it the exact same as for microprofile? So we dont do? > >> > > >> > Le ven. 3 mai 2019 à 16:21, Mark Struberg a écrit : > >> > I've started tinkering something under specs/branches/jakarta. > >> > It's wip but have to rush out for a few hours now. > >> > Will continue later today. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > Am 03.05.2019 um 15:50 schrieb Mark Struberg : > >> > > > >> > > hi folks! > >> > > > >> > > You might have read todays post from Mike Milinkovich. > >> > > > >> > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > >> > > > >> > > It basically says that Jakarta will not be able to change a single bit > >> > > in the current spec apis under the javax.* package. > >> > > Any change has to be done in a
Re: [DISCUSS] implement jakarta spec apis
Do we also want to clean our gav? Artifact=spec, major.minor version =spec version Ex: org.apache.geronimo.specs:jsp:2.1.1 Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau a écrit : > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg a écrit : > >> The problem is that in a git repo you can only release all at once. That >> means we would need to have a single git repo for each and every spec. That >> will be quite many... >> > > No, maven plugins was a monorepo for years and then they split. > > That said i proposed that exactly for that. At the end the release process > is more on jira dev etc, one or N repos does not compress that time. > Release prepare/perform is very fast on these repo so one or 100 is likely > the same for release manager and seems it will also enable better osgi > support and probably - hopefully - enable servicemix to stop forking the > fork ;). > > I also see svn as legacy now gitbox is mainstream and people contributing > like to see their name in - I expect maybe some help for new spec as we got > for each new version. > Fixed are generally trivial there and a good reason to use github. > > >> LieGrue, >> strub >> >> > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> > >> > AFAIK we dont have limitations there and can do share stuff outside >> with jgit - but it is very rare - so probably sane to unify all repo to >> git. In particular since we will not do all specs probably. Cxf already >> moved to jakarta spec so we dont need jaxrs stack for instance, same for >> cdi, bval,... So we wil reduce a lot what we fork IMHO. >> > >> > Le sam. 4 mai 2019 à 21:12, Mark Struberg a écrit : >> > I’d keep that in svn because of the tons of modules. >> > >> > Lg, >> > Strub >> > >> > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> > >> >> We mainly fork for legal reasons and defaults so name is probably not >> critical while we respect module names. >> >> >> >> Btw do we do it in gitbox? Svn had some limitations by the past for >> contributions. >> >> >> >> Le sam. 4 mai 2019 à 17:47, Raymond Auge a >> écrit : >> >> One thing to consider is there may be cases where it is desirable to >> retain the javax API alongside some extra jakarta packages & types. >> >> >> >> For example, for JAX-RS you may wish to add some newly defined jakarta >> types (part of a new spec) which interact over the original javax API. >> >> >> >> The result might be that "Jakarta EE REST" (a fictitious name for next >> JAX-RS) might contain a subset of packages which, in combination with JAXRS >> v2.1, also qualifies as "Jakarata EE Rest". >> >> >> >> - Ray >> >> >> >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge >> wrote: >> >> so is this a matter of forking all the current specs into the new >> namespace? Or is the intention to completely change the packages in-place? >> >> >> >> - Ray >> >> >> >> On Fri, May 3, 2019 at 1:58 PM Romain Manni-Bucau < >> rmannibu...@gmail.com> wrote: >> >> Hmm >> >> >> >> My understanding was it was getting under eclipse license as well and >> was fully donated but can have missed some details. >> >> >> >> If we cant reuse them let's just create new ones and fix module name >> for others. >> >> >> >> specs/ is fine since it is the same for us IMHO >> >> >> >> Le ven. 3 mai 2019 à 18:24, Mark Struberg a écrit >> : >> >> No, it is not the same. microprofile specs are licensed under ALv2 and >> we know all the legal details. >> >> For the EE specs this is by far not the same. We don't even know >> exactly what parts did yet get donated by Oracle to the EF. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >> > Am 03.05.2019 um 18:12 schrieb Romain Manni-Bucau < >> rmannibu...@gmail.com>: >> >> > >> >> > Hi >> >> > >> >> > Idnt it the exact same as for microprofile? So we dont do? >> >> > >> >> > Le ven. 3 mai 2019 à 16:21, Mark Struberg a >> écrit : >> >> > I've started tinkering something under specs/branches/jakarta. >> >> > It's wip but have to rush out for a few hours now. >> >> > Will continue later today. >> >> > >> >> > LieGrue, >> >> > strub >> >> > >> >> > >> >> > > Am 03.05.2019 um 15:50 schrieb Mark Struberg : >> >> > > >> >> > > hi folks! >> >> > > >> >> > > You might have read todays post from Mike Milinkovich. >> >> > > >> >> > > >> https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ >> >> > > >> >> > > It basically says that Jakarta will not be able to change a single >> bit in the current spec apis under the javax.* package. >> >> > > Any change has to be done in a different package. >> >> > > The Jakarta people over at Eclipse already did some voting and the >> new package name will be jakarta.* >> >> > > >> >> > > Thus I would like to recommend to use our IP clean geronimo-specs >> to setup a new project for the EE8 specs under the jakarta.* package name. >> >> > > >> >> > > I'll go forward and create a branch starting with the most >> important specs. >> >> > > >> >> > > Any feedback
