Craig L. Ching wrote:
Hi,
I'm trying to get the code to support the JCR explorer integrated into
the current trunk of sling, but I'm looking at the project dependencies
from the "org.apache.sling.servlets.get" project to the
"org.apache.sling.commons.json" project (since I have changes for both
of those) and wondering if the version shouldn't be set to the
development version, e.g. 2.0.3-incubator-SNAPSHOT. In other words:
not
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.commons.json</artifactId>
<version>2.0.2-incubator</version>
</dependency>
but
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.commons.json</artifactId>
<version>2.0.3-incubator-SNAPSHOT</version>
</dependency>
Certainly on your maintenance branch it should be set to a released
version, but not on your development branch? Shouldn't that be true for
all sling project inter-dependencies?
Hi,
this is actually a hot topic where people have different opinions. For
now we think that we should change dependencies between modules if there
is no reason for it. For instance in the example above if the servlets
get module does not need a newer version of the json module, there is no
reason to change the version number of the dependency.
This ensures that a module always refers to the lowest version it works
with.
Imagine that you want to change something in the servlets get module
(and this doesn't require changes in other modules). With our current
module you can just do your changes and upload the bundle into your app.
You know that you've already deployed 2.0.2 of json etc.
If we would have changed the dependency to 2.0.3-incubator-SNAPSHOT for
the json module, you would first need to build the snapshot of the json
module, deploy that before you can deploy your servlets get module. And
in the end this wouldn't be required, but you can't tell this from
looking at the pom.
HTH
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
