[DISCUSS] ConnId restructuring (including full OpenICF compatibility)

[Francesco Chicchiriccò]

Hi all,
today I had a nice chat with Radovan Semancik from idPoint [1], an Open
Source IdM.

As you can read from their website, they are currently relying upon
OpenICF [2] for actual provisioning towards external resources.
Moreover, as you might already know, OpenICF is a sort of ConnId
"bother" project since we both forked the original Sun Microsystem's
IdentityConnectors project [3].

Basically, Radovan and I have been discussing about the possibility of a
joint effort for merging the OpenICF features and enhancements into
ConnId (this is completely allowed by the shared license CDDL).

With more detail:

1. some guys from Evolveum (including Radovan) will join this ML,
create accounts on JIRA and Confluence and get write access to github
repositories

2. this ML will be used to coordinate all the activities, to discuss
relevant topics and to make decisions about releases

3. the initial task of this restructuring will involve taking the
current OpenICF source tree and merging together ConnId's and OpenICF's
modifications to the original source tree into a single coherent set;
this work is likely to be done in a separate branch on github that will
be eventually merged with master, once the restructuring is complete

4. once completed (3), we will also need to keep periodically in sync
our repos with OpenICF's - this task might not be trivial since they are
still on SVN [4]

WDYT?

[1] http://www.evolveum.com/midpoint.php
[2] http://openicf.forgerock.org/
[3] https://java.net/projects/identityconnectors/
[4] https://svn.forgerock.org/openicf/

--
Francesco Chicchiricc�

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[Colm O hEigeartaigh]

+1.

Colm.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

--
You received this message because you are subscribed to the Google Groups "connid-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+unsubscribe@googlegroups.com.
Visit this group at http://groups.google.com/group/connid-dev?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[Fabio Martelli]

Il giorno 22/apr/2013, alle ore 12.38, Francesco Chicchiriccò ha scritto:

> Hi all,
> today I had a nice chat with Radovan Semancik from idPoint [1], an Open Source IdM.
>
> As you can read from their website, they are currently relying upon OpenICF [2] for actual provisioning towards external resources.
> Moreover, as you might already know, OpenICF is a sort of ConnId "bother" project since we both forked the original Sun Microsystem's IdentityConnectors project [3].
>
> Basically, Radovan and I have been discussing about the possibility of a joint effort for merging the OpenICF features and enhancements into ConnId (this is completely allowed by the shared license CDDL).
>
> With more detail:
>
> 1. some guys from Evolveum (including Radovan) will join this ML, create accounts on JIRA and Confluence and get write access to github repositories
>
> 2. this ML will be used to coordinate all the activities, to discuss relevant topics and to make decisions about releases
>
> 3. the initial task of this restructuring will involve taking the current OpenICF source tree and merging together ConnId's and OpenICF's modifications to the original source tree into a single coherent set; this work is likely to be done in a separate branch on github that will be eventually merged with master, once the restructuring is complete
>
> 4. once completed (3), we will also need to keep periodically in sync our repos with OpenICF's - this task might not be trivial since they are still on SVN [4]
>
> WDYT?

Really really interesting. I do think that ConnId can only benefit from this.

+1 for me.

>
> [1] http://www.evolveum.com/midpoint.php
> [2] http://openicf.forgerock.org/
> [3] https://java.net/projects/identityconnectors/
> [4] https://svn.forgerock.org/openicf/
>
> --

> Francesco Chicchiriccò

>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
>

> --
> You received this message because you are subscribed to the Google Groups "connid-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+...@googlegroups.com.

[Marco Di Sabatino Di Diodoro]

Good idea

+1 

Marco

To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+...@googlegroups.com.

Visit this group at http://groups.google.com/group/connid-dev?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Dott. Marco Di Sabatino Di Diodoro

mdisabatin...@gmail.com

[Massimiliano Perrone]

+1 of course.

>
> [1] http://www.evolveum.com/midpoint.php
> [2] http://openicf.forgerock.org/
> [3] https://java.net/projects/identityconnectors/
> [4] https://svn.forgerock.org/openicf/
>


--

Massimiliano Perrone
Tel +39 393 9121310

Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Apache Syncope PMC Member
http://people.apache.org/~massi/

"L'apprendere molte cose non insegna l'intelligenza"
(Eraclito)

[Francesco Chicchiriccò]

On 22/04/2013 12:38, Francesco Chicchiricc� wrote:

Well, it seems we have some consensus here: Radovan, how should we
proceed now?

Regards.

[Radovan Semancik]

On 04/23/2013 08:54 AM, Francesco Chicchiriccò wrote:
> Well, it seems we have some consensus here: Radovan, how should we
> proceed now?

That's an excellent question. But not an easy one. I generally see two
approaches:

