You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Darren Hartford <dh...@ghsinc.com> on 2006/11/22 20:45:45 UTC

Jackrabbit JCA 1.1 from ibiblio - wrong jcr dependency

Hmm...I thought the pom.xml for the Jackrabbit JCA got fixed, but it
didn't get updated.

Could someone update the pom.xml to replace from:

<dependency>
<groupId>jsr170</groupId>
<artifactId>jcr</artifactId>
<version>1.0</version>
</dependency>

To:
<dependency>
<groupId>javax.jcr</groupId>
<artifactId>jcr</artifactId>
<version>1.0</version>
</dependency>

Thanks,
-D

Re: Jackrabbit JCA 1.1 from ibiblio - wrong jcr dependency

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On 11/23/06, Marcel May <ma...@consol.de> wrote:
> There is actually a quite firm policy that once a pom is uploaded to the
> repo it will not get changed again. Having a reproducible build can only
> be assured if the given pom is immutable. Also, I believe the pom once
> downloaded is not getting fetched again (except for SNAPSHOTs). Solution
> would be to publish eg '1.1.01' :-(

Yes, we'll probably solve the dependency issues incrementally as we
make more releases.

About the repository immutability rule - I've seen the repository
owners being rather relaxed about this rule on some occasions. For
example some of the Jackrabbit POMs were actually modified to have the
javax.jcr dependency without even updating the associated MD5 sums or
notifying me to update the PGP signature.

I'm not totally happy with that but I understand the fine line between
repository stability and validity they are maintaining. I've been
trying to get a bit more involved with the repository maintenance to
better understand the underlying issues and hopefully help improve
also the Jackrabbit POM metadata. You're welcome to join
repository@apache.org if you're also interested.

BR,

Jukka Zitting

Re: Jackrabbit JCA 1.1 from ibiblio - wrong jcr dependency

Posted by Marcel May <ma...@consol.de>.
Hi!

There is actually a quite firm policy that once a pom is uploaded to the 
repo it will not get changed again. Having a reproducible build can only 
be assured if the given pom is immutable. Also, I believe the pom once 
downloaded is not getting fetched again (except for SNAPSHOTs). Solution 
would be to publish eg '1.1.01' :-(

A very nasty example is eg the commons-logging-1.1.pom which contains a 
compile dependency for javax.servlet:servlet-api:2.3 (!!!).  Even such 
an accidental slip is not getting fixed for the reasons mentioned above 
(see JIRA issue http://jira.codehaus.org/browse/MEV-392).

Cheers,
Marcel

Darren Hartford wrote:
> Hmm...I thought the pom.xml for the Jackrabbit JCA got fixed, but it
> didn't get updated.
>
> Could someone update the pom.xml to replace from:
>
> <dependency>
> <groupId>jsr170</groupId>
> <artifactId>jcr</artifactId>
> <version>1.0</version>
> </dependency>
>
> To:
> <dependency>
> <groupId>javax.jcr</groupId>
> <artifactId>jcr</artifactId>
> <version>1.0</version>
> </dependency>
>
> Thanks,
> -D
>   


Re: Jackrabbit JCA 1.1 from ibiblio - wrong jcr dependency

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On 11/22/06, Darren Hartford <dh...@ghsinc.com> wrote:
> Hmm...I thought the pom.xml for the Jackrabbit JCA got fixed, but it
> didn't get updated.
>
> Could someone update the pom.xml to replace from:
>
> <dependency>
> <groupId>jsr170</groupId>
> <artifactId>jcr</artifactId>
> <version>1.0</version>
> </dependency>
>
> To:
> <dependency>
> <groupId>javax.jcr</groupId>
> <artifactId>jcr</artifactId>
> <version>1.0</version>
> </dependency>

There's still an unresolved license issue with the JCR API jars being
distributed from the central Maven repository. See the following
issues for the details and current status:

   http://issues.apache.org/jira/browse/JCR-592
   http://jira.codehaus.org/browse/MAVENUPLOAD-1050

Until either Day grants an extra license for Maven distribution of the
JCR jars (as discussed in JCR-592 by Roy) or the issue is resolved in
some other way, we won't be updating the POM dependencies.

BR,

Jukka Zitting