jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.stras...@gmail.com>
Subject Re: Rethinking the great split
Date Fri, 29 Jul 2005 16:53:11 GMT
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 <jukka@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 >---

Mime
View raw message