Re: Rethinking the great split

["Roy T. Fielding" <fi...@gbiv.com>]

On Jul 26, 2005, at 4:36 PM, Jukka Zitting wrote:

> After a few weeks of working with the post JCR-157 Jackrabbit 
> structure, I've started thinking about partially reverting the 
> restructuring. The main reasons for this are:
>
> * Managing the current Jackrabbit build environment is relatively hard 
> even with the multiproject plugin being used.
> * There is no longer a single Jackrabbit jar with an associated set of 
> dependencies, leading to more complex documentation and deployment 
> issues.
> * There is no obvious way to avoid navigational issues across the 
> component sites generated by the current multiproject setup.
> * The unit test, checkstyle, and other reports are split over the 
> component projects
> * The component structure points the way towards an even more 
> fragmented project structure with separate component projects for 
> example for individual persistence managers (see the recent "build 
> problems" thread)
>
> Even though I greatly appreciate the benefits of the restructuring 
> (especially the commons library that I'm already using in a few other 
> projects) I've come to feel that the problems outweight the benefits.

Me too -- I've tried several times to recover a decent website build
from the split directories and I am ready to give up.  Since nobody
else has built the site since the split was made, I think it is a
dead end that is hampering progress.

Moving contrib to sandbox also needs to be done, and then deciding
what else needs to be completed before a 1.0 release.

> So, I'd like to propose to partially undo the changes related to 
> JCR-157. Instead of the full api, commons, and core subprojects, I'd 
> propose using package naming and design conventions to manage these 
> components. We could have o.a.j.{api,commons,core} packages within a 
> top-level ./src/main/java source directory. Additional component 
> packages (like o.a.j.rmi) could be used if major contrib projects were 
> to be fully integrated with Jackrabbit. The design constraints (like  
> no Jackrabbit dependencies in commons) could be enforced either 
> manually or with some custom Checkstyle checks. The separate api and 
> commons jar files could still be generated by a Maven postGoal rule. 
> This change would solve above problems while still providing at least 
> some of the original benefits.
>
> Comments?

We seem to have no end of bad names.  None of {api,commons,core}
are meaningful.  api is just a placeholder for javax.jcr.
commons should be o.a.j.util.  core should be o.a.j.jcr.

I'd like to have some kind of grouping/distinction of things
like rmi and webdav that act as network client interfaces.
Would "org.apache.jackrabbit.via.rmi" be okay?

....Roy

Re: Rethinking the great split

[Tobias Bocanegra <to...@day.com>]

> >> We seem to have no end of bad names.  None of {api,commons,core}
> >> are meaningful.  api is just a placeholder for javax.jcr.
> > btw, i thought, org.apache.jackrabbit is a placeholder for javax.jcr
> > :-)
> 
> cute.
please? org.apache.jackrabbit.api was not though to be a placeholder
for javax.jcr, it was though of the API of jackrabbit. have you ever
tried to register a nodetype in jackrabbit without using 'core'
methods?

> >> core should be o.a.j.jcr.
> > i disagree. o.a.j.core is totally ok.
> 
> core is what you get with a segfault, which is why many Unix backup
> systems won't save anything named "core" or under a "core" directory.
speeking of bad naming...it's a pity they havn't named it
'processimage' or something more descriptive, since that's what it is.
'core' is as descriptive as 'apple' or 'potatoe'.

> "o.a.j.jcr" makes it clear that the code within implements the
> "javax.jcr" interface.
well, is still disagree...

> I am really looking forward to getting the tree together again
> so that we can start the 1.0 release discussion.

perhaps we could vote on:
1) reverting 'the great split'
2) 'dropping' the jackrabbit API
3) renaming org.apache.jackrabbit.core to org.apache.jackrabbit.jcr
4) moving all 'commons' to org.apache.jackrabbit.util.

cheers, tobi

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Re: Rethinking the great split

["Roy T. Fielding" <fi...@gbiv.com>]

On Sep 7, 2005, at 2:07 AM, Tobias Bocanegra wrote:

>> Me too -- I've tried several times to recover a decent website build
>> from the split directories and I am ready to give up.  Since nobody
>> else has built the site since the split was made, I think it is a
>> dead end that is hampering progress.
>
> well, i still believe that the split is good, especially,
> if we want to develop the jackrabbit api in future. could everything
> be put into one sole codebase of course, but it will be more
> difficult to find cyclic dependencies, etc. if the project grows 
> bigger.
> from my experience with larger, multi-module projects, it is
> crucial to separate the build processes of the individual modules.

When it grows bigger, maybe, but not now.  Jackrabbit is a
project for implementing an API (JCR).  Having some other thing
in the project also called the Jackrabbit API is just too confusing.
In any case, the dependencies are wrong and maven multiproject is
not the way to build stable APIs.  When we want to create a
stable client API beyond JCR, we create a separate interface
definition with its own name and versioning.  There is no need
for separate build trees.

