Access to the branches shouldn't be an issue -- I can open it up or
merge changes as needed.
More of a problem is publishing to maven.java.net. I don't know how
to get the maven release plugin to do point releases, and the manual
tweaking required even with the release plugin is non trivial (since
it doesn't update everything you'd want it to).
I've been thinking it might be easier to just tweak release numbers
manually, and publish directly, but I haven't yet taken the time to
figure out how to do that. It probably just requires invoking the
right targets/goals, but a simple deploy won't be enough -- the jars
need to be signed, or they won't upload to maven.java.net.
I will say that, while we could theoretically make changes to the
existing repo(s), folks here would prefer we don't, because it
creates a moving target for migration.
An independent library is also an option; the issue there is making
sure the IP can be cleanly contributed back to EE4J. IP ownership
needs to be clear, and the owner needs to be willing/able to
If we're talking about RI-only changes, and if time is really that
critical, the best approach might be to work in the existing soteria
repo. But if we can wait until after the holidays, we might have a
clearer picture about when we could get into Eclipse and publish
On 11/30/2017 02:27 PM, Arjan Tijms
There’s some things that could indeed go into an extended RI,
but the API is just as frozen for the RI as for others.
I don’t know at this point if it’s possible to release new RI
versions easily. I’m still locked out from the Soteria master
and I certainly don’t have the credentials required to do a
Soteria release anymore.
That’s a bit of an issue. For my or our own library I can
commit to master and I would not be locked out, plus I can do
Maven (central) releases for that.
That’s a very big advantage for an own independent library.
On Thursday, November 30, 2017, Guillermo González de Agüero
While I see the point of the independent library, I
still advocate for a good RI that goes beyond the spec. A
3rd party library reaches more people, but what's the
benefit of having 5 different implementations that don't
go beyond the spec, and then a library that provides extra
funcionality for every implementation?
IBM and more than probably RedHat will go with their
independent implementations, and they will try to make
them better than the others. Why should we do the same?
The RI is just another implementation. Weld or Jersey are
good examples of RIs that experiment and provide extra
features. I think we could do the same with Soteria.
Guillermo González de Agüero
El mié., 29 nov. 2017 a las 17:39,
Arjan Tijms (<arjan.tijms@...
First of all thanks for the reply, good to see you
here again ;)
There's some things that are best changed in the
API, specifically the CDI 2.0 inspired annotation
instances/builders. If I'm not mistaken, CDI 1.2 and
JSF 2.1 (two MRs done outside Java EE) could not
been officially included into Java EE 7 resp EE 6
either, but many vendors choose to include these
Private modifications to the RI are probably not so
nice in this case, as it concerns things that should
be available everywhere, so also on Liberty.
There's an amount of RI implementation things to be
done though, basically just small bugs. There's a
bug where the URL attribute of the ldap store was
accidentally left constant, and I think there's a
NPE somewhere if the password is left blank in the
BASIC mechanism. My guess would be that those things
would be relatively easy to do; release a Soteria
1.0.1 with just bug fixes.
Unless a MR can still be done, maybe the best way
forward is to incubate the mentioned changes in an
OmniFaces like library, perhaps OmniJSR375 or so.
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803