Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-03-01 Thread Alex Karasulu
On Tue, Mar 1, 2011 at 11:09 AM, Pierre-Arnaud Marcelot 
wrote:

> On lundi 28 février 2011 at 14:49, Alex Karasulu wrote:
>
> (4) work together with Pierre to get Studio back to 100% (jars,
> bundles in build need adjusting)
>
>  Completed!
>
> It was not very easy but I finally get it working.
> I had to use kind of a nasty hack to force the start of the new Protocol
> LDAP Codec bundle, but it's good now.
>
> Ready to move to next steps whenever you're ready Alex.
>

OK thanks Pierre you saved the day here. So the next step (5) is just to
swap out the trunks with what we have in milestones.

Will do that now if no one has objections.

Regards,
Alex


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-03-01 Thread Pierre-Arnaud Marcelot
On lundi 28 février 2011 at 14:49, Alex Karasulu wrote:
(4) work together with Pierre to get Studio back to 100% (jars,
> bundles in build need adjusting) 
 Completed! 

It was not very easy but I finally get it working.
I had to use kind of a nasty hack to force the start of the new Protocol LDAP 
Codec bundle, but it's good now.

Ready to move to next steps whenever you're ready Alex.

Regards,
Pierre-Arnaud




Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
Here's where we are now:

(4) work together with Pierre to get Studio back to 100% (jars,
> bundles in build need adjusting)
>

Now with this new directory structure we probably need to review module
artifactIds and change them in shared. And then move up the stack to correct
changes in ApacheDS and Studio.

Best,
Alex


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
>
> (3) swap out milestones with personal branch
>

Reorg worked, swapping out the milestones now.


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
On Mon, Feb 28, 2011 at 3:49 PM, Alex Karasulu  wrote:
> OK Pierre and I talked on IRC. This is a good time with relatively
> little activity that may pose the least disruption to others. So we're
> going to push the reorg and promotions to trunks and milestones to
> have the same paths. Here's the process which I will begin after
> posting this mail:
>
> (1) merge into my personal branch from trunks and milestones - all
> changes will be up to date on personal branch.

COMPLETED !!!

> (2) do the reorg

STARTING AFTER FULL BUILD AND INTEG TEST !!!

> (3) swap out milestones with personal branch
> (4) work together with Pierre to get Studio back to 100% (jars,
> bundles in build need adjusting)
> (5) swap out trunks with fully operational reorganized milestones branch
> (6) kick off the M2 release cycle
> (7) keep working towards M3 in milestones/personal branches


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
Thanks Pierre!

On Mon, Feb 28, 2011 at 3:46 PM, Pierre-Arnaud Marcelot  
wrote:
> I will help you on that task.
>
> Regards,
> Pierre-Arnaud
>
> On lundi 28 février 2011 at 14:29, Alex Karasulu wrote:
>
> OK if there are no objections I will merge in from trunks and
> milestones first. Then I will re-organize as stated then swap out
> milestones.
>
> Can we then work on milestones instead of trunk? I just want to make
> sure the path changes do not cause issues.
>
> The idea is to get this quickly into trunk and we can all work off the
> same paths from then on even if on different branches?
>
> Regards,
> Alex
>
>


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
OK Pierre and I talked on IRC. This is a good time with relatively
little activity that may pose the least disruption to others. So we're
going to push the reorg and promotions to trunks and milestones to
have the same paths. Here's the process which I will begin after
posting this mail:

(1) merge into my personal branch from trunks and milestones - all
changes will be up to date on personal branch.
(2) do the reorg
(3) swap out milestones with personal branch
(4) work together with Pierre to get Studio back to 100% (jars,
bundles in build need adjusting)
(5) swap out trunks with fully operational reorganized milestones branch
(6) kick off the M2 release cycle
(7) keep working towards M3 in milestones/personal branches

Regards,
Alex