> having a set of good maven goals solves a lot of the multiproject
> problems. i must admit, that i did not invest a lot of time
> adjusting the maven files, i though that there are other
> developers with more maven experience than i have.

It is more than that -- I've already spent a week trying to get
multiproject to generate a usable tree of documentation.  Maven
treats them as separate islands of code/test/docs without any
connections between them -- the menu that multiproject:site
generates is a joke.  It is far easier to build all of the
components as a single project and then use custom xdocs to
describe the architecture, since then all of the detailed
interface xrefs are generated automatically.

> but if it is the common wish, i will adjust the files so that:
>
> - a comprehensive site, including the 'modules', 'contribs' external
>   docs, etc is built.
> - add a mechanism for handling the transitive dependencies
>   (imo, maven 2 is not ready, yet)
>
>> We seem to have no end of bad names.  None of {api,commons,core}
>> are meaningful.  api is just a placeholder for javax.jcr.
> no. api will contain the jackrabbit API with methods that are
> currently not available in jcr (nodetypes, QName, etc). and this
> will be the base for the future jcr 2.0.  it is a pity that few
> efforts were made in creating such an api, since the split.
>
> btw, i thought, org.apache.jackrabbit is a placeholder for javax.jcr 
> :-)

cute.

>> commons should be o.a.j.util.
> ok,
>
>> core should be o.a.j.jcr.
> i disagree. o.a.j.core is totally ok.

core is what you get with a segfault, which is why many Unix backup
systems won't save anything named "core" or under a "core" directory.
"o.a.j.jcr" makes it clear that the code within implements the
"javax.jcr" interface.

>> I'd like to have some kind of grouping/distinction of things
>> like rmi and webdav that act as network client interfaces.
>> Would "org.apache.jackrabbit.via.rmi" be okay?
> ok for me.

I am really looking forward to getting the tree together again
so that we can start the 1.0 release discussion.

....Roy

Re: Rethinking the great split

[Tobias Bocanegra <to...@day.com>]

> Me too -- I've tried several times to recover a decent website build
> from the split directories and I am ready to give up.  Since nobody
> else has built the site since the split was made, I think it is a
> dead end that is hampering progress.

well, i still believe that the split is good, especially,
if we want to develop the jackrabbit api in future. could everything
be put into one sole codebase of course, but it will be more 
difficult to find cyclic dependencies, etc. if the project grows bigger.
from my experience with larger, multi-module projects, it is
crucial to separate the build processes of the individual modules.

having a set of good maven goals solves a lot of the multiproject
problems. i must admit, that i did not invest a lot of time 
adjusting the maven files, i though that there are other 
developers with more maven experience than i have.

but if it is the common wish, i will adjust the files so that:

- a comprehensive site, including the 'modules', 'contribs' external
  docs, etc is built.
- add a mechanism for handling the transitive dependencies 
  (imo, maven 2 is not ready, yet)
  
> We seem to have no end of bad names.  None of {api,commons,core}
> are meaningful.  api is just a placeholder for javax.jcr.
no. api will contain the jackrabbit API with methods that are
currently not available in jcr (nodetypes, QName, etc). and this
will be the base for the future jcr 2.0.  it is a pity that few 
efforts were made in creating such an api, since the split.

btw, i thought, org.apache.jackrabbit is a placeholder for javax.jcr :-)

> commons should be o.a.j.util.
ok,

> core should be o.a.j.jcr.
i disagree. o.a.j.core is totally ok.

> I'd like to have some kind of grouping/distinction of things
> like rmi and webdav that act as network client interfaces.
> Would "org.apache.jackrabbit.via.rmi" be okay?
ok for me.

cheers, tobi

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Re: Rethinking the great split

[Jukka Zitting <jz...@yukatan.fi>]

Hi,

Roy T. Fielding wrote:
> Me too -- I've tried several times to recover a decent website build
> from the split directories and I am ready to give up.  Since nobody
> else has built the site since the split was made, I think it is a
> dead end that is hampering progress.

Agreed. OK with everyone if I just move things back the way they were? 
Let's use that as a baseline for thinking what other structural changes 
to do before 1.0.

> I'd like to have some kind of grouping/distinction of things
> like rmi and webdav that act as network client interfaces.
> Would "org.apache.jackrabbit.via.rmi" be okay?

OK for me.

The more I think about the idea of promoting stable contrib (/sandbox) 
projects to the main source tree, the more I like it. It will create 
more maintenance issues as the main codebase grows, but I think the 
benefits for the build and deployment processes and documentation are 
worth the trouble.

BR,

Jukka Zitting