Not sure, who is (from a rights or team point) able to do that on java.net?
Kind Regards,
Werner
On Wed, Feb 3, 2016 at 3:24 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> On Wed, Feb 3, 2016 at 2:36 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
>
>> Btw, although we have that image of Duke with the sword used by the JSR
>> in many cases, maybe the ancient godess Soteria could offer inspiration for
>> a dedicated RI logo: https://en.wikipedia.org/wiki/Soteria_(mythology)
>> >Soteria was depicted as a woman wearing a laurel wreath
>> <https://en.wikipedia.org/wiki/Laurel_wreath> crown, a symbol of victory.
>>
>> Let's see, maybe we could get JDuchess (after all Soteria was a
>> goddess;-) to wear a laurel wreath crown instead of that hair ribbon?
>>
>
> +1 would be cool. If someone feels inspired to set up a bare
> homepage/project page specifically for the RI, kinda like
> https://ozark.java.net, please go ahead ;)
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>>
>> Cheers,
>>
>> Werner
>>
>> On Wed, Feb 3, 2016 at 1:55 PM, Werner Keil <werner.keil_at_gmail.com>
>> wrote:
>>
>>> Alex,
>>>
>>> That's OK, thanks for letting us know. I hope it gets accepted (again,
>>> after at least 2 DevoXX, 1 JavaOne and a codemotion talk last year;-)
>>>
>>> Will (either by myself or with other EG members) also propose it for one
>>> or the other codemotion, Java Forum in Stuttgart (very close) and Geecon.
>>> The codemotion in Amsterdam could also be a chance to meet Arjan in
>>> person and (should others also attend) have a European F2F meeting.
>>>
>>> Kind Regards,
>>>
>>> Werner
>>>
>>> On Wed, Feb 3, 2016 at 2:48 AM, Alex Kosowski <alex.kosowski_at_oracle.com>
>>> wrote:
>>>
>>>> Hi Werner,
>>>>
>>>> Unfortunately, I will not be presenting at DevoXX this year. Have fun!
>>>>
>>>> With regards,
>>>> Alex
>>>>
>>>> On 2/2/16, 7:42 PM, Werner Keil wrote:
>>>>
>>>> Alex/all,
>>>>
>>>> I just used the final day of the DevoXX UK CFP to propose something for
>>>> DevoXX UK again, too.
>>>> I noticed almost half the EG (Adam, Ivar even with 2 entries, David and
>>>> Alex) available as potential co-speakers.
>>>> This may be based on current proposals, but also possible, it's simply
>>>> based on last year's speakers, since e.g. Chris Senior and Leo who
>>>> presented JSR 363 are also in that list.
>>>>
>>>> I added Ivar as co-speaker, knowing he may have proposed something else
>>>> there and he was at 3 DevoXX events alone last year from what I recall.
>>>> I don't want to add everyone, especially not if they're not likely to
>>>> get travel (as it happened with 2 co-speakers in Antwerp)
>>>>
>>>> Better submit it now while CFP is still on. I hope it does not overlap
>>>> too much with any other proposal?
>>>>
>>>> Cheers,
>>>> Werner
>>>>
>>>> On Tue, Feb 2, 2016 at 2:40 PM, Werner Keil <werner.keil_at_gmail.com>
>>>> wrote:
>>>>
>>>>> That might work.
>>>>>
>>>>> The groupId and artifactId should probably be different, but for a
>>>>> general structure to start the RI with it sounds OK.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
>>>>> Eclipse UOMo Lead, Babel Language Champion | Apache Committer
>>>>>
>>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @DeviceMap
>>>>> | #DevOps | #EclipseUOMo
>>>>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>>>>
>>>>> On Tue, Feb 2, 2016 at 1:18 PM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, Feb 2, 2016 at 11:16 AM, Werner Keil <werner.keil_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Yeah, for some reasons JSF even bundles the API with its RI, so I
>>>>>>> really would not use that as a good example either ;-)
>>>>>>>
>>>>>>
>>>>>> No, indeed. The reason is that the API is not really a pure API, but
>>>>>> contains a lot of code. API classes like UIComponent contain half of the
>>>>>> framework, but that bridge was crossed a long time ago. Only way out would
>>>>>> be to create a new partially incompatible JSF.next, but to include that in
>>>>>> Java EE would mean a third MVC framework, which seems... unlikely.
>>>>>>
>>>>>>
>>>>>>> If there's "api" and "api-spec" it does sound quite confusing.
>>>>>>> Beside the question of a parent POM there would be nothing wrong keeping
>>>>>>> the "api-upstream" module in a
>>>>>>> https://github.com/javaee-security-spec/soteria repo.
>>>>>>>
>>>>>>
>>>>>> You mean
>>>>>>
>>>>>> *https://github.com/javaee-security-spec/soteria/api
>>>>>> <https://github.com/javaee-security-spec/soteria/api>*
>>>>>>
>>>>>> *https://github.com/javaee-security-spec/soteria/impl
>>>>>> <https://github.com/javaee-security-spec/soteria/impl> *
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> It can al ways be swapped for the official one later. If you prefer
>>>>>>> a separate API repo to work with, I guess that might also be OK, especially
>>>>>>> as long as there's no content in the other one.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>>
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>> On Tue, Feb 2, 2016 at 10:44 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Feb 2, 2016 at 9:45 AM, Werner Keil <werner.keil_at_gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Keeping API and implementation in the same codebase is pretty much
>>>>>>>>> what Spring does everywhere ;-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> It's also what JSF does :P See
>>>>>>>> https://github.com/javaserverfaces/mojarra
>>>>>>>>
>>>>>>>> But... the Mojarra project and frankly JSF itself has many issues
>>>>>>>> in the API/impl department, so I wouldn't want to take that as an example.
>>>>>>>>
>>>>>>>> So what about
>>>>>>>>
>>>>>>>> https://github.com/javaee-security-spec/soteria
>>>>>>>> https://github.com/javaee-security-spec/api
>>>>>>>>
>>>>>>>> ?
>>>>>>>>
>>>>>>>> It's perhaps slightly confusing having a /api while there's also
>>>>>>>> /spec-api
>>>>>>>>
>>>>>>>> An alternative:
>>>>>>>>
>>>>>>>> https://github.com/javaee-security-spec/soteria
>>>>>>>> https://github.com/javaee-security-spec/api-upstream
>>>>>>>>
>>>>>>>> So then /api-upstream is where the real development takes places.
>>>>>>>> At important milestones (edr1, edr2, final, etc) this can be synched to
>>>>>>>> java.net where it would represent the truth. And then java.net
>>>>>>>> synched back to /spec-api to have a mirror of the truth.
>>>>>>>>
>>>>>>>> Would that work for everyone?
>>>>>>>>
>>>>>>>> In Mojarra we also have a 3 step setup, but slightly different:
>>>>>>>>
>>>>>>>> Real development (for me) takes place in my "feature branch repo":
>>>>>>>> https://github.com/arjantijms/mojarra
>>>>>>>> This gets synched to java.net for the truth:
>>>>>>>> https://java.net/projects/mojarra/sources/git/show
>>>>>>>> Which gets synched back to Github since that's what everyone uses:
>>>>>>>> https://github.com/javaserverfaces/mojarra
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> The EDR pattern of MVC looks like this:
>>>>>>>>> http://mvnrepository.com/artifact/javax.mvc/javax.mvc-api
>>>>>>>>> Similar to the template we got under the "api" space.
>>>>>>>>>
>>>>>>>>> Not sure, if you plan to define the new RI repo under a group like
>>>>>>>>> "org.glassfish.soteria" (maybe Alex can advise on that, the package
>>>>>>>>> structure already is that way) but the MVC RI POM looks reasonable:
>>>>>>>>> https://github.com/spericas/ozark/blob/master/pom.xml
>>>>>>>>> Especially the java.net parent POM.
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>> On Tue, Feb 2, 2016 at 12:57 AM, arjan tijms <
>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Alex,
>>>>>>>>>>
>>>>>>>>>> First of all great to see you back here, it has been a while!
>>>>>>>>>>
>>>>>>>>>> Thanks for the owner role :) I'll leave the other repos as they
>>>>>>>>>> are, and will just create the soteria repo. It's likely easiest to keep the
>>>>>>>>>> API in the same repo for now, and split it later once we figure out how to
>>>>>>>>>> push to Maven central using the correct group and artefact ids.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Arjan Tijms
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Feb 2, 2016 at 12:32 AM, Alex Kosowski <
>>>>>>>>>> alex.kosowski_at_oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Arjan,
>>>>>>>>>>>
>>>>>>>>>>> I added you as "owner" role (i.e. admin) in the organization
>>>>>>>>>>> https://github.com/orgs/javaee-security-spec.
>>>>>>>>>>>
>>>>>>>>>>> Please feel free to add/modify repos as required.
>>>>>>>>>>>
>>>>>>>>>>> I ask that you do not change
>>>>>>>>>>> https://github.com/javaee-security-spec/spec-api, which is a
>>>>>>>>>>> mirror of git://java.net/javaee-security-spec~spec-api
>>>>>>>>>>> <http://java.net/javaee-security-spec%7Espec-api>. Per Oracle,
>>>>>>>>>>> the "source of truth" of released artifacts need to be in
>>>>>>>>>>> java.net, and the mirror facilitates accessibility within
>>>>>>>>>>> GitHub. Also, please do not change the Bots team. So, once we complete and
>>>>>>>>>>> "release" the EDR, we would need to copy it to java.net.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for your contributions to the JSR!
>>>>>>>>>>>
>>>>>>>>>>> With regards,
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/1/16, 10:28 AM, Alex Kosowski wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Not a problem. Let me take a look.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>> On 2/1/16, 6:23 AM, Werner Keil wrote:
>>>>>>>>>>>
>>>>>>>>>>> You'd have to ask David or Alex (depending on who is more
>>>>>>>>>>> responsive right now?;-) but I'd say, at the very least you could/should be
>>>>>>>>>>> an admin if that's used by the organization or otherwise also made
>>>>>>>>>>> co-owner.
>>>>>>>>>>> I have a similar role in JSR 354 (as I helped create it like
>>>>>>>>>>> David did here), so that's not reserved to Spec Leads alone.
>>>>>>>>>>>
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Feb 1, 2016 at 12:19 PM, arjan tijms <
>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Okay, cool, so if either of them could make me an owner too, OR
>>>>>>>>>>>> create that soteria repo, then I can copy the code to there. After the
>>>>>>>>>>>> version can become edr1-alpha1 or something, We can then increase the
>>>>>>>>>>>> alphaX versions until we do the actual EDR submission.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Feb 1, 2016 at 12:11 PM, Werner Keil <
>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, according to GitHub only Alex and David are owners, so
>>>>>>>>>>>>> either of them could add such repo;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Feb 1, 2016 at 12:01 PM, arjan tijms <
>>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Feb 1, 2016 at 11:48 AM, Werner Keil <
>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> P.s.: IMHO the "edr1" should not be part of the artifactId,
>>>>>>>>>>>>>>> it's clearly a part of the version number.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess it is, but shouldn't soteria then not become it's own
>>>>>>>>>>>>>> top level repo? E.g.
>>>>>>>>>>>>>> https://github.com/javaee-security-spec/soteria
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One of the reasons I went with edr1 in the artifact name for
>>>>>>>>>>>>>> now (I knows it's not ideal and should be changed) is that the version as
>>>>>>>>>>>>>> set in Maven would best be aligned with the git tag, but if you do that
>>>>>>>>>>>>>> know the entire
>>>>>>>>>>>>>> https://github.com/javaee-security-spec/javaee-security-proposals
>>>>>>>>>>>>>> repo would get that tag. The authentication/authorization etc folders are
>>>>>>>>>>>>>> independent of that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So maybe we could have 2 Maven modules under "
>>>>>>>>>>>>>>> soteria-proposal" or similar and simply call them "
>>>>>>>>>>>>>>> javax.security-api:security-api" (in the API project the
>>>>>>>>>>>>>>> artifactId also contains the "javax" part, not sure, if other EE JSRs do
>>>>>>>>>>>>>>> that also on MavenCentral?) as well as "
>>>>>>>>>>>>>>> net.java.jsr375:soteria" for now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Something like "EDR1" "B01" or similar should only be in the
>>>>>>>>>>>>>>> version number.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Feb 1, 2016 at 11:38 AM, Werner Keil <
>>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At least Reza is very eager blogging all the time, maybe he
>>>>>>>>>>>>>>>> could help us with some of the things like updating RI list, etc.?;-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Feb 1, 2016 at 11:36 AM, Werner Keil <
>>>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sounds great, thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If anybody has enough rights in JIRA we could schedule
>>>>>>>>>>>>>>>>> these accordingly and define at least "versions" for each of these EDR and
>>>>>>>>>>>>>>>>> other steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I noticed, the larger Glassfish community has also not
>>>>>>>>>>>>>>>>> been updated for 3 years now (guess Oracle is not so interested in
>>>>>>>>>>>>>>>>> Glassfish now after all? ;-|)
>>>>>>>>>>>>>>>>> https://glassfish.java.net/rel-projects.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> MVC and JSR 375 RIs should be listed there and if there is
>>>>>>>>>>>>>>>>> a CI server instance for Glassfish or related projects, we should try to
>>>>>>>>>>>>>>>>> run those on a CI build, too.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Known public CI servers like Travis or Circle-CI would
>>>>>>>>>>>>>>>>> also work if we had to do this on our own.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Feb 1, 2016 at 12:43 AM, arjan tijms <
>>>>>>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Sun, Jan 31, 2016 at 8:28 PM, Werner Keil <
>>>>>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ideally we should keep API/Spec (it's simply Asciidoc
>>>>>>>>>>>>>>>>>>> like JSR 354) and RI separate.
>>>>>>>>>>>>>>>>>>> Snapshot repos are fine, we used JFrog OSS with JSRs 354
>>>>>>>>>>>>>>>>>>> or 363 but Sonatype is just as good (possibly easier to get it to
>>>>>>>>>>>>>>>>>>> MavenCentral then)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Indeed, we went specifically for that with Sonatype for
>>>>>>>>>>>>>>>>>> OmniFaces.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> From a process point we have up to 1 year from the
>>>>>>>>>>>>>>>>>>> Renewal Ballot, but of course it's always better to produce something
>>>>>>>>>>>>>>>>>>> earlier. Could always do EDR2 or more similar to MVC and others.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yeah, I think it's best we do something like that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> EDR1 is then roughly;
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Authentication Mechanism base API
>>>>>>>>>>>>>>>>>> * Several implementations of authentication mechanisms
>>>>>>>>>>>>>>>>>> * Two mechanism interceptors; auto session and remember me
>>>>>>>>>>>>>>>>>> * Identity store base API
>>>>>>>>>>>>>>>>>> * Several implementations of identity stores
>>>>>>>>>>>>>>>>>> * Standard Principal for the caller (used by JSR 375 at
>>>>>>>>>>>>>>>>>> least, standardising this for the entire platform will be bigger task)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For EDR2 to consider:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Multi authentication mechanism proposal from Darran
>>>>>>>>>>>>>>>>>> * Multi identity store proposal from Rudy
>>>>>>>>>>>>>>>>>> * Security context
>>>>>>>>>>>>>>>>>> * Security interceptor proposal from Reza et all
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For EDR3 to consider:
>>>>>>>>>>>>>>>>>> * Mandating containers doing 1:1 role mapping (we can't
>>>>>>>>>>>>>>>>>> really implement this using public APIs, but RI could do it using GlassFish
>>>>>>>>>>>>>>>>>> specific code)
>>>>>>>>>>>>>>>>>> * web.xml integration/alignment
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> There's (much) more on the TODO list like events,
>>>>>>>>>>>>>>>>>> password aliasing and more, but the above may be a guideline on how to
>>>>>>>>>>>>>>>>>> proceed.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Sun, Jan 31, 2016 at 5:47 PM, arjan tijms <
>>>>>>>>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Okay, so that remains an open question.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Meanwhile I've done a quick snapshot upload here using
>>>>>>>>>>>>>>>>>>>> our omnnifaces groupId:
>>>>>>>>>>>>>>>>>>>> https://oss.sonatype.org/content/repositories/snapshots/org/omnifaces/soteria-edr1/1.0-SNAPSHOT/
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I made some choices with regard to naming and
>>>>>>>>>>>>>>>>>>>> organisation here.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Both API and impl. are in the same Maven module, just
>>>>>>>>>>>>>>>>>>>> as two different packages. MVC has the API as a separate artefact in a
>>>>>>>>>>>>>>>>>>>> separate repo, with the implementation depending on that. JSF however has
>>>>>>>>>>>>>>>>>>>> api and impl as two folders in one larger project. Once the API is a little
>>>>>>>>>>>>>>>>>>>> bit more stable and we can more easily upload both artefacts under their
>>>>>>>>>>>>>>>>>>>> own groupIds, we should do the separation I guess.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I also named the artefact "soteria-edr1" for now. It
>>>>>>>>>>>>>>>>>>>> could have been just soteria with "edr1" as the version number. For now I
>>>>>>>>>>>>>>>>>>>> thought it was easier and clearer to have a separate edr1 folder, and then
>>>>>>>>>>>>>>>>>>>> later have an edr2 etc, but we can change this of course. I just had to
>>>>>>>>>>>>>>>>>>>> pick something for now.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I'll test a little with the snapshot and can do a Maven
>>>>>>>>>>>>>>>>>>>> central upload using the omnifaces groupId for the short term. This would
>>>>>>>>>>>>>>>>>>>> make it easier for people to at least try out the code in their own test
>>>>>>>>>>>>>>>>>>>> projects.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>>>> Arjan
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Sun, Jan 31, 2016 at 5:17 PM, Werner Keil <
>>>>>>>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Not sure, who in the EG can do that, at least someone
>>>>>>>>>>>>>>>>>>>>> had to request upload privileges to MavenCentral for a groupId like
>>>>>>>>>>>>>>>>>>>>> org.glassfish.soteria and of course for javax.security.* too, otherwise it
>>>>>>>>>>>>>>>>>>>>> won't build ;-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Sat, Jan 30, 2016 at 12:49 AM, arjan tijms <
>>>>>>>>>>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2016 at 6:31 PM, Werner Keil <
>>>>>>>>>>>>>>>>>>>>>> werner.keil_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So along the lines of MVC it should be
>>>>>>>>>>>>>>>>>>>>>>> package org.glassfish.soteria;
>>>>>>>>>>>>>>>>>>>>>>> then ;-)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I just did the initial commit for the work in
>>>>>>>>>>>>>>>>>>>>>> progress EDR1:
>>>>>>>>>>>>>>>>>>>>>> https://github.com/javaee-security-spec/javaee-security-proposals/commit/e482ba6580072ad82413a80c40e7d3112b83119a
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The implementation package is org.glassfish.soteria ;)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Please in the proposals repo try to use the license
>>>>>>>>>>>>>>>>>>>>>>> header plugin.
>>>>>>>>>>>>>>>>>>>>>>> Looking at e.g. JAX-RS, the header spans across
>>>>>>>>>>>>>>>>>>>>>>> multiple years for some JSRs (probably will be for MVC if they do something
>>>>>>>>>>>>>>>>>>>>>>> again)
>>>>>>>>>>>>>>>>>>>>>>> Copyright (c) 2010-2015 Oracle and/or its
>>>>>>>>>>>>>>>>>>>>>>> affiliates. All rights reserved.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I had already copied the header manually to the API
>>>>>>>>>>>>>>>>>>>>>> files, but I'll try the license plug-in header next.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For promotion it would be cool if we can publish the
>>>>>>>>>>>>>>>>>>>>>> work in progress EDR1 jar to Maven central so people can more easily try it
>>>>>>>>>>>>>>>>>>>>>> out.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Right now the license plugin as of last year only
>>>>>>>>>>>>>>>>>>>>>>> uses the inception year (from the POM) but "currentYear" is also available.
>>>>>>>>>>>>>>>>>>>>>>> If you want I can run the license reformatting at any time when things are
>>>>>>>>>>>>>>>>>>>>>>> changed.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2016 at 6:18 PM, arjan tijms <
>>>>>>>>>>>>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Great :)
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I'll do the package renaming tonight or tomorrow at
>>>>>>>>>>>>>>>>>>>>>>>> the latest and commit the whole to the proposals repo.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 29, 2016 at 9:08 AM, Rudy De Busscher <
>>>>>>>>>>>>>>>>>>>>>>>> rdebusscher_at_gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> All,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I created the Twitter account @Soteria_RI to
>>>>>>>>>>>>>>>>>>>>>>>>> promote the RI and evangelise Java EE Security in general.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> best regards
>>>>>>>>>>>>>>>>>>>>>>>>> Rudy
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>