On Mon, Feb 28, 2011 at 3:29 PM, Alex Karasulu  wrote:
> OK if there are no objections I will merge in from trunks and
> milestones first. Then I will re-organize as stated then swap out
> milestones.
>
> Can we then work on milestones instead of trunk? I just want to make
> sure the path changes do not cause issues.
>
> The idea is to get this quickly into trunk and we can all work off the
> same paths from then on even if on different branches?
>
> Regards,
> Alex
>


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Pierre-Arnaud Marcelot
I will help you on that task.

Regards,
Pierre-Arnaud
On lundi 28 février 2011 at 14:29, Alex Karasulu wrote: 
> OK if there are no objections I will merge in from trunks and
> milestones first. Then I will re-organize as stated then swap out
> milestones.
> 
> Can we then work on milestones instead of trunk? I just want to make
> sure the path changes do not cause issues.
> 
> The idea is to get this quickly into trunk and we can all work off the
> same paths from then on even if on different branches?
> 
> Regards,
> Alex
> 


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
OK if there are no objections I will merge in from trunks and
milestones first. Then I will re-organize as stated then swap out
milestones.

Can we then work on milestones instead of trunk? I just want to make
sure the path changes do not cause issues.

The idea is to get this quickly into trunk and we can all work off the
same paths from then on even if on different branches?

Regards,
Alex


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
Ooops premature e-mail send. ...

On Mon, Feb 28, 2011 at 2:54 PM, Emmanuel Lécharny  wrote:
> On 2/28/11 1:02 PM, Alex Karasulu wrote:
>>
>> Hi Emmanuel,

SNIP ...

>
>> The archetype module? It contains some Maven archetypes for rapidly
>> setting up new extension oriented maven projects. Like for example an
>> archetype to start a new control project or a new ext req/resp pair.
>
> Ahh, ok. Call it maven-archetype, then, it would be more explicit.

Can do that but then it will be in the name. Nesting is causing longer
artifact names so I was trying to conserve.

>>
>>> Seems ok to me, more or less, but I think we should reorganize after M2.
>>
>> I don't see a benefit before or after M2. Just curious though why you
>> want to do this after M2? If you have a preference we can cater to
>> that.
>
> Not a big deal, trying to connect the two mails you sent, was thinking you
> wanted to get M2 out now.

Yeah the reorg can be done in 2 hours. I was thinking of doing it
before merging into the milestones branch, and before asking Pierre to
help with fixing up Studio.

> Sorry for the short answers, I'm a bit busy dealing with real life atm.

No worries at all.

Thanks,
Alex


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
On Mon, Feb 28, 2011 at 2:54 PM, Emmanuel Lécharny  wrote:
> On 2/28/11 1:02 PM, Alex Karasulu wrote:
>>
>> Hi Emmanuel,
>>
>> On Mon, Feb 28, 2011 at 1:27 PM, Emmanuel Lecharny
>>  wrote:

     ldap/
         codec/
         model/
         schema/
         schema-converter/
>>>
>>> wouldn't it be better to make it a sub-module ?
>>
>> Yes these are all sub modules.
>
> I mean, schema-convertor as a sub-model under schema/

OH OK I see. Sure yeah.


         client-api/
         codec-standalone/
         all/
>>>
>>> Shouldn't it be a separated module ?
>>
>> Hmm I don't quite understand you here. These are all separate modules
>> broken down for better hierarchical organization. Could you be a bit
>> more specific, I want to make sure I understand you fully.
>
> The 'all' module shoudl'nt it be moved at the top level ?

This all module is for all of LDAP not all of shared. The idea is to
create one big shaded jar file that can be used instead of all our
dependencies. It's more for people dropping in this jar instead of
using an archetype for a Maven based LDAP project that can pull down
all the deps.

> What is this module about ?

This all-in-one jar should not be used in Maven projects as a
dependency. It's for quick use and testing. Down the line it can even
have a main in the jar to enable use as a quick use command line
client.