1. Start from ConnId code, make it compatible with OpenICF and then
apply the changes that were done by Forgerock and us in OpenICF
subversion. But this may be tricky. As far as I know ForgeRock
restructured the project a bit, introduced OSGi support, etc. This
approach may be quite difficult to merge and especially keeping the two
projects continually in sync.

2. Start from OpenICF code and re-apply all the changes that were done
in ConnId. As far as I understand the changes done in ConnId were either
minor (bugfixes), some new connectors and version number changes. Is
that right? If it is so this may be an easier approach. The problem is
that OpenICF is still using subversion. I'm not an git expert but it
looks like one-time migration OpenICF to git for the purposes of ConnId
merge should not be difficult. Also the continued "pull" of patches from
OpenICF to ConnId should work. The problem may appear if OpenICF
switches development to git. This may mean that we will need to do some
creative rebasing/merging/magic to adapt to that. But I guess this
approach can work.

I would like to emphasize that both approaches assume that ConnId
project will continue as it is now (git, github, CDDL, procedures). Just
the source code needs to be changed to be compatible with OpenICF. I
propose that ConnId will pull all (or most) of changes from OpenICF as
they come. And also offer all its changes to OpenICF. We need this to
create a kind of "continually integrated" development to avoid diverging
the projects too much.

I would prefer approach 2. It seems to be easier from my point of view.
But perhaps someone who is used to develop ConnId framework should have
a deep look at OpenICF source code structure and maven configuration to
figure out how feasible is either approach.

ConnId and ForgeRock also need to coordinate evolution of the ICF
framework. I mean keeping the framework compatible, introduce common
features, extensions, etc. This is critical. If we don't do this then
the two project will eventually diverge again. I have talked to
ForgeRock engineers and they are more than willing to cooperate. I also
had some discussion about the ForgerRock plans with OpenICF and it seems
reasonable. We have discussed it and quite naturally aligned ForgeRock
and Evolveum plans regarding ICF without any disputes. I can personally
say that the cooperation of ForgeRock and Evolveum goes quite well. I
expect that adding ConnId to this "loop" will bring benefits to all of
us. Once we figure out whether the merge of ConnId and OpenICF code is
feasible how to do it and when to do it we will need to discuss the
common ConnId-OpenICF outline for framework evolution. But let's take
one step at a time.

That's my point of view. What do you think?

--

Radovan Semancik
Software Architect
evolveum.com

[Francesco Chicchiriccò]

On 23/04/2013 10:40, Radovan Semancik wrote:

Comparing to the original IdentityConnectors project, ConnId basically
made bugfixes (in the framework and in some connectors), added some
configuration options (in inherited connectors) and created some new
connectors.

In addition to this, ConnId is split in several github repositories (one
for framework + one for each connector): the dependencies are managed at
Maven level.

I have no particular troubles in accepting the approach (2) above,
starting at first from framework, then moving to common connectors.

> ConnId and ForgeRock also need to coordinate evolution of the ICF
> framework. I mean keeping the framework compatible, introduce common
> features, extensions, etc. This is critical. If we don't do this then
> the two project will eventually diverge again. I have talked to
> ForgeRock engineers and they are more than willing to cooperate. I
> also had some discussion about the ForgerRock plans with OpenICF and
> it seems reasonable. We have discussed it and quite naturally aligned
> ForgeRock and Evolveum plans regarding ICF without any disputes. I can
> personally say that the cooperation of ForgeRock and Evolveum goes
> quite well. I expect that adding ConnId to this "loop" will bring
> benefits to all of us. Once we figure out whether the merge of ConnId
> and OpenICF code is feasible how to do it and when to do it we will
> need to discuss the common ConnId-OpenICF outline for framework
> evolution. But let's take one step at a time.
>
> That's my point of view. What do you think?

It seems to me that you are basically proposing to
a) take OpenICF as a whole
b) adapt it to ConnId repositories and resoures
c) re-apply ConnId enhancements
d) keep in sync any future OpenICF modification

I could agree until (c) - even tough it would mean *a lot* of work, so I
don't know how long this would take - but it looks to me that (d) just
implies that we are basically implementing a poor synchronization
protocol where ConnId is just a slave of OpenICF.

The sentence "ConnId and ForgeRock also need to coordinate evolution of
the ICF framework" then barely means to me that ConnId must take care of
not diverging from OpenICF, without being involved into the technical
discussions held there, and just taking changes as a whole, once
implemented and published.

Sorry, I cannot see this as way to cooperate.

Regards.

[Radovan Semancik]

On 04/23/2013 12:14 PM, Francesco Chicchiriccò wrote:
> It seems to me that you are basically proposing to
> a) take OpenICF as a whole
> b) adapt it to ConnId repositories and resoures
> c) re-apply ConnId enhancements
> d) keep in sync any future OpenICF modification
>
> I could agree until (c) - even tough it would mean *a lot* of work, so
> I don't know how long this would take - but it looks to me that (d)
> just implies that we are basically implementing a poor synchronization
> protocol where ConnId is just a slave of OpenICF.

