users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Social Media presence for Soteria

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 2 Feb 2016 14:40:55 +0100

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