[RT] Cleaning up our modules (Part V)

[Carsten Ziegeler <cz...@apache.org>]

Hi,

it seems that we are nearly through - so this could be the last part of 
the series for now :)

I think the remaining part is the "sling" directory. I'm not sure if 
this contains some extensions we could move to the extensions dir?

And I think we should find a better name than "sling" for this directory 
as everything is Sling :) (it made sense when we distinguished between 
micro sling and sling). So any good idea?

And the last thing I noticed is that commons testing now contains 
references to other sling modules which is a little bit against the idea 
of commons being independent from Sling. As the testing stuff is about 
jcr testing, we could move it to the jcr modules?
(This one is not that important though)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Cleaning up our modules (Part V)

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote:
> Hi,
> 
> On Tue, May 13, 2008 at 8:30 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ... it seems that we are nearly through - so this could be the last part of the
>> series for now :)...
> 
> Wait wait wait - that Hollywood contract for season II is on my desk,
> ready to sign ;-)
You might want to check the contract for any hidden clauses (watch out 
for catapults...) :)

> 
>> ... I think the remaining part is the "sling" directory. I'm not sure if this
>> contains some extensions we could move to the extensions dir?...
> 
> I think it depends on what we rename that "sling" directory
> to...adapter and bundleresource might be considered extensions maybe?
Hmm, more or less the whole dir is made out of extensions (except core)

> 
>> ... And I think we should find a better name than "sling" for this directory as
>> everything is Sling :) (it made sense when we distinguished between micro
>> sling and sling). So any good idea?...
> 
> Those are the "main" or "core" modules maybe?
> I'd suggest main, or core-components?
Yes, sounds good to me.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Cleaning up our modules (Part V)

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Tue, May 13, 2008 at 8:30 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ... it seems that we are nearly through - so this could be the last part of the
> series for now :)...

Wait wait wait - that Hollywood contract for season II is on my desk,
ready to sign ;-)

> ... I think the remaining part is the "sling" directory. I'm not sure if this
> contains some extensions we could move to the extensions dir?...

I think it depends on what we rename that "sling" directory
to...adapter and bundleresource might be considered extensions maybe?

> ... And I think we should find a better name than "sling" for this directory as
> everything is Sling :) (it made sense when we distinguished between micro
> sling and sling). So any good idea?...

Those are the "main" or "core" modules maybe?
I'd suggest main, or core-components?

> ... And the last thing I noticed is that commons testing now contains
> references to other sling modules which is a little bit against the idea of
> commons being independent from Sling. As the testing stuff is about jcr
> testing, we could move it to the jcr modules?
>  (This one is not that important though)...

Why not, I'd agree to move commons/testing to jcr/testing.

-Bertrand
>
>  Carsten
>  --
>  Carsten Ziegeler
>  cziegeler@apache.org
>
>



-- 
 Bertrand Delacretaz
 http://www.codeconsult.ch

Re: [RT] Cleaning up our modules (Part V)

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
> 
> Yes, because providing a JCR repository instance is just part of the
> module. It also contains mocks for OSGi and Sling API interfaces, both
> of which have nothing to do with JCR.
> 
> We could of course split into three: OSGi mocks, Sling API mocks and the
> JCR stuff and distribute accordingly. But I am not sure, whether this is
> really worth the effort.
> 
No, I don't think its worth it, let's leave it the way it is right now.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Cleaning up our modules (Part V)

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Dienstag, den 13.05.2008, 13:04 +0200 schrieb Carsten Ziegeler:
> Felix Meschberger wrote:
> >> And the last thing I noticed is that commons testing now contains 
> >> references to other sling modules which is a little bit against the idea 
> >> of commons being independent from Sling. As the testing stuff is about 
> >> jcr testing, we could move it to the jcr modules?
> >> (This one is not that important though)
> > 
> > There are two, actually: Sling API and Sling JCR API. Both are API-only
> > bundles and both are present because the commons/testing bundle
> > implements Mock classes for the respective APIs. I am fine with these
> > dependencies.
> Yes, they're fine and make sense of course. Would you mind if we move 
> the testing stuff from commons to jcr?

Yes, because providing a JCR repository instance is just part of the
module. It also contains mocks for OSGi and Sling API interfaces, both
of which have nothing to do with JCR.

We could of course split into three: OSGi mocks, Sling API mocks and the
JCR stuff and distribute accordingly. But I am not sure, whether this is
really worth the effort.

Regards
Felix

Re: [RT] Cleaning up our modules (Part V)

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, May 13, 2008 at 2:17 PM, Carsten Ziegeler <cz...@apache.org> wrote:

> ...So, let's move core to top level as "engine", move the extensions from the
> current "sling" dir to "extensions" and rename "sling" to "servlets"....

+1

-Bertrand

Re: [RT] Cleaning up our modules (Part V)

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
> 
> Agreed. In fact, bundleresource is probably also an extension...
Maybe :)

