You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2018/07/01 07:40:18 UTC
SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Hi guys,
I've been a bit silent those last days, being stuck with loads of work
and parenting tasks...
I will try to get the site updated tonite (EU time) with SCIMple on it.
I will do that on the staging site, so you can provide some feedback
before we publish the site to the world. We may need some blurb of
information to introduce the project, but this can be done next week.
Otherwise, the APache LDAP API 2.0 is on its way, I have fixed a long
lasting ticket about reshuffling the error/messages numbering - quite a
pain in the back...- and I still have a pending issue in ApacheDS with
this revision : one failing test, related to using teh
DelegatingAuthenticator, when using startTLS. It's complicated, because
it involves a client (the LDAP API), a server, which talks to another
server using the LDAP API, and MINA. Of course to muddy the thing, there
are connection timeout issues - a bug I fixed and I still have to commit -.
Once I get ApacheDS compiling with no error, I will be able to cut the
LDAP API release and ApacheDS release, something much wanted for Studio.
This release will be a major step forwards, so it's important to have it
working fine.
Last, not least, it's probably time to try to have all thos projects
working fine with the latest Java version (and specificlly with Java 11
which will be the LTS version). We have more and more people
complainging about issues with those versions, but I o think it's not an
enormous tasks we have in front of us.
Feel free to comment !
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/07/2018 à 22:52, Smith, Shawn E a écrit :
> Thanks Emmanuel. I've started closing old completed issues in the current repository and will migrate those that are left. We should be able to get the code moved over in the next day or two as well.
>
>
> Would it be preferable to put the Apache license comments in before we migrate? I'd rather do any required package naming changes after the move so that we don't potentially break people who are currently using it.
No, but it has to be done before the first release. Same for package
renaming.
>
>
> And one last question, is it alright to change the README on the Penn State SCIMple site to start pushing traffic to the Apache repo as soon as it is moved, or are there other intermediate steps we should take?
I guess it would be a good move.
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by "Smith, Shawn E" <se...@psu.edu>.
Thanks Emmanuel. I've started closing old completed issues in the current repository and will migrate those that are left. We should be able to get the code moved over in the next day or two as well.
Would it be preferable to put the Apache license comments in before we migrate? I'd rather do any required package naming changes after the move so that we don't potentially break people who are currently using it.
And one last question, is it alright to change the README on the Penn State SCIMple site to start pushing traffic to the Apache repo as soon as it is moved, or are there other intermediate steps we should take?
Shawn
________________________________
From: Stefan Seelmann <ma...@stefan-seelmann.de>
Sent: Tuesday, July 3, 2018 4:35:53 PM
To: dev@directory.apache.org
Subject: Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
On 07/02/2018 07:58 PM, Stefan Seelmann wrote:
> Thanks Emmanuel!
>
> On 07/02/2018 03:30 PM, Emmanuel Lécharny wrote:
>> ApacheDS :
>> ----------
>>
>> - I have fixed the failing startTLS test (which was in fact an LDAP API
>> error : the SslFilter was not added to the chain)
>> - ApacheDS is now building fine
>>
>> I think I will start to cut a release of the Apache LDAP API 2.0.0-AM1
>> (first milestone before a release) and a ApachedS 2.0.0-AM25. I just
>> have to test if Studio works fine with both those guys. Will do that one
>> of those coming evenings, when teh baby will sleep ;-)
>
> I can help with testing Studio.
Good news, all Studio tests are back to stable so I'm pretty confident
that everything is fine. Good job, Emmanuel!
I'll try to test Studio with Java 11 and check if it makes sense to
upgrade from Oxygen to Photon right now.
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/07/2018 à 22:35, Stefan Seelmann a écrit :
> On 07/02/2018 07:58 PM, Stefan Seelmann wrote:
>> Thanks Emmanuel!
>>
>> On 07/02/2018 03:30 PM, Emmanuel Lécharny wrote:
>>> ApacheDS :
>>> ----------
>>>
>>> - I have fixed the failing startTLS test (which was in fact an LDAP API
>>> error : the SslFilter was not added to the chain)
>>> - ApacheDS is now building fine
>>>
>>> I think I will start to cut a release of the Apache LDAP API 2.0.0-AM1
>>> (first milestone before a release) and a ApachedS 2.0.0-AM25. I just
>>> have to test if Studio works fine with both those guys. Will do that one
>>> of those coming evenings, when teh baby will sleep ;-)
>>
>> I can help with testing Studio.
>
> Good news, all Studio tests are back to stable so I'm pretty confident
> that everything is fine. Good job, Emmanuel!
Great !
>
> I'll try to test Studio with Java 11 and check if it makes sense to
> upgrade from Oxygen to Photon right now.
Okie. FTR, I have tested photon last week-end, and I'm not totally
pleased with the way it delas with loaded projects, when they are built
outside: it's quite a pain in the back to get them rebuilt properly in
eclipse (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=536592)
Otherwise, i'm trying to bump up maven plugins version in 'project', and
all works fine except for teh osgi tests that take forever (like 10 mins
instead of 1) when using a surefire plugin version > 1.19.1. Obviously,
they have chenged something that makes the tests to slow down terribly
(I suspect they have added some 'cleanup' tasks that weren't present
before, becuase the tests themselves are only taking 2 and a half
second). I will most certainly keep going with 2.19.1 for the OSGi tests.
Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 07/02/2018 07:58 PM, Stefan Seelmann wrote:
> Thanks Emmanuel!
>
> On 07/02/2018 03:30 PM, Emmanuel Lécharny wrote:
>> ApacheDS :
>> ----------
>>
>> - I have fixed the failing startTLS test (which was in fact an LDAP API
>> error : the SslFilter was not added to the chain)
>> - ApacheDS is now building fine
>>
>> I think I will start to cut a release of the Apache LDAP API 2.0.0-AM1
>> (first milestone before a release) and a ApachedS 2.0.0-AM25. I just
>> have to test if Studio works fine with both those guys. Will do that one
>> of those coming evenings, when teh baby will sleep ;-)
>
> I can help with testing Studio.
Good news, all Studio tests are back to stable so I'm pretty confident
that everything is fine. Good job, Emmanuel!
I'll try to test Studio with Java 11 and check if it makes sense to
upgrade from Oxygen to Photon right now.
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Thanks Emmanuel!
On 07/02/2018 03:30 PM, Emmanuel Lécharny wrote:
> ApacheDS :
> ----------
>
> - I have fixed the failing startTLS test (which was in fact an LDAP API
> error : the SslFilter was not added to the chain)
> - ApacheDS is now building fine
>
> I think I will start to cut a release of the Apache LDAP API 2.0.0-AM1
> (first milestone before a release) and a ApachedS 2.0.0-AM25. I just
> have to test if Studio works fine with both those guys. Will do that one
> of those coming evenings, when teh baby will sleep ;-)
I can help with testing Studio.
But I assume there will be problems with the ApacheDS version number in
Studio, especially with updateing the Studio plugin, because the bundle
version 2.0.0.AM25 is smaller than the previous 2.0.0.M24. I'd suggest
to go back to the old naming schema for ApacheDS.
Kind Regards,
Stefan
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi guys,
a quick update :
SCIMple :
---------
- the SCIMple basic we site is done
(http://directory.staging.apache.org/scimple)
- the SCIMple JIRA space has been created
(https://issues.apache.org/jira/projects/SCIMPLE), an I have made Shawn
Smith admin of this space
ApacheDS :
----------
- I have fixed the failing startTLS test (which was in fact an LDAP API
error : the SslFilter was not added to the chain)
- ApacheDS is now building fine
I think I will start to cut a release of the Apache LDAP API 2.0.0-AM1
(first milestone before a release) and a ApachedS 2.0.0-AM25. I just
have to test if Studio works fine with both those guys. Will do that one
of those coming evenings, when teh baby will sleep ;-)
Thanks !
On 2018/07/01 07:40:18, Emmanuel Lécharny <e....@gmail.com> wrote:
> Hi guys,
>
>
>
> I've been a bit silent those last days, being stuck with loads of work
>
> and parenting tasks...
>
>
>
> I will try to get the site updated tonite (EU time) with SCIMple on
> it.
>
> I will do that on the staging site, so you can provide some feedback>
> before we publish the site to the world. We may need some blurb of
> information to introduce the project, but this can be done next week.
>
>
> Otherwise, the APache LDAP API 2.0 is on its way, I have fixed a long
> lasting ticket about reshuffling the error/messages numbering - quite
> a pain in the back...- and I still have a pending issue in ApacheDS
> with this revision : one failing test, related to using teh
> DelegatingAuthenticator, when using startTLS. It's complicated,
> because it involves a client (the LDAP API), a server, which talks to
> another server using the LDAP API, and MINA. Of course to muddy the
> thing, there are connection timeout issues - a bug I fixed and I still
> have to commit -.
>
> Once I get ApacheDS compiling with no error, I will be able to cut the
> LDAP API release and ApacheDS release, something much wanted for
> Studio. This release will be a major step forwards, so it's important
> to have it working fine.
>
> Last, not least, it's probably time to try to have all thos projects
> working fine with the latest Java version (and specificlly with Java
> 11 which will be the LTS version). We have more and more people
> complainging about issues with those versions, but I o think it's not
> an enormous tasks we have in front of us.
>
> Feel free to comment !
>
> Thanks !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache
LDAP 2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 09/07/2018 à 15:28, Radovan Semancik a écrit :
>> One last solution : pass a flag (like 'MUTE_WARNINGS') to the API while
>> processing a schema, and have something like :
>>
>> if ( LOG.isWarnEnabled() && !muteWarnings )
>> {
>> LOG.warn( msg );
>> }
>>
>> We would initiate the flag when instanciating the registries:
>>
>> public Registries( boolean muteWarnings )
>> {
>> globalOidRegistry = new OidRegistry<>();
>> attributeTypeRegistry = new DefaultAttributeTypeRegistry(
>> muteWarnings );
>> comparatorRegistry = new DefaultComparatorRegistry(
>> muteWarnings );
>> ...
>> }
>>
>> Whatever works, just suggesting an alternative idea, not pretending it's
>> better, but offering options.
>
> I think the flag is redundant. Setting a listener to non-null value will
> do the same trick:
>
> if (errorListener == null) {
> LOG.warn( msg );
> } else {
> errorListener.accept(msg);
> }
Which is not different from
if ( !muteWarnings && LOG.isWarnEnabled() )
{
LOG.warn( msg );
}
You have to define the errorListener somwhere, as you have to set the
muteWarnings. This can be done at teh same place, propagated to the
registry.
The difference is that the muteRegistry is really limited in
functionality, while the listener *may* handle more things (like, you
may define a ADListener that will keep some warnings, but that would be
a bit complex to handle, as you must have some knowledge about the
warnings you want to keep).
All in all, you can't really decouple the warning you want to produce
from the pace in the code it's produced, so that could lead to things like :
String msg = I18n.err( I18n.ERR_13733_ARG_NOT_NUMERIC_OID );
if ( listener instanceof ADListener )
{
LOG.trace( msg ); // We don't want to be flooded with logs in AD
}
else if ( listener instanceof OPENLDAPListener
{
LOG.error( msg ); // OpenLDAP is stricter
}
else
{
LOG.warn( msg ); // Default mode
}
and that for each specific message...
Unless you want to be global, and make the listener globally push AD
logs to TRACE (and eventually get them ignored because the default log
level is INFO, which means your approach works.
>> 2.0.0-AM1 is pretty much done. I intend to cut a release this week, so I
>> guess it's a bit late to introduce such a change, except if you think
>> you can cut it very quickly. To be franck, I've a lot to do on my day
>> job atm, and the baby is draining the remaining energy I have, so I was
>> planning to cut this release this week-end, so that leave you some room
>> for such a change. We just have to be sure that does not break the
>> server, but I don't think I can't fix any breakage there in more than a
>> couple of hours. Same for studio.
>
> I'm not sure either. But I'll try on Wednesday or Thursday. If I can't
> make it I just won't merge the changes to master and it won't be in AM1.
> It looks like we can make this change compatible with previous API, so
> probably no problem there
Sure, please do your experiments in a branch, so that I can play with it
asap.
>
>> Bottom line, this is not such a big change, if properly handled - and I
>> trust your skill here :-) -
>
> Thank you. I'll try to to live up to expectations :-)
I always set my expectations as high as my level of competence. Which is
fine for 90% of the developpers on this planet. I'm pretty sure you can
pass this bar easily ;-)
>> Java 11 is going t be out in 2 months and a half. We already have some
>> early-access versions (http://jdk.java.net/11/) and I know that The ASF
>> has already configured Jenkins to support Java 11.
>
> I think I'll be a bit conservative here and wait for Java 11 release. I
> know that Oracle has made promises. But please forgive me if I'm not
> entirely ready to believe :-)
> I'm quite happy with Java 8 for API 2.0.
Me too. Many others too. And Oracle new policy (ie, let the Java users
dead in the water very fast, forcing them to either pay the Oracle taxe
- and it's a freaking heavy one !!! -, or switch to a newest version
every year, is pretty likely to kill Java in the coming years. Unless
you are ready to keep going with OpenJDK.
That makes me think we should start basing our developments and tests on
OpenJDK rather on an Oracle JDK... But that is another discussion to have !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache
LDAP 2.0, and Java 9/10/11
Posted by Radovan Semancik <ra...@evolveum.com>.
On 07/09/2018 02:54 PM, Emmanuel Lécharny wrote:
> I guess most of the errors are produced by the
> DefaultSchemaObjectRegistry class.
>
> If so, I wonder if a more simple solution would'nt be to create a
> specific Logger for such a thing as AD, and configure the property file
> to mute the other loggers. OTOH, that would require to either tune the
> property file *before* connecting to an AD server (and that means we
> *know* we are talking to such a turd), or that we programatically
> configure the logger (which might not be easy considering we use a
> facade like slf4j).
Exactly. That's what I thought. And also won't work if you want to
connect to nice LDAP and naughty LDAP at the same time. Loggers are
essentially singletons. So unless someone invents quantum logger they
cannot be both on on off at the same time :-)
> Now, using a listener solve both drawbacks, we just have to pay the
> price of an indirection (ok, I assume it's not a terrible big deal), and
> to have a way to configure this listener.
We have to pay the price only if the listener is configured. Otherwise
we will just pay price of "if (listener != null) {}" check. Not a bad
price to pay for getting rid of complaints about AD schema errors.
> One last solution : pass a flag (like 'MUTE_WARNINGS') to the API while
> processing a schema, and have something like :
>
> if ( LOG.isWarnEnabled() && !muteWarnings )
> {
> LOG.warn( msg );
> }
>
> We would initiate the flag when instanciating the registries:
>
> public Registries( boolean muteWarnings )
> {
> globalOidRegistry = new OidRegistry<>();
> attributeTypeRegistry = new DefaultAttributeTypeRegistry(
> muteWarnings );
> comparatorRegistry = new DefaultComparatorRegistry( muteWarnings );
> ...
> }
>
> Whatever works, just suggesting an alternative idea, not pretending it's
> better, but offering options.
I think the flag is redundant. Setting a listener to non-null value will
do the same trick:
if (errorListener == null) {
LOG.warn( msg );
} else {
errorListener.accept(msg);
}
I have do dig deeper in the code to figure out how to hide this in some
superclass or util class, so we won't repeat the code everywhere. But I
think this could work. And in fact, it may even be a compatible API change.
> The XXXRegistry classes are not to be used from external callers. The
> Registries class can be extended, by adding a parameter, and the
> constructor with no parameter will simply works as designed initally.
> This would change the API ina very minimal way (being compatible with
> teh current version)
Oh yes. That may be the way. Good idea.
> 2.0.0-AM1 is pretty much done. I intend to cut a release this week, so I
> guess it's a bit late to introduce such a change, except if you think
> you can cut it very quickly. To be franck, I've a lot to do on my day
> job atm, and the baby is draining the remaining energy I have, so I was
> planning to cut this release this week-end, so that leave you some room
> for such a change. We just have to be sure that does not break the
> server, but I don't think I can't fix any breakage there in more than a
> couple of hours. Same for studio.
I'm not sure either. But I'll try on Wednesday or Thursday. If I can't
make it I just won't merge the changes to master and it won't be in AM1.
It looks like we can make this change compatible with previous API, so
probably no problem there.
> Bottom line, this is not such a big change, if properly handled - and I
> trust your skill here :-) -
Thank you. I'll try to to live up to expectations :-)
> If you come to realize it's going to be a bigger breakage than what I
> think, then I'd rather call for a 3.0. IMO, 2.0 is almost dne, and I'm
> willing to move to a faster numbering release, à la Chrome/Firefox. Ie,
> instead of cutting some 2.0.1, 2.1.0 etc, I'd ratcher go for 3.0/4.0/5.0
> etc...
Oh good. I like faster versioning. Let's see how the change looks like
when I'm done. I'll keep it on a branch. It is not really critical do
get it in 2.0 if 3.0 will be released soon enough.
> Java 11 is going t be out in 2 months and a half. We already have some
> early-access versions (http://jdk.java.net/11/) and I know that The ASF
> has already configured Jenkins to support Java 11.
I think I'll be a bit conservative here and wait for Java 11 release. I
know that Oracle has made promises. But please forgive me if I'm not
entirely ready to believe :-)
I'm quite happy with Java 8 for API 2.0.
--
Radovan Semancik
Software Architect
evolveum.com
LDAP 2.0 and beyond, was : Re: SCIMple, current state of Apache LDAP
2.0, and Java 9/10/11
Posted by Emmanuel Lécharny <el...@gmail.com>.
<changing the title for clarity>
Le 09/07/2018 à 13:46, Radovan Semancik a écrit :
> Hi,
>
> On 07/01/2018 09:40 AM, Emmanuel Lécharny wrote:
>> Otherwise, the APache LDAP API 2.0 is on its way, I have fixed a long
>> lasting ticket about reshuffling the error/messages numbering - quite a
>> pain in the back...- and I still have a pending issue in ApacheDS with
>> this revision : one failing test, related to using teh
>> DelegatingAuthenticator, when using startTLS. It's complicated, because
>> it involves a client (the LDAP API), a server, which talks to another
>> server using the LDAP API, and MINA. Of course to muddy the thing, there
>> are connection timeout issues - a bug I fixed and I still have to
>> commit -.
>
> I'm planning to change the way how schema errors are handled in API 2.0
> devel cycle. The problem is that there are popular LDAP servers with
> really bad schema (e.g. AD).
How surprising !!!
And in that case the LDAP API floods the
> logfiles with warnings. I would like to make this behavior configurable,
> provide "listener" for errors or do something like that.
That seems reasonnable.
I guess most of the errors are produced by the
DefaultSchemaObjectRegistry class.
If so, I wonder if a more simple solution would'nt be to create a
specific Logger for such a thing as AD, and configure the property file
to mute the other loggers. OTOH, that would require to either tune the
property file *before* connecting to an AD server (and that means we
*know* we are talking to such a turd), or that we programatically
configure the logger (which might not be easy considering we use a
facade like slf4j).
Now, using a listener solve both drawbacks, we just have to pay the
price of an indirection (ok, I assume it's not a terrible big deal), and
to have a way to configure this listener.
One last solution : pass a flag (like 'MUTE_WARNINGS') to the API while
processing a schema, and have something like :
if ( LOG.isWarnEnabled() && !muteWarnings )
{
LOG.warn( msg );
}
We would initiate the flag when instanciating the registries:
public Registries( boolean muteWarnings )
{
globalOidRegistry = new OidRegistry<>();
attributeTypeRegistry = new DefaultAttributeTypeRegistry(
muteWarnings );
comparatorRegistry = new DefaultComparatorRegistry( muteWarnings );
...
}
Whatever works, just suggesting an alternative idea, not pretending it's
better, but offering options.
But
> implementing that properly is likely to introduce non-compatible changes
> to SchemaManager and surrounding classes.
The XXXRegistry classes are not to be used from external callers. The
Registries class can be extended, by adding a parameter, and the
constructor with no parameter will simply works as designed initally.
This would change the API ina very minimal way (being compatible with
teh current version)
I think I have proposed this
> change some time ago and we have decided to wait for 2.0. So now I would
> like to implement it. Emmanuel, please let me know whether it is right
> time to do it now. I would not like to clash with your changes.
2.0.0-AM1 is pretty much done. I intend to cut a release this week, so I
guess it's a bit late to introduce such a change, except if you think
you can cut it very quickly. To be franck, I've a lot to do on my day
job atm, and the baby is draining the remaining energy I have, so I was
planning to cut this release this week-end, so that leave you some room
for such a change. We just have to be sure that does not break the
server, but I don't think I can't fix any breakage there in more than a
couple of hours. Same for studio.
Bottom line, this is not such a big change, if properly handled - and I
trust your skill here :-) -
If you come to realize it's going to be a bigger breakage than what I
think, then I'd rather call for a 3.0. IMO, 2.0 is almost dne, and I'm
willing to move to a faster numbering release, à la Chrome/Firefox. Ie,
instead of cutting some 2.0.1, 2.1.0 etc, I'd ratcher go for 3.0/4.0/5.0
etc...
>
>> Last, not least, it's probably time to try to have all thos projects
>> working fine with the latest Java version (and specificlly with Java 11
>> which will be the LTS version). We have more and more people
>> complainging about issues with those versions, but I o think it's not an
>> enormous tasks we have in front of us.
>
> I would test API with Java 11, once Java 11 is released.
Java 11 is going t be out in 2 months and a half. We already have some
early-access versions (http://jdk.java.net/11/) and I know that The ASF
has already configured Jenkins to support Java 11.
I would say : the faster, the better, but of course, this is depending
on teh will of volunters... And we are not many :-)
Ideally speaking, I'd like to have the API ready before Java 11 is out.
Not sure we will be heavilly impacted. Anyway, I'm going to give it a
try in agust.
But as for Java
> 9 and 10 we are ignoring them completely.
Java 9/10? What is that ?
Therefore I won't be able to
> help with those.
Me neither ;-)
Many thanks, Radovan !
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: SCIMple, current state of Apache LDAP 2.0, and Java 9/10/11
Posted by Radovan Semancik <ra...@evolveum.com>.
Hi,
On 07/01/2018 09:40 AM, Emmanuel Lécharny wrote:
> Otherwise, the APache LDAP API 2.0 is on its way, I have fixed a long
> lasting ticket about reshuffling the error/messages numbering - quite a
> pain in the back...- and I still have a pending issue in ApacheDS with
> this revision : one failing test, related to using teh
> DelegatingAuthenticator, when using startTLS. It's complicated, because
> it involves a client (the LDAP API), a server, which talks to another
> server using the LDAP API, and MINA. Of course to muddy the thing, there
> are connection timeout issues - a bug I fixed and I still have to commit -.
I'm planning to change the way how schema errors are handled in API 2.0
devel cycle. The problem is that there are popular LDAP servers with
really bad schema (e.g. AD). And in that case the LDAP API floods the
logfiles with warnings. I would like to make this behavior configurable,
provide "listener" for errors or do something like that. But
implementing that properly is likely to introduce non-compatible changes
to SchemaManager and surrounding classes. I think I have proposed this
change some time ago and we have decided to wait for 2.0. So now I would
like to implement it. Emmanuel, please let me know whether it is right
time to do it now. I would not like to clash with your changes.
> Last, not least, it's probably time to try to have all thos projects
> working fine with the latest Java version (and specificlly with Java 11
> which will be the LTS version). We have more and more people
> complainging about issues with those versions, but I o think it's not an
> enormous tasks we have in front of us.
I would test API with Java 11, once Java 11 is released. But as for Java
9 and 10 we are ignoring them completely. Therefore I won't be able to
help with those.
--
Radovan Semancik
Software Architect
evolveum.com