jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: build problems
Date Mon, 11 Jul 2005 10:51:07 GMT
On Jul 11, 2005, at 2:48 AM, Jukka Zitting wrote:

> Thanks for the +1s. Roy, what do you think, can I go on implementing 
> the proposal or do you want to tweak the Maven setup yourself? Are you 
> using the standard Maven site goal to generate the site, or are there 
> some special steps I should be aware of?

I was using "maven site:deploy".  I was going to replace that with
"maven multisite:site-deploy" as per the docs, though it did not
seem to work with projects at depth > 1.  It may be better to
override "maven site" in the top-level build, but that is as far
as I got before getting sidetracked.

> Stefan Guggisberg wrote:
>> in general +1; however, if the subprojects were to be included in the
>> top level multiproject it should still be possible to build 'just' 
>> jackrabbit
>> without the subprojects. i am a little worried that work on core 
>> could be hampered otherwise. there's still the possibility of 
>> necessary
>> major changes in the core that could break some subprojects.
>
> That's reasonable. OK, if the subprojects are included in the site 
> build as a postGoal? Alternatively we could separately commit the 
> generated subproject sites under site/subprojects.

I am going to disagree a little bit.  We need to figure out what
will be included in an eventual 1.0 release and build all of it.
The core cannot be allowed to break the rest of the release as we
do today, so we need to be in the habit of making such changes
across the entire code base in a single commit.  With that perspective
in mind, I'd like to move "contrib" to "sandbox" and organize
everything else according to their function within Jackrabbit.

I should be able to look at the release directories and have a clue
what each part does for Jackrabbit. "core", "api", "commons",
"jcr-server", "jcr-ext", and "jcr-rmi" are all terrible names for
trying to explain to a developer where to look for what functions.

Also, I don't believe Apache should have visible subprojects.
Projects have a habit of forgetting that they are responsible
for the entire contents of version control and subprojects
get twisted into fiefdoms.

So, for those reasons, I would prefer

jackrabbit/
          ./shared      (jackrabbit code used by below modules and 
jcr-ext)
          ./jcr         (everything needed for JCR implementation)
          ./examples    (buildable usage examples)
          ./gateways
                  ./orm2jcr
                  ./rmi2jcr
                  ./taglib2jcr
                  ./webdav2jcr
                  ...
          ./persistence
                  ./jcr2fs
                  ./jcr2jdbc
                  ...
          ./sandbox     (not included in release jars)
                  ./textfilters
                  ./phpcr
                  ...
          ./test
                  ./jmeter-commands
                  ./tck-webapp
          ./xdocs

Would that make sense to someone working with Jackrabbit for
the first time?  I probably have less experience with the code
than anyone else at Day, but I think one of the reasons we have
so little documentation is because it is very difficult to
figure our where to start.

....Roy


Mime
View raw message