>> The archetype module? It contains some Maven archetypes for rapidly
>> setting up new extension oriented maven projects. Like for example an
>> archetype to start a new control project or a new ext req/resp pair.
>
> Ahh, ok. Call it maven-archetype, then, it would be more explicit.
>>
>>> Seems ok to me, more or less, but I think we should reorganize after M2.
>>
>> I don't see a benefit before or after M2. Just curious though why you
>> want to do this after M2? If you have a preference we can cater to
>> that.
>
> Not a big deal, trying to connect the two mails you sent, was thinking you
> wanted to get M2 out now.
>
> Sorry for the short answers, I'm a bit busy dealing with real life atm.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Emmanuel Lécharny

On 2/28/11 1:02 PM, Alex Karasulu wrote:

Hi Emmanuel,

On Mon, Feb 28, 2011 at 1:27 PM, Emmanuel Lecharny  wrote:

 ldap/
 codec/
 model/
 schema/
 schema-converter/

wouldn't it be better to make it a sub-module ?

Yes these are all sub modules.

I mean, schema-convertor as a sub-model under schema/

 client-api/
 codec-standalone/
 all/

Shouldn't it be a separated module ?

Hmm I don't quite understand you here. These are all separate modules
broken down for better hierarchical organization. Could you be a bit
more specific, I want to make sure I understand you fully.

The 'all' module shoudl'nt it be moved at the top level ?

What is this module about ?



The archetype module? It contains some Maven archetypes for rapidly
setting up new extension oriented maven projects. Like for example an
archetype to start a new control project or a new ext req/resp pair.

Ahh, ok. Call it maven-archetype, then, it would be more explicit.



Seems ok to me, more or less, but I think we should reorganize after M2.

I don't see a benefit before or after M2. Just curious though why you
want to do this after M2? If you have a preference we can cater to
that.
Not a big deal, trying to connect the two mails you sent, was thinking 
you wanted to get M2 out now.


Sorry for the short answers, I'm a bit busy dealing with real life atm.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com



Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
On Mon, Feb 28, 2011 at 2:49 PM, Pierre-Arnaud Marcelot  
wrote:
> On lundi 28 février 2011 at 13:02, Alex Karasulu wrote:
>
> Seems ok to me, more or less, but I think we should reorganize after M2.

Yeah did not think of that. We did not announce M1 at all so it was
safe to make aggressive changes.

Alex

> I don't see a benefit before or after M2. Just curious though why you
> want to do this after M2? If you have a preference we can cater to
> that.
>
> If we are going to advertise a little more on M2 than we did for M1 to our
> users, I'd recommend that we reorganize before M2.
> It will avoid future breakage in the builds of our users since artifacts ids
> might change.
>
> Regards,
> Pierre-Arnaud


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Pierre-Arnaud Marcelot
On lundi 28 février 2011 at 13:02, Alex Karasulu wrote:
Seems ok to me, more or less, but I think we should reorganize after M2.
> 
> I don't see a benefit before or after M2. Just curious though why you
> want to do this after M2? If you have a preference we can cater to
> that. 
If we are going to advertise a little more on M2 than we did for M1 to our 
users, I'd recommend that we reorganize before M2.
It will avoid future breakage in the builds of our users since artifacts ids 
might change.

Regards,
Pierre-Arnaud 

Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Pierre-Arnaud Marcelot
Hi Alex,

Very good idea.
I like this reorganization a lot.

At some point with our number of projects increasing, it really makes sense to 
group them in some kind of logical organization.
We did the same thing for Studio a few months ago.

+1 

