You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@zitting.name> on 2005/07/27 01:36:23 UTC
Rethinking the great split
Hi,
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.
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?
BR,
Jukka Zitting
Re: Rethinking the great split
Posted by 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
Posted by "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
Posted by 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
Posted by 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
Re: Rethinking the great split
Posted by "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
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Tobias wrote:
> i´m curently on vacation and have limited internet access, so lets
> dicuss this issue next week.
OK, no need to hurry. Have a nice vacation!
BR,
Jukka Zitting
Re: Rethinking the great split
Posted by Tobias Bocanegra <to...@gmail.com>.
hi,
i´m curently on vacation and have limited internet access, so lets
dicuss this issue next week.
cheers, tobi
On 7/27/05, Jukka Zitting <ju...@zitting.name> wrote:
> Hi,
>
> 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.
>
> 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?
>
> BR,
>
> Jukka Zitting
>
--
-----------------------------------------< 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
Posted by Stefan Guggisberg <st...@gmail.com>.
hi jukka,
On 7/27/05, Jukka Zitting <ju...@zitting.name> wrote:
> Hi,
>
> 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.
>
> 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?
personally i would be ok with the change you suggest. i too experienced
the same problems that you described. therefore +1 from me.
however, tobi who initiated the current structure might come up with issues
with the suggested re-restructuring.
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
Re: Rethinking the great split
Posted by Jérôme BENOIS <be...@argia-engineering.fr>.
I totally agree, Maven is good project but limited to manage
multiproject.
I had a same problems and now i am a Core-Developper of A.B.S. (Advanced
Build System). It's an ant tasks generator (all tasks are generated (on
the fly) by POM representation equivalent), see
http://abs.open-model.org.
ABS manage 2 concepts :
-> components : reusable source tree
-> projects : it's is an assembly of components
You can manage external libraries dependencies with 2 ant tasks :
dep:add.bin Add a new dependency to a binary component
dep:ls.bin List all binary dependencies
You can manage source dependencies (components dependencies) with 2 ant
tasks :
dep:add.src Add a new dependency to a source component
dep:ls.src List all source dependencies
And run unit tests or many others tasks :
test:java.all Run local Unit tests local and dependent components
test:java.local Run local Unit tests
...
For information, it's a young project but reactive (look the
changeLog ;-)) and a user guide is in the course of drafting !
And i could write news tasks for you ...
Jérôme.
--
The ABS team.
« Given enough eyeballs, all bugs are shallow »
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ABS ~ Advanced Build System ~
~ Next Generation Build System ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 2005-08-03 at 15:25 +0200, Tobias Bocanegra wrote:
> hi jukka,
>
> > * 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)
>
> i totally agree, that multiproject support is not solved very
> sophisticated in maven (at least in 1.0, i don't know about 2.0). for
> our own product, we use maven, but only to manage the build process.
> none of mavens site generation, unittest, etc. are used. we get the
> best overview of our modules / (sub)projects using eclipse or idea.
>
> > 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.
> >
> > 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.
>
> well, i can't see another nice way of doing this. so maybe a common
> source directory would be the easiest solution. however, we should
> also check the new features of maven 2.0 in respect of multiproject
> capabilities:
>
> http://maven.apache.org/maven2/about.html#features
> [...]
> - Superior dependency management including automatic updating, dependency
> closures (also known as transitive dependencies)
> - Able to easily work with multiple projects at a time
> [...]
>
> i will give it a try and see if maven 2.0 would offer the needs we are
> looking for.
> cheers, tobi
Re: Rethinking the great split
Posted by Jérôme BENOIS <be...@argia-engineering.fr>.
Hi,
On Wed, 2005-08-03 at 19:21 +0300, Jukka Zitting wrote:
> Hi,
>
> Tobias wrote:
> > well, i can't see another nice way of doing this. so maybe a common
> > source directory would be the easiest solution. however, we should
> > also check the new features of maven 2.0 in respect of multiproject
> > capabilities:
>
> The Maven 2.0 option sounds interesting. Great if you can take some time
> to experiment with it. If it works out fine, I'd be happy to go along,
> otherwise we can fall back to the old model.
>
> About the ABS proposal: While the project seems interesting, it seems to
> be too premature for our needs. Even if Maven hasn't got a good answer
> to all our needs, it still covers many of them most excellently. In my
> opinion the multiproject problem is nowhere near grave enough to warrant
> considering a switch from Maven.
OK, I understand you but ABS isn't a premature project, ABS is based on
Jakarta Ant, and Ant is very stable ;-)
Thanks for your response,
Jérôme.
>
> BR,
>
> Jukka Zitting
>
--
The ABS team.
« Given enough eyeballs, all bugs are shallow »
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ABS ~ Advanced Build System ~
~ Next Generation Build System ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Rethinking the great split
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Tobias wrote:
> well, i can't see another nice way of doing this. so maybe a common
> source directory would be the easiest solution. however, we should
> also check the new features of maven 2.0 in respect of multiproject
> capabilities:
The Maven 2.0 option sounds interesting. Great if you can take some time
to experiment with it. If it works out fine, I'd be happy to go along,
otherwise we can fall back to the old model.
About the ABS proposal: While the project seems interesting, it seems to
be too premature for our needs. Even if Maven hasn't got a good answer
to all our needs, it still covers many of them most excellently. In my
opinion the multiproject problem is nowhere near grave enough to warrant
considering a switch from Maven.
BR,
Jukka Zitting
Re: Rethinking the great split
Posted by Tobias Bocanegra <to...@gmail.com>.
hi jukka,
> * 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)
i totally agree, that multiproject support is not solved very
sophisticated in maven (at least in 1.0, i don't know about 2.0). for
our own product, we use maven, but only to manage the build process.
none of mavens site generation, unittest, etc. are used. we get the
best overview of our modules / (sub)projects using eclipse or idea.
> 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.
>
> 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.
well, i can't see another nice way of doing this. so maybe a common
source directory would be the easiest solution. however, we should
also check the new features of maven 2.0 in respect of multiproject
capabilities:
http://maven.apache.org/maven2/about.html#features
[...]
- Superior dependency management including automatic updating, dependency
closures (also known as transitive dependencies)
- Able to easily work with multiple projects at a time
[...]
i will give it a try and see if maven 2.0 would offer the needs we are
looking for.
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 >---