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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>