OpenSAML - Java compatibility (9, 10, 11?)

[Ian Young]

Sorry not to CC you on my previous reply, but it's below anyway.

Just to add to this:

I --- personally, this is not a project position --- would like us to be able to support the Java module path in the long run. That's not an easy thing to do, though, because of the way they have defined things. A lot of products which were invented long before the JPMS was will have some trouble fitting into the constraints that have been introduced, particularly around the way things need to be strictly partitioned between what were JAR artifacts. It remains to be seen, really, whether everyone will adopt the module system or whether instead it will just wither because too many things can't use it.

One aspect of this is that I'd be very surprised if OpenSAML was the only thing you'd hit problems with if you attempt to deploy things on the module path today. It may interest you to know that I surveyed all of the dependencies we ship with the IdP product, and other than our own components the only JAR which even has a reserved module names is Guava. Everything else is completely unaware of the module system and it's a toss-up whether they will work in that environment.

We know of a number of cases where the split package issue comes up in our code, which is one reason we don't support the module path at this point. You shouldn't expect that we will be able to address that soon. It _would_ nevertheless be useful for the longer term if you could open a JIRA case for the issue you've found so that we can make sure that we consider it for a future release.

https://issues.shibboleth.net/jira/projects/OSJ/

Cheers,

	-- Ian

> On 12 Oct 2018, at 16:49, Ian Young <ian at iay.org.uk> wrote:
> 
> 
> 
>> On 12 Oct 2018, at 15:43, Cristi Chircu <cristian.chircu at gmail.com <mailto:cristian.chircu at gmail.com>> wrote:
>> 
>> Hello everyone, 
>> 
>> I've been using OpenSAML 3.3.0  <https://mvnrepository.com/artifact/org.opensaml/opensaml-core/3.3.0>for a java 8 service provider and it made my life a lot easier (thanks for sharing, by the way :) ). 
>> Now I'm trying to upgrade to java 10 and it looks like I'm out of luck. When I try to deploy I get an exception: "java.lang.module.ResolutionException: Modules opensaml.saml.impl and opensaml.saml.api export package org.opensaml.saml.config to module jersey.client".
> 
> I'm guessing that you are trying to put OpenSAML on the Java module path rather than on the classpath. We don't support that at present.
> 
>> I've searched around for a bit and I can't seem to find clear information on your plans for newer java versions support.
> 
> We have a page describing our approach here:
> 
> https://wiki.shibboleth.net/confluence/display/DEV/Java+Modularity <https://wiki.shibboleth.net/confluence/display/DEV/Java+Modularity>
> 
> You will be aware that we recently released a new version of the Shibboleth IdP, and in conjunction with that a new version of OpenSAML. These versions include reserved module names for the various components, and it's _possible_ that may help with the issue you're seeing. As before, though, no guarantees at this stage because we don't support use of the module path yet (we're aware of some split packages, although I don't think the one you've come across was one I was aware of).
> 
> 
>> I would like to know when you are planning to release a version that works with java 11 (since it's the newest LTS version)
> 
> The IdP (which uses OpenSAML) works just fine under Java 11. Use the classpath, not the module path.
> 
> 
>> and what will your approach be regarding Oracles change to their release strategy (will you support all versions? will you support all LTS versions?). 
> 
> For more information:
> 
> https://wiki.shibboleth.net/confluence/display/DEV/Product+Platforms <https://wiki.shibboleth.net/confluence/display/DEV/Product+Platforms>
> 
> 
>     -- Ian
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20181012/31588793/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3870 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20181012/31588793/attachment.p7s>