> 
> We might want to start thinking of required and optional extensions ;-)
> Because some extensions are required and used by the launchpad and some
> extensions are just there for demo and other purposes...
Yes, I thought of this as well, but couldn't come up with a good 
explanation and categories :( If we just have "extensions" this will 
grow to a very large number over time. But on the other hand it's just a 
directory grouping, so we can change this later on, without any problems.

> Hmm... I have my reservations with the name "core-components". First it
> is long - and I don't like long names and second: This would give a
> groupId of o.a.s.core.components and an bundle symbolic name of
> org.apache.sling.core.components.core for the (today's) sling/core
> bundle ...
> 
> But we could of course rename the sling folder to core and rename the
> sling/core module to core/engine - because that module essentially
> contains the main request processing machinery.
Might work.

> 
> The question still remains: What is really "core" ? The Sling API in
> fact would be core, what else ? Maybe we should change completely ? Move
> sling/core to a top-level engine bundle (besides api the only toplevel
> bundle. And rename the current sling directory to servlets - because it
> just contains the servlet resolver as well as the get and post servlets.
:) Yes, I had this idea as well and so far it seems to be the best 
option. So, let's move core to top level as "engine", move the 
extensions from the current "sling" dir to "extensions" and rename 
"sling" to "servlets".

Sounds good to me.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Cleaning up our modules (Part V)

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Dienstag, den 13.05.2008, 13:04 +0200 schrieb Carsten Ziegeler:
> looking at the contents we have there core, 
> i18n, httpauth, bundleresource, servlet-resolver,servlets-get, 
> servlets-post.
> 
> Most of them are central and it wouldn't make much sense to start Sling 
> without them (except of course you provide an alternative 
> implementation). I consider all of them except i18n and httpauth to be 
> central. So I suggest we move i18n and httpauth to extensions (please 
> note that this change does not come with any other requirements like 
> changing artifacts or packaging, so it's just a simple move)

Agreed. In fact, bundleresource is probably also an extension...

We might want to start thinking of required and optional extensions ;-)
Because some extensions are required and used by the launchpad and some
extensions are just there for demo and other purposes...

> 
> Bertrand suggested to name all of this "core-components" which I think 
> is a much better name than "sling". This dir would then contain the core 
> itself and the most important bundles (except the jcr and scripting stuff).

Hmm... I have my reservations with the name "core-components". First it
is long - and I don't like long names and second: This would give a
groupId of o.a.s.core.components and an bundle symbolic name of
org.apache.sling.core.components.core for the (today's) sling/core
bundle ...

But we could of course rename the sling folder to core and rename the
sling/core module to core/engine - because that module essentially
contains the main request processing machinery.

The question still remains: What is really "core" ? The Sling API in
fact would be core, what else ? Maybe we should change completely ? Move
sling/core to a top-level engine bundle (besides api the only toplevel
bundle. And rename the current sling directory to servlets - because it
just contains the servlet resolver as well as the get and post servlets.

Regards
Felix

Re: [RT] Cleaning up our modules (Part V)

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
>> I think the remaining part is the "sling" directory. I'm not sure if 
>> this contains some extensions we could move to the extensions dir?
> 
> Wasn't that part of an earlier "Cleaning up our modules" approach ?
> 
No, we only moved eventing and scheduling to extensions but didn't 
discuss the other things.

>> And I think we should find a better name than "sling" for this directory 
>> as everything is Sling :) (it made sense when we distinguished between 
>> micro sling and sling). So any good idea?
> 
> Sorry, no. Except perhaps "Catapult" ;-)
Hehe, +1 :) Ok, seriously, looking at the contents we have there core, 
i18n, httpauth, bundleresource, servlet-resolver,servlets-get, 
servlets-post.

Most of them are central and it wouldn't make much sense to start Sling 
without them (except of course you provide an alternative 
implementation). I consider all of them except i18n and httpauth to be 
central. So I suggest we move i18n and httpauth to extensions (please 
note that this change does not come with any other requirements like 
changing artifacts or packaging, so it's just a simple move)

Bertrand suggested to name all of this "core-components" which I think 
is a much better name than "sling". This dir would then contain the core 
itself and the most important bundles (except the jcr and scripting stuff).

> 
>> And the last thing I noticed is that commons testing now contains 
>> references to other sling modules which is a little bit against the idea 
>> of commons being independent from Sling. As the testing stuff is about 
>> jcr testing, we could move it to the jcr modules?
>> (This one is not that important though)
> 
> There are two, actually: Sling API and Sling JCR API. Both are API-only
> bundles and both are present because the commons/testing bundle
> implements Mock classes for the respective APIs. I am fine with these
> dependencies.
Yes, they're fine and make sense of course. Would you mind if we move 
the testing stuff from commons to jcr?

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [RT] Cleaning up our modules (Part V)

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Dienstag, den 13.05.2008, 08:30 +0200 schrieb Carsten Ziegeler:
> Hi,
> 
> it seems that we are nearly through - so this could be the last part of 
> the series for now :)

Great !!

> I think the remaining part is the "sling" directory. I'm not sure if 
> this contains some extensions we could move to the extensions dir?

Wasn't that part of an earlier "Cleaning up our modules" approach ?

> And I think we should find a better name than "sling" for this directory 
> as everything is Sling :) (it made sense when we distinguished between 
> micro sling and sling). So any good idea?

Sorry, no. Except perhaps "Catapult" ;-)

> And the last thing I noticed is that commons testing now contains 
> references to other sling modules which is a little bit against the idea 
> of commons being independent from Sling. As the testing stuff is about 
> jcr testing, we could move it to the jcr modules?
> (This one is not that important though)

There are two, actually: Sling API and Sling JCR API. Both are API-only
bundles and both are present because the commons/testing bundle
implements Mock classes for the respective APIs. I am fine with these
dependencies.

We should take care to not add more - e.g. like I did adding the
sling/core dependency, which was really a bad idea.

Regards
Felix