Hi,
It's a question what's going to happen with all the various artifacts
hosted for the JSR, both on java.net but perhaps also on GitHub.
For java.net we're mostly using the JIRA instance and the mailing list.
What will they be replaced with? And IFF they will be replaced with
something, will history be preserved?
For Github we're now using the "working repo section" of
github.com/javaee-security-spec, namely
github.com/javaee-security-spec/soteria
With java.net disappearing and (hopefully) the repos being moved, it may
not be unthinkable that the existing GitHub repos may be re-organized in
some way as well. Does anyone know if this will indeed happen? If so, maybe
it's a better idea to fork /soteria to some other account and sync that
with github.com/javaee-security-spec/soteria? Or just everyone forks
/soteria to their own accounts on GitHub and we'll do PRs all the time
(this may be a better way of working anyway).
Kind regards,
Arjan Tijms
On Thu, Apr 28, 2016 at 12:54 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Dear Experts,
>
> As you have probably seen java.net hosting for all projects but a few
> (maybe the "umbrella" GlassFish and likely OpenJDK are preserved in a
> different place, e.g. OpenJDK and JSR 376/Jigsaw already use "
> bugs.java.com" rather than JIRA at java.net;-) are going away from
> java.net within a year.
> Given the last code contribution in the API section (by Alex) was nearly a
> year ago, and we have barely heard from him since, it is impossible, JSR
> 375 (or Java EE 8, take alone the Java SE 9 roadmap hopes to get IT final
> around the same time) can be final before this deadline.
>
>
> Therefore Oracle itself has nullified the constraints
> Mirroring from java.net
>
> The specification must originate from java.net per Oracle policy. To
> enable use of the facilities of GitHub, the java.net repository is
> periodically mirrored into a GitHub repository. The corresponding GitHub
> repository is effectively "read only".
> from the README on https://github.com/javaee-security-spec/spec-api
>
> Unlike all other JSRs (even 373 - Java EE Management aims to replace or
> refurbish JSR 77 owned by Oracle, there is not a single item in JIRA or a
> code repository for 373, so currently it's dead and Oracle may well
> withdraw it if they have no resources or interest in this area;-) under the
> EE 8 umbrella, this JSR is a total "green field" development. There may be
> things to reuse from Java EE like Principal or annotations and other
> existing types from javax.security, but the codebase starts from zero.
> Oracle's "IP" in the api/spec repository are dummy classes like
> https://github.com/javaee-security-spec/spec-api/blob/master/api/src/main/java/javax/security/Placeholder.java
>
> So the IP argument does not apply to this JSR. If this JSR fails, then the
> existing pseudo-standards (like Spring Security, etc.) will continue to
> flourish making it hard or impossible for projects and companies to switch
> or combine them with one another.
>
> I already mentioned (see
> https://jcp.org/aboutJava/communityprocess/ec-public/materials/2016-04-05/April-2016-Public-Minutes.html)
> that https://jcp.org/en/procedures/jcp2_9#1.2 contains 1.2.4 in the
> recent (applicable) version of the JCP process document where three members
> of an EG like this may ask the EC to have an unresponsive or inactive Spec
> Lead replaced (usually by someone else in the EG, but of course the Spec
> Lead company Oracle could have the first choice offering somebody else if
> they can and want to)
>
> Those who met him know, Alex is a nice guy and it certainly isn't his
> decision or fault here, but if we don't act fast enough in such a
> situation, the entire JCP will become irrelevant or a laughing stock of the
> industry soon ;-O
> I was at a local MeetUp where beside Docker another "vendor-driven
> standard" was presented: http://graphql.org/. Facebook single-handedly
> defined a spec for it in about a year, but they offer others to help:
> http://graphql.org/help/ 35 people, many of them outside Facebook have
> contributed to its spec: https://github.com/facebook/graphql, they simply
> issued a PR. That's how standards are driven now by Facebook, Twitter,
> Google or even Microsoft (and they also use Github or support Apache
> projects in a "post Ballmer" world;-)
>
> Happy to hear your thoughts. If at least 2 or 3 EG members felt they
> already wanted to address the EC now, please speak up. Otherwise this and
> other JSRs will certainly be discussed in May at the EC F2F and related JUG
> event.
> It actually seems, Alex did work on "his own" API which is where most code
> was contributed. I did not look into greater detail, but right now we got
> at least
>
> - An empty https://github.com/javaee-security-spec/spec-api
> - A working subset of the API in
> https://github.com/javaee-security-spec/soteria/tree/master/api
> - A pretty rich number of proposals, partially overlapping or forked
> into Soteria
> - A very early approach in
> https://github.com/alexkosowski/javaee-security-spec--spec-api (the
> Spec part is empty, just placeholders, the API seems rudimentary and much
> of what's now gone into Soteria was derived from the "playground" or other
> repositories including Arjan's and a few other's)
>
> So we got quite a "mess" even inside the JSR that must be consolidated and
> polished towards a possible EDR 1 (what's done in Soteria would be more
> than enough to be called EDR 1 comparing to say MVC and others)
>
> Judging from commits, Arjan would clearly qualify as a new Spec Lead or Co
> Spec Lead if a sharing model could be found (and look at e.g. 107 or 363
> not all Spec Leads contribute the same at all times) next probably David if
> he had the time for it (he already got responsibilities with TomEE or
> Tomitribe) I am a Co Spec Lead, so until JSR 363 goes final, I would not
> want to volunteer for another even Co Spec Lead role, but I'm more than
> happy to help with what I've done so far as spokesperson at conferences and
> also a share of actual code commits or advise and input on design, helping
> with the spec, etc. or EC/process related things.
>
> 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
>
>
> ---------- Forwarded message ----------
> From: Werner Keil <werner.keil_at_gmail.com>
> Date: Wed, Apr 27, 2016 at 6:45 PM
> Subject: Fwd: Java.net and Kenai.com forges closing
> To: "experts_at_unitsofmeasurement.java.net" <
> experts_at_unitsofmeasurement.java.net>
>
>
> Dear Experts,
>
> For your info.
> We are well prepared. The only relevant artifact are downloads of e.g. the
> Spec which is also made available on jcp.org for important stages (and
> before the end of 2016 JSR 363 should be final based on our current plan
> and effort)
>
> If this mailing list goes away, hope the archive won't otherwise we'd have
> to use Google Groups for that, too. Again technically after a JSR is final
> there IS no EG, so the other two lists will do.
>
> We'll ask soon enough to have the old java.net project redirected to the
> GitHub one, that should last for a very long time (even SourceForge is
> still around, only Oracle or Google shut theirs down;-)
>
> Regards,
>
> Werner
>
>
> ---------- Forwarded message ----------
> From: Sonya Barry <sonya.barry_at_oracle.com>
> Date: Wed, Apr 27, 2016 at 6:35 PM
> Subject: Java.net and Kenai.com forges closing
> To:
>
>
> Hello,
>
> You are receiving this note because you are an administrator on at least
> one project hosted on Java.net or Kenai.com.
>
> We will be closing both websites on April 28, 2017. You may request a
> tarball of your project assets and get instructions to download a copy of
> your bugs here:
> https://community.oracle.com/community/java/javanet-forge-sunset
>
> You may also request a redirect to a new homepage of your choice.
>
> Please note that we will be honoring one request per project, on a first
> come, first served basis. Once a request is made any changes to the
> project will be lost. If you share administrator access with other members
> you must coordinate with them on a plan of action before making your
> request. All communications from us will be to all project administrators
> once this process begins.
>
> Finally, the old Java.net home page redirects to
> community.oracle.com/community/java now. If you need to log in to
> Java.net you can do so at https://java.net/people/login.
>
> If you have any questions please ask in the discussion area of the request
> page here -
> https://community.oracle.com/community/java/javanet-forge-sunset, or
> send a note to communitymanager_at_java.net.
>
> Thanks,
>
> Sonya Barry
> Director, Community Infrastructure
>
>
>
>