Well, not really. If that would be the case we would simply stay with
OpenICF. But we want something more. I would rather see ConnId as an
upstream project to OpenICF rather than a downstream project. Think of
it as ConnId accepting contributions from OpenICF, not following OpenICF.

> The sentence "ConnId and ForgeRock also need to coordinate evolution
> of the ICF framework" then barely means to me that ConnId must take
> care of not diverging from OpenICF, without being involved into the
> technical discussions held there, and just taking changes as a whole,
> once implemented and published.

I would say that it should be mutual cooperation and there needs to be
effort on both sides not to diverge too much. You can see this somehow
as a "standardization" of the framework. If ForgeRock cannot cooperate
and they diverge the framework without any good reason then ConnId has
no obligation to follow. But what I've heard from ForgeRock is actually
quite the opposite. They want to cooperate.

> Sorry, I cannot see this as way to cooperate.

Well, it is not a big secret that ICF as a framework is far from
perfect. There are serious design issues that needs to be addressed
otherwise they are going to bit us very badly in the long run (e.g. see
https://wiki.evolveum.com/display/midPoint/ICF+Issues). I'm tempted all
the time to just get rid of ICF in midPoint entirely and just reuse the
connector code (in fact there is layer for that in midPoint already).
But we won't do it. In this case I prefer cooperation and
interoperability over technological excellence. I believe that it will
eventually pay off.

This is your (ConnId team) decision. Yes, it will be a huge task. Yes,
there are dangers. But the current schism is just insane. You decide.

[Francesco Chicchiriccò]

On 23/04/2013 15:25, Radovan Semancik wrote:

> On 04/23/2013 12:14 PM, Francesco Chicchiricc� wrote:
>> It seems to me that you are basically proposing to
>> a) take OpenICF as a whole
>> b) adapt it to ConnId repositories and resoures
>> c) re-apply ConnId enhancements
>> d) keep in sync any future OpenICF modification
>>
>> I could agree until (c) - even tough it would mean *a lot* of work,
>> so I don't know how long this would take - but it looks to me that
>> (d) just implies that we are basically implementing a poor
>> synchronization protocol where ConnId is just a slave of OpenICF.
>
> Well, not really. If that would be the case we would simply stay with
> OpenICF. But we want something more. I would rather see ConnId as an
> upstream project to OpenICF rather than a downstream project. Think of
> it as ConnId accepting contributions from OpenICF, not following OpenICF.

"Accepting contributions" is incorrect since seeking what's new in
OpenICF and bring it to ConnId would be ConnId's duty.
It would be completely different if someone from OpenICF takes care of
pushing their own modifications to ConnId.

>> The sentence "ConnId and ForgeRock also need to coordinate evolution
>> of the ICF framework" then barely means to me that ConnId must take
>> care of not diverging from OpenICF, without being involved into the
>> technical discussions held there, and just taking changes as a whole,
>> once implemented and published.
>
> I would say that it should be mutual cooperation and there needs to be
> effort on both sides not to diverge too much. You can see this somehow
> as a "standardization" of the framework. If ForgeRock cannot
> cooperate and they diverge the framework without any good reason then
> ConnId has no obligation to follow. But what I've heard from ForgeRock
> is actually quite the opposite. They want to cooperate.

I can trust you about this, but it's rather strange you are acting as
their proxy: if they want to cooperate, let's do it openly (here or in
any other public discussion place).
I would personally be glad to discuss about framework status and roadmap
with you and OpenICF people.

It would also be nice to share the merge effort: since we are doing this
in the overall interest, I would expect everyone involved to spend some
time on this.

