You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <Fe...@day.com> on 2005/05/17 13:04:54 UTC
Dependency on cqfs-jackrabbit
Hi all,
The Jackrabbit project contains a dependency on "cqfs-jackrabbit" and
"cqfs" provided by Day Software. The former contains a single class
CQFileSystem implementing the "org.apache.jackrabbit.core.fs.FileSystem"
to provide an alternative for Jackrabbit's own LocalFileSystem
implementation. This dependency is part of the Jackrabbit project such
that this implementation is available to the test cases for them to run
faster on Windows-based development boxes.
The problem with this project-level dependency is that the
cqfs-jackrabbit project contains a dependency on the Jackrabbit project
to get the interface to be implemented. Now there is a cyclic dependency
which is not good conceptually and which creates a bootstrap problem.
I would like to break this cyclic dependency by removing the cqfs
dependency from Jackrabbit altogether. This would result in the tests
being configured to use LocalFileSystem instead of CQFileSystem.
Consequently performance - esp. on Windows boxes - would suffer. Simple
tests on Windows XP show, that a full build with test runs take around
10-11 minutes with LocalFileSystem compared to around 5-6 minutes with
CQFileSystem. The same hardware running Fedora Core 3 runs the full
build cycle in 4-5 minutes regardless of whether LocalFileSystem or
CQFileSystem is used.
Nothing would of course prevent developers from configuring tests on
their local platform with more performing FileSystem implementations.
What do you think ?
Regards
Felix Meschberger
Re: Dependency on cqfs-jackrabbit
Posted by Marcel Reutegger <ma...@gmx.net>.
Since the cqfs-*.jars are available from a maven repository I don't
think there is a bootstrap problem. sure, if you have to build both from
the sources you will have to temprarily remove the cqfs dependency from
jackrabbit. jackrabbit will still compile because cqfs is only a
dependency that is needed when configured that way.
If I'm the only one using a windows machine I would be ok with removing
the dependency, but I guess I'm not.
regards
marcel
Felix Meschberger wrote:
> Hi all,
>
> The Jackrabbit project contains a dependency on "cqfs-jackrabbit" and
> "cqfs" provided by Day Software. The former contains a single class
> CQFileSystem implementing the "org.apache.jackrabbit.core.fs.FileSystem"
> to provide an alternative for Jackrabbit's own LocalFileSystem
> implementation. This dependency is part of the Jackrabbit project such
> that this implementation is available to the test cases for them to run
> faster on Windows-based development boxes.
>
> The problem with this project-level dependency is that the
> cqfs-jackrabbit project contains a dependency on the Jackrabbit project
> to get the interface to be implemented. Now there is a cyclic dependency
> which is not good conceptually and which creates a bootstrap problem.
>
> I would like to break this cyclic dependency by removing the cqfs
> dependency from Jackrabbit altogether. This would result in the tests
> being configured to use LocalFileSystem instead of CQFileSystem.
> Consequently performance - esp. on Windows boxes - would suffer. Simple
> tests on Windows XP show, that a full build with test runs take around
> 10-11 minutes with LocalFileSystem compared to around 5-6 minutes with
> CQFileSystem. The same hardware running Fedora Core 3 runs the full
> build cycle in 4-5 minutes regardless of whether LocalFileSystem or
> CQFileSystem is used.
>
> Nothing would of course prevent developers from configuring tests on
> their local platform with more performing FileSystem implementations.
>
> What do you think ?
>
> Regards
> Felix Meschberger
>
>
>
Re: Dependency on cqfs-jackrabbit
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
>both cqfs & cqfs-jackrabbit are runtime dependencies only
>and commented as such in project.xml. there's no problem
>of cyclic dependencies when building jackrabbit because
>both jars are automatically downloaded by maven from day's
>repository.
>
>
True, so these dependencies could be removed from the project.xml.
But they are in there because they are needed for the build-time tests.
So of tests are running during the builds the dependencies become more
than just runtime dependencies, they become build-time dependencies and
you are back where you started.
>i cannot see any urging technical reason why we should remove
>cqfs-jackrabbit and cqfs from the project.xml, especially so when
>considering its trade-off (doubling the runtime of the test cases :(.
>
>
There is of course no urging technical reason because we already have
the basic bootstrapping issue - call it a chicken and egg problem if you
wish - behind us.
It is just that cyclic dependencies between two projects are never good,
regardless of whether there is an urging technical reason to break it or
not.
Regarding the performance of the test cases: Use a decent operating
system such as Linux and you gain in overall performance :-)
Regards
Felix
Re: Dependency on cqfs-jackrabbit
Posted by Stefan Guggisberg <st...@gmail.com>.
On 5/17/05, Felix Meschberger <Fe...@day.com> wrote:
> Hi all,
>
> The Jackrabbit project contains a dependency on "cqfs-jackrabbit" and
> "cqfs" provided by Day Software. The former contains a single class
> CQFileSystem implementing the "org.apache.jackrabbit.core.fs.FileSystem"
> to provide an alternative for Jackrabbit's own LocalFileSystem
> implementation. This dependency is part of the Jackrabbit project such
> that this implementation is available to the test cases for them to run
> faster on Windows-based development boxes.
>
> The problem with this project-level dependency is that the
> cqfs-jackrabbit project contains a dependency on the Jackrabbit project
> to get the interface to be implemented. Now there is a cyclic dependency
> which is not good conceptually and which creates a bootstrap problem.
>
> I would like to break this cyclic dependency by removing the cqfs
> dependency from Jackrabbit altogether. This would result in the tests
> being configured to use LocalFileSystem instead of CQFileSystem.
> Consequently performance - esp. on Windows boxes - would suffer. Simple
> tests on Windows XP show, that a full build with test runs take around
> 10-11 minutes with LocalFileSystem compared to around 5-6 minutes with
> CQFileSystem. The same hardware running Fedora Core 3 runs the full
> build cycle in 4-5 minutes regardless of whether LocalFileSystem or
> CQFileSystem is used.
>
> Nothing would of course prevent developers from configuring tests on
> their local platform with more performing FileSystem implementations.
>
> What do you think ?
both cqfs & cqfs-jackrabbit are runtime dependencies only
and commented as such in project.xml. there's no problem
of cyclic dependencies when building jackrabbit because
both jars are automatically downloaded by maven from day's
repository.
i cannot see any urging technical reason why we should remove
cqfs-jackrabbit and cqfs from the project.xml, especially so when
considering its trade-off (doubling the runtime of the test cases :(.
hence -1 for removing cqfs-jackrabbit and cqfs from project.xml
cheers
stefan
>
> Regards
> Felix Meschberger
>
>