Regards,
Pierre-Arnaud
On lundi 28 février 2011 at 04:50, Alex Karasulu wrote: 
> Hi all,
> 
> Shared has grown somewhat and I think it will grow more as we tack on
> more protocol additions and functionality. I was thinking of using
> some project module hierarchy to try to establish some organization we
> can grow with.
> 
> Here's what I was thinking:
> 
> shared/
>  i18n/
>  util/
>  integ/
>  asn1/
>  api/
>  ber/
>  dsml/
>  parser/
>  engine/
>  ldap/
>  codec/
>  model/
>  schema/
>  schema-converter/
>  client-api/
>  codec-standalone/
>  all/
>  protocol/
>  mina/
>  extras/
>  aci/
>  sp/
>  trigger/
>  util/
>  archetype/
>  control/
>  extended/
>  schema/
>  codec/
>  api/
>  plugin/
> 
> The deepest level is 5 and we'd concat levels into the names as we
> kind of do already. Here is the very last node,
> shared-ldap-extras-codec-plugin, as an example of the artifactId
> composition standard.
> 
> Thoughts?
> 
> Thanks,
> Alex
> 


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Alex Karasulu
Hi Emmanuel,

On Mon, Feb 28, 2011 at 1:27 PM, Emmanuel Lecharny  wrote:
> On 2/28/11 4:50 AM, Alex Karasulu wrote:
>>
>> Hi all,
>
> comments in line.
>>
>> Shared has grown somewhat and I think it will grow more as we tack on
>> more protocol additions and functionality. I was thinking of using
>> some project module hierarchy to try to establish some organization we
>> can grow with.
>>
>> Here's what I was thinking:
>>
>> shared/
>>     i18n/
>>     util/
>>     integ/
>>     asn1/
>>         api/
>>         ber/
>>     dsml/
>>         parser/
>>         engine/
>>     ldap/
>>         codec/
>>         model/
>>         schema/
>>         schema-converter/
>
> wouldn't it be better to make it a sub-module ?

Yes these are all sub modules.

>>
>>         client-api/
>>         codec-standalone/
>>         all/
>
> Shouldn't it be a separated module ?

Hmm I don't quite understand you here. These are all separate modules
broken down for better hierarchical organization. Could you be a bit
more specific, I want to make sure I understand you fully.

Thanks.

>>
>>         protocol/
>>             mina/
>>         extras/
>>             aci/
>>             sp/
>>             trigger/
>>             util/
>>             archetype/
>
> What is this module about ?

The archetype module? It contains some Maven archetypes for rapidly
setting up new extension oriented maven projects. Like for example an
archetype to start a new control project or a new ext req/resp pair.

>>
>>                control/
>>                extended/
>>                schema/
>>             codec/
>>                api/
>>                plugin/
>>
>> The deepest level is 5 and we'd concat levels into the names as we
>> kind of do already. Here is the very last node,
>> shared-ldap-extras-codec-plugin, as an example of the artifactId
>> composition standard.
>>
>> Thoughts?
>
> Seems ok to me, more or less, but I think we should reorganize after M2.

I don't see a benefit before or after M2. Just curious though why you
want to do this after M2? If you have a preference we can cater to
that.

Regards,
Alex


Re: [Shared] [SCM] Thinking about some hierarchy in shared.

2011-02-28 Thread Emmanuel Lecharny

On 2/28/11 4:50 AM, Alex Karasulu wrote:

Hi all,

comments in line.

Shared has grown somewhat and I think it will grow more as we tack on
more protocol additions and functionality. I was thinking of using
some project module hierarchy to try to establish some organization we
can grow with.

Here's what I was thinking:

shared/
 i18n/
 util/
 integ/
 asn1/
 api/
 ber/
 dsml/
 parser/
 engine/
 ldap/
 codec/
 model/
 schema/
 schema-converter/

wouldn't it be better to make it a sub-module ?

 client-api/
 codec-standalone/
 all/

Shouldn't it be a separated module ?

 protocol/
 mina/
 extras/
 aci/
 sp/
 trigger/
 util/
 archetype/

What is this module about ?

control/
extended/
schema/
 codec/
api/
plugin/

The deepest level is 5 and we'd concat levels into the names as we
kind of do already. Here is the very last node,
shared-ldap-extras-codec-plugin, as an example of the artifactId
composition standard.

Thoughts?

Seems ok to me, more or less, but I think we should reorganize after M2.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com