users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Fwd: Java.net and Kenai.com forges closing

From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 28 Apr 2016 12:54:45 +0200

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