>> Sorry, I cannot see this as way to cooperate.
>
> Well, it is not a big secret that ICF as a framework is far from
> perfect. There are serious design issues that needs to be addressed
> otherwise they are going to bit us very badly in the long run (e.g.
> see https://wiki.evolveum.com/display/midPoint/ICF+Issues). I'm
> tempted all the time to just get rid of ICF in midPoint entirely and
> just reuse the connector code (in fact there is layer for that in
> midPoint already). But we won't do it. In this case I prefer
> cooperation and interoperability over technological excellence. I
> believe that it will eventually pay off.
>
> This is your (ConnId team) decision. Yes, it will be a huge task. Yes,
> there are dangers. But the current schism is just insane. You decide.

I don't think it is fair that charge of synchronizing OpenICF and ConnId
is exclusively up to ConnId.

I don't think it is acceptable that framework features and problems are
not discussed in an open place.

I don't think it is sane to make a deal without one of the parties involved.

[Francesco Chicchiriccò]

On 23/04/2013 20:30, Gael.A...@forgerock.com wrote:
> [...]
>
> Hi Francesco,
>
> Forgerock wishes to participate in a common discussion around the specifications and evolutions of the Identity connectors framework.
> This will guarantee connectors compatibility throughout the 3 projects
> (OpenICF/ConnID/MidPoint).
> This will also ease the contribution model, giving freedom for developers to chose where their connector contribution is hosted.
>
> As an FYI, we are planning to move to GIT soon.

Hi Gael, and welcome to this discussion.

I agree with you, let's focus on the framework, targeting the full
interoperability for connectors developed in any place.

IMO we need to:

1. establish a starting shared version by merging the current OpenICF
and ConnId versions
2. maintain this shared version over time
3. discuss about evolutions and set some specifications for the future

About (1), I propose to create a new branch on ConnId github repository
with content from your SVN repository [1], and then re-apply the ConnId
changes performed so far.

Issues I see:

a. we will need to adjust the POM files: groupId and artifactId of
course, but also version since you are on 1.1.2.0-SNAPSHOT and ConnId is
on 1.3.4-SNAPSHOT - is it fine to move to 1.4.0 for this new branch?
b. difficult management of future changes to be imported from your
repository: switching to GIT will help in this respect, but we will need
anyway someone from your team with responsibility to regularly push
changes from your repository to ConnId's

About (3), I think we might use a document on GoogleDrive (or any other
public collaboration tool, even ConnId's wiki [2] if it is fine for you)
as scratchpad for the ongoing discussion.

WDYT?

[1] https://svn.forgerock.org/openicf/trunk/framework/java/
[2] https://connid.atlassian.net/wiki/

[Gael Allioux]

Hi, inline:

On 04/24/2013 10:58 AM, Francesco Chicchiricc� wrote:
> On 23/04/2013 20:30, Gael.A...@forgerock.com wrote:
>> [...]
>>
>> Hi Francesco,
>>
>> Forgerock wishes to participate in a common discussion around the
>> specifications and evolutions of the Identity connectors framework.
>> This will guarantee connectors compatibility throughout the 3 projects
>> (OpenICF/ConnID/MidPoint).
>> This will also ease the contribution model, giving freedom for
>> developers to chose where their connector contribution is hosted.
>>
>> As an FYI, we are planning to move to GIT soon.
>
> Hi Gael, and welcome to this discussion.
>
> I agree with you, let's focus on the framework, targeting the full
> interoperability for connectors developed in any place.
>
> IMO we need to:
>
> 1. establish a starting shared version by merging the current OpenICF
> and ConnId versions

agreed.

> 2. maintain this shared version over time

agreed again

> 3. discuss about evolutions and set some specifications for the future

yes. There are 2 things here...

1- carry on the work on the 1.X version of the framework. We'll have to
align our 2 different versions. Never forget that
the framework has this compatibility constraint for the connectors...
meaning we need to guarantee that the current connectors
(call them the 1.1 framework connectors) will work with the future 1.x
version of the framework regardless of the framework evolutions

2- (which is your 3.) , start working on the future which would be the
2.x framework. This means (most probably) breaking the connectors
compatibility
with 1.x.

>
> About (1), I propose to create a new branch on ConnId github
> repository with content from your SVN repository [1], and then
> re-apply the ConnId changes performed so far.
>
> Issues I see:
>
> a. we will need to adjust the POM files: groupId and artifactId of
> course, but also version since you are on 1.1.2.0-SNAPSHOT and ConnId
> is on 1.3.4-SNAPSHOT - is it fine to move to 1.4.0 for this new branch?

I'll let Laszlo answer to this one. Our initial thought was to go for a
1.2 with the following improvements:

- byte support:
OpenICF does not currently support the "byte" type for an attribute

- LiveSync: CREATE and UPDATE
OpenICF only supports DELETE and CREATE_UPDATE type of events. We
propose to add the
CREATE (object creation) and UPDATE (object update) events as well.

- __ANY__ special ObjectClass for Sync() :
One of the problem with the sync() method is that you have to specify an
objectclass. This is an issue
when you need to track events sequence between 2 differents objects from
2 different objectclasses. (Bkley/UCSF has it)

We propose to introduce a new special __ANY__ objectclass for Sync()
that would fetch "any" object so that
they could be processed wrt their sequence on the target system.

- SchemaViolationException
ICF does not have a SchemaViolationException. It is needed.

- Session Context in the pool
The way the connector pool works to day makes it a bit hard for
developers to have a smart handling of connection
pool to target system. Only way to do it is to play with static objects.
We propose to improve the ICF connector pool to
be able to handle that.

> b. difficult management of future changes to be imported from your
> repository: switching to GIT will help in this respect, but we will
> need anyway someone from your team with responsibility to regularly
> push changes from your repository to ConnId's

yep... We need to figure out how to sort out that one. But I think that
once we align our framework, there should not be that much "moves".
Framework should be pretty stable.

>
> About (3), I think we might use a document on GoogleDrive (or any
> other public collaboration tool, even ConnId's wiki [2] if it is fine
> for you) as scratchpad for the ongoing discussion.

sure... We need to share our ideas and specs.

Gael

[Fabio Martelli]

Hi Guys, I'm really appreciating the way you are going to converge.
The solution suggested by Francesco sounds good to me.

As written in a previous email I do think that this collaboration is a good thing: it seems that the benefits for ConnId are quite obvious but I'm still wondering about OpenICF's.
I'm not a so great business man but the main reasons that I can see is that FR's support offer will benefit of an extended market: IMO, in the long term an OpenICF subscription could be needed not just on an OpenIDM project (for ConnId should be quite the same, I hope).

Btw, let's forget my digression now and go on. I confirm my agreement with the suggested plan.

Best regards,
F.

[Radovan Semancik]

Hi,

> a. we will need to adjust the POM files: groupId and artifactId of course, but also version since you are on 1.1.2.0-SNAPSHOT and ConnId is on 1.3.4-SNAPSHOT - is it fine to move to 1.4.0 for this new branch?

Fine for me. I like this idea. Seems to be good for everybody.

> About (3), I think we might use a document on GoogleDrive (or any other public collaboration tool, even ConnId's wiki [2] if it is fine for you) as scratchpad for the ongoing discussion.

I would prefer wiki. But I can adapt to almost any method.

[László Hordós]

Hi Francesco,

I agree this is a good idea to make a new version where we merge our changes. We did planned the same. I looked into the ConnId source and the changes on GitHub and I think there were significantly more changes in OpenICF so I try to make OpenICF more aligned to ConnId before so the merge will be simpler. There are some area where I think in advance we should get an agreement. I try to describe some as is in OpenICF and we can discuss them.

Versioning policy:

The Identity Connector framework used major.minor versioning for the API. OpenICF kept this and as I see ConnId did the same. As long the major version is the same the bigger minor version MUST guarantee the backward compatibility so connector using earlier API MUST work with the new framework version.    

f

r

a

m

w

o

r Connector version

k 1.1 1.2 1.3 1.4

1.1 OK

1.2 OK OK

1.3 OK OK OK

1.4  OK OK OK OK

If the major version is increased then we are allow to break the compatibility but before we do that we can in advance prepare how to support the existing connectors but that just technical details. 

OpenICF use x.x.x.x version in POM to let us keep the same API version and make multiple releases and maintenance releases in between.  I think as long the source code and the API version is the same it does not matter what's the version of the artifact. I will increase the OpenICF version to 1.4 too.

Formatting and Checkstyle:

OpenICF as a ForgeRock project it moves to a common style and we have our own checkstyle 

 

https://svn.forgerock.org/commons/forgerock-build-tools/trunk/src/main/resources/org/forgerock/checkstyle/check-src-default.xml

I hope this is mostly compatible with the ConnId style. 

We mostly develop with Eclipse and IntelliJ (with Eclipse Formatter) and we may be able to align the same formatting settings.

Testing framework:

OpenICF as a ForgeRock project we change from JUnit to TestNG everywhere. I'd like to propose to use TestNG as going forward unless there is a reason to stay with JUnit.  

  

There are some other areas where I need to sync internally. These are the documentation and the QA. We write the Framework documentation in DocBook 5.0 and generate multiple media when we make a release. QA use their own system in corporation with the contract test to test the connector. This is one of our priority to improve the contract test framework regards some proposed improvement for the new API version and write the developer guide for connectors document. I don't really like the idea to maintain multiple documentation so I need to figure out what can we do here. I like the wiki but I think we would like to keep the DocBook documentation too. We also generate these for most of the connectors and append the connector documentation as a chapter to a bigger documents. 

What I propose now. I make some more detailed analysis and preparation to make the merge easy and then I come back with some more detailed responses. I let Gael to present you our proposed roadmap for the 1.4 so we all can make a common connector framework.

Regards,

Laszlo

Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[Francesco Chicchiriccò]

On 30/04/2013 10:07, László Hordós wrote:

Hi Francesco,

I agree this is a good idea to make a new version where we merge our changes. We did planned the same. I looked into the ConnId source and the changes on GitHub and I think there were significantly more changes in OpenICF so I try to make OpenICF more aligned to ConnId before so the merge will be simpler.

Hi Lazlo,
this sounds very interesting: I will be waiting for a signal from you then before creating the new branch and importing from your repository.

There are some area where I think in advance we should get an agreement. I try to describe some as is in OpenICF and we can discuss them.

Versioning policy:

The Identity Connector framework used major.minor versioning for the API. OpenICF kept this and as I see ConnId did the same. As long the major version is the same the bigger minor version MUST guarantee the backward compatibility so connector using earlier API MUST work with the new framework version.    

f

r

a

m

w

o

r Connector version

k 1.1 1.2 1.3 1.4

1.1 OK

1.2 OK OK

1.3 OK OK OK

1.4  OK OK OK OK

If the major version is increased then we are allow to break the compatibility but before we do that we can in advance prepare how to support the existing connectors but that just technical details. 

OpenICF use x.x.x.x version in POM to let us keep the same API version and make multiple releases and maintenance releases in between.  I think as long the source code and the API version is the same it does not matter what's the version of the artifact. I will increase the OpenICF version to 1.4 too.

Fine: this means that the new branch on ConnId github mentioned above will start with version 1.4.0.0-SNAPSHOT; correct?

Formatting and Checkstyle:

OpenICF as a ForgeRock project it moves to a common style and we have our own checkstyle 

 

https://svn.forgerock.org/commons/forgerock-build-tools/trunk/src/main/resources/org/forgerock/checkstyle/check-src-default.xml

I hope this is mostly compatible with the ConnId style. 

We mostly develop with Eclipse and IntelliJ (with Eclipse Formatter) and we may be able to align the same formatting settings.

We are instead mostly on Netbeans; however, the NB Checkstyle plugin should ease the alignment process.

Testing framework:

OpenICF as a ForgeRock project we change from JUnit to TestNG everywhere. I'd like to propose to use TestNG as going forward unless there is a reason to stay with JUnit.

I don't see any reason for not using TestNG.

There are some other areas where I need to sync internally. These are the documentation and the QA. We write the Framework documentation in DocBook 5.0 and generate multiple media when we make a release. QA use their own system in corporation with the contract test to test the connector. This is one of our priority to improve the contract test framework regards some proposed improvement for the new API version and write the developer guide for connectors document. I don't really like the idea to maintain multiple documentation so I need to figure out what can we do here. I like the wiki but I think we would like to keep the DocBook documentation too. We also generate these for most of the connectors and append the connector documentation as a chapter to a bigger documents.

Ok, this is an aspect to check.

What I propose now. I make some more detailed analysis and preparation to make the merge easy and then I come back with some more detailed responses.

Fine, I will be waiting for this.

Anyway, we will also need, on the ConnId github new branch, avoid dependencies on other ForgeRock resources (like as org.forgerock: forgerock-parent or org.forgerock: forgerock-doc-maven-plugin).

I let Gael to present you our proposed roadmap for the 1.4 so we all can make a common connector framework.

About this, we can use ConnId wiki [2] (possibly with a whole new space); Radovan already said ok, what about you (and Gael)?
If confirmed, you will need to create your accounts there and I will take care of necessary setup.

Regards.

[Radovan Semancik]

HI,

I just want formally say that "I agree". We have discussed most of this with Laszlo and Gael before and we are in agreement here.

And I would also like to support Francesco's comment about removing the dependencies on forgerock parent maven project if possible. It would be better if the framework code is maintained as a standalone project independent of company-specific settings.

-- 

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com

[László Hordós]

Hi, 

I'd like to give a short status report. In the last couple of days I was able to merge ConnId and OpenICF and improve the code quality to comply with the checkstyle. There are many Java Doc issues but the time will fix it.

What we get with the merge:

From OpenICF:

Configureable result handlers:

http://openicf.forgerock.org/connector-framework/apidocs/org/identityconnectors/framework/api/ResultsHandlerConfiguration.html

Solves the problem of https://connid.atlassian.net/browse/AD-19 

This was a quick solution in advance a bigger API change: Support better filtering and pagination.  

Use a more flexible filtering aligned with http://tools.ietf.org/html/draft-ietf-scim-api-01#section-3.2.2.2 

 Expr            = OrExpr

 OrExpr          = AndExpr ( 'or' AndExpr ) *

 AndExpr        = NotExpr ( 'and' NotExpr ) *

 NotExpr         = '!' PrimaryExpr | PrimaryExpr

 PrimaryExpr     = '(' Expr ')' | ComparisonExpr | PresenceExpr | LiteralExpr

 ComparisonExpr = Pointer OpName Value

 PresenceExpr   = Pointer 'pr'

 LiteralExpr     = 'true' | 'false'

 Pointer         = Attribute pointer

 OpName          = 'eq' |  # equal to

                  'co' |   # contains

                  'sw' |   # starts with

                  'lt' |   # less than

                  'le' |   # less than or equal to

                  'gt' |   # greater than

                  'ge' |  # greater than or equal to

                  STRING  # extended operator

 Value       = NUMBER | BOOLEAN | '"' UTF8STRING '"'

 STRING          = ASCII string not containing white-space

 UTF8STRING     = UTF-8 string possibly containing white-space

https://bugster.forgerock.org/jira/browse/OPENICF-19

The implementation is ready but it's not committed to OpenICF yet because the API incompatibility.

Supported attribute type: Byte 

https://bugster.forgerock.org/jira/browse/OPENICF-77

LiveSync deadlock:

https://bugster.forgerock.org/jira/browse/OPENICF-103

Support version range for the connectors:

https://bugster.forgerock.org/jira/browse/OPENICF-63

Improve the Connector pool to prepare for the Shared Pool Context which we planned to add to the next release

https://bugster.forgerock.org/jira/browse/OPENICF-26 

Add a heartbeat to check the connection with the connector server

https://bugster.forgerock.org/jira/browse/OPENICF-25

Add Update and Create to SyncDelta

https://bugster.forgerock.org/jira/browse/OPENICF-12

Change from JUnit to TestNG

Uid has revision to support MVCC implementations

Fix the performance bottleneck of LocalCache.

There are some other small bug fixes

From ConnId: 

IOUtil has same new methods 

https://github.com/Tirasa/ConnId/commit/328e36b777c7091bed24e8a9f31be4e1e1264c6c

new PrettyStringBuilder class

Fix ThreadLocal 

https://github.com/Tirasa/ConnId/commit/cef18c78db989d5be85f5dfb80505964415fe6b0

There are some other small bug fixes

Please let me know if there is any particular fix/commit I should be aware. Only the JavaDoc formatting left to fix. I will commit the change in next week and we can create the branch from that version.

Regards,

Laszlo

[Gael Allioux]

Thanks a lot Laszlo.

Gael

[Francesco Chicchiriccò]

Hi Lazlo,
this sounds very nice: good job!

As soon as you've finished, I will create the new branch on github with export from the SVN path that you will indicate.

At that point I will change the POM files to match ConnId coordinates.

Moreover, I think we need to agree on the license header to use; an example of ConnId's is at

https://github.com/Tirasa/ConnId/blob/master/framework/src/main/java/org/identityconnectors/common/Assertions.java

while an example of OpenICF's is at

https://svn.forgerock.org/openicf/trunk/framework/java/connector-framework/src/main/java/org/identityconnectors/common/Assertions.java

I would suggest to take ConnId's and add

Copyright 2011-2013 ForgeRock. All rights reserved.

on top: WDYT?

Regards.

[Radovan Semancik]

Hi,

First of all: great work Laszlo!

On 05/10/2013 11:55 AM, Francesco Chicchiricc� wrote:
> I would suggest to take ConnId's and add
>
> Copyright 2011-2013 ForgeRock. All rights reserved.
>
> on top: WDYT?

As far as I understand CDDL then any ICF fork that builds on top of Sun
ICF is still formally (c) Sun Microsystems. And all of us are just
contributors. Therefore we can add "portions (c)
ForgeRock/Tirassa/Evolveum" at the bottm of the header. But placing any
other (c) on top except for Sun Microsystems would be inappropriate.
There is a theoretical way how to work around that by starting a new
project and just including the original ICF files in such a new project.
But this has serious drawbacks and as neighter of us owns copyright for
a vast majority of the source code this would not be a good open-source
approach. Therefore I suggest to keep the original Sun copyright there
and just let anyone who edits a file add himself to that specific file
header claiming a partial copyright. It may be quite different for a
completely new files, but I believe that this is the right way for
existing files.

But IANAL. I do not claim to have a complete understanding of CDDL.

[Gael Allioux]

Hi,

I can only agree with you Radovan. Original Sun code should stay
copyrighted as is.
We can only add the "Portions ..." when we do modify a file.

Gael

On 05/10/2013 04:51 PM, Radovan Semancik wrote:
> Hi,
>
> First of all: great work Laszlo!
>

[Gael Allioux]

Hi,

from a License/Copyright perspective, we verified on our side and here are the basic rules we need to agree on:

1- Existing files from Sun that none of the projects have modified: only update the CDDL URL in the existing Copyright

2- Modified files by one of the three projects: "Portions Copyrighted... " added for each project that has modified the file

3- New file: The project that brings the new file put its copyright and the file is under CDDL.

Because of the invalid CDDL URL, all framework files will be updated with this License and Copyright version:
(existing Portions Copyright will be kept)

/*

 * ====================

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

 *

 * Copyright 2008-2009 Sun Microsystems, Inc. All rights reserved.

 *

 * The contents of this file are subject to the terms of the Common Development

 * and Distribution License("CDDL") (the "License").  You may not use this file

 * except in compliance with the License.

 *

 * You can obtain a copy of the License at

 * http://opensource.org/licenses/cddl1.php

 * See the License for the specific language governing permissions and limitations

 * under the License.

 *

 * When distributing the Covered Code, include this CDDL Header Notice in each file

 * and include the License file at http://opensource.org/licenses/cddl1.php.

 * If applicable, add the following below this CDDL Header, with the fields

 * enclosed by brackets [] replaced by your own identifying information:

 * "Portions Copyrighted [year] [name of copyright owner]"

 * ====================

 *
==== If portions copyrighted, the following will be added accordingly:

 * Portions Copyrighted 2011-2013 Evolveum.

 * Portions Copyrighted 2011-2013 ForgeRock Inc.

 * Portions Copyrighted 2011-2013 Tirasa.

 */

Please confirm

cheers

Gael

On 05/10/2013 04:51 PM, Radovan Semancik wrote:

Hi,

First of all: great work Laszlo!

[Francesco Chicchiriccò]

+1, sounds fine.

Regards.

[Fabio Martelli]

Sounds good.
thanks,
F.

[Radovan Semancik]

Hi,

OK for us

-- 

                                           Radovan Semancik
                                          Software Architect
                                             evolveum.com

[Colm O hEigeartaigh]

> 2- Modified files by one of the three projects: "Portions Copyrighted... " added for each project that has modified the file

What about changes that do not fall into one of the three categories? I have committed some code to ConnID but I am not an employee of Tirasa.

Colm.

--

You received this message because you are subscribed to the Google Groups "connid-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+...@googlegroups.com.
Visit this group at http://groups.google.com/group/connid-dev?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Francesco Chicchiriccò]

On 17/05/2013 14:53, Colm O hEigeartaigh wrote:
>
> > 2- Modified files by one of the three projects: "Portions
> Copyrighted... " added for each project that has modified the file
>
> What about changes that do not fall into one of the three categories?
> I have committed some code to ConnID but I am not an employee of Tirasa.

Good point: I'd propose then to use

Portions Copyrighted 2011-2013 ConnId.

instead of

Portions Copyrighted 2011-2013 Tirasa.

WDYT?

--
Francesco Chicchiricc�

[Gael Allioux]

Anyone can add his own name or company name in the Portions Copyrighted.
I've just named the 3 projects as an example.

The key points here are:
1- not to change the original copyright from Sun.
2-proper CDDL copyright for new files.

Gael

[Colm O hEigeartaigh]

> Portions Copyrighted 2011-2013 ConnId.
>instead of
>Portions Copyrighted 2011-2013 Tirasa.

Sure, that works for me, thanks.

Colm.

On Fri, May 17, 2013 at 2:18 PM, Francesco Chicchiriccò <ilgr...@apache.org> wrote:

On 17/05/2013 14:53, Colm O hEigeartaigh wrote:

> 2- Modified files by one of the three projects: "Portions Copyrighted... " added for each project that has modified the file

What about changes that do not fall into one of the three categories? I have committed some code to ConnID but I am not an employee of Tirasa.

Good point: I'd propose then to use

Portions Copyrighted 2011-2013 ConnId.

instead of

Portions Copyrighted 2011-2013 Tirasa.

WDYT?

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

--
You received this message because you are subscribed to the Google Groups "connid-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to connid-dev+unsubscribe@googlegroups.com.

Visit this group at http://groups.google.com/group/connid-dev?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[László Hordós]

Hi,

Sorry for the delay. I had too many other things to finish. I merged the ConnId into the OpenICF trunk and I made some cleanup. Feel free to fetch the trunk version of the code now. 

We will keep the ForgeRock Maven project structure but the code should work with the new 1.4 maven project you add . Only the version must be 1.4 and the code base same. 

Let me know if you have any question.

Regards,

Laszlo

[Francesco Chicchiriccò]

On 30/05/2013 14:04, László Hordós wrote:
> Hi,
>
> Sorry for the delay. I had too many other things to finish. I merged
> the ConnId into the OpenICF trunk and I made some cleanup. Feel free
> to fetch the trunk version of the code now.
>
> We will keep the ForgeRock Maven project structure but the code should
> work with the new 1.4 maven project you add . Only the version must be
> 1.4 and the code base same.
>
> Let me know if you have any question.

Hi Lazlo,
thanks for this.

Is it fine to use [1] as import source?

As recently said [2], I will also turn any "Tirasa" copyright instance
into "ConnId".

I'll keep you posted.
Regards.

[1] https://svn.forgerock.org/openicf/trunk/framework/java/
[2] https://groups.google.com/d/msg/connid-dev/mKBhLZaKR1Q/5gZ923PskIIJ

[László Hordós]

Yes, that's the correct place.

I didn't updated the copyright except the PrettyStringBuilder. I just fixed the licence file location and I kept the original headers.