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

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

Will

On 11/30/2017 02:27 PM, Arjan Tijms wrote:

Hi,

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.

Kind regards,

Arjan Tijms

On Thursday, November 30, 2017, Guillermo González de Agüero <z06.guillermo@...> wrote:

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.

Regards,

Guillermo González de Agüero

El mié., 29 nov. 2017 a las 17:39, Arjan Tijms (<arjan.tijms@...>) escribió:

Hi,

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

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.

Kind regards,
Arjan Tijms

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803