Re: [M10N] cocoon-jcr
David Nuescheler wrote: hi sylvain, does this help? http://www.day.com/maven/jsr170/licenses/day-spec-license.htm if i can do anything else to help, please let me know. it clearly is our intention that everybody should be able to redistribute the jcr-1.0.jar well, I will use your statement in front of a court (maybe in the future) to argue why we redistributed jcr-1.0.jar ;-) Although I am not sure if the word intention is enough versus the end of the second para: No license is granted hereunder for any other purpose (including, for example, modifying the Specification, other than to the extent of your fair use rights, or distributing the Specification to third parties) or am I misunderstanding something? Or what is the context of distributing the Specification to third parties? Thanks Michi regards, david -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [M10N] cocoon-jcr
David Nuescheler wrote: Hi, Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. As far as I am concerned, I would argue that based on the JCP licensing the Spec-Lead of a JSR as the owner of the intellectual property is probably the most legitimate source to distribute the resulting JAR-File of an API. Thoughts? The problem is not about where we get the API jar from, but the licence that covers it. I couldn't find it except on the JCP dowload page where a specific Day/JCP licence is shown. The whole question is to know if the JCR API is under an Apache-compatible licence and if we can redistribute it with an Apache product. I hope so, but couldn't find any formal confirmation of it. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [M10N] cocoon-jcr
hi sylvain, does this help? http://www.day.com/maven/jsr170/licenses/day-spec-license.htm if i can do anything else to help, please let me know. it clearly is our intention that everybody should be able to redistribute the jcr-1.0.jar regards, david
Re: [M10N] cocoon-jcr
David Nuescheler wrote: hi sylvain, does this help? http://www.day.com/maven/jsr170/licenses/day-spec-license.htm I found that one, but IANAL and I can't say if this text allows redistribution with an Apache-licenced product... I guess Roy should be able to tell us. if i can do anything else to help, please let me know. it clearly is our intention that everybody should be able to redistribute the jcr-1.0.jar I know that :-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jan 2006, Giacomo Pati wrote: Date: Thu, 12 Jan 2006 08:51:12 +0100 (CET) From: Giacomo Pati [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr --[PinePGP]--[begin]-- On Thu, 12 Jan 2006, Jorg Heymans wrote: Date: Thu, 12 Jan 2006 00:19:47 +0100 From: Jorg Heymans [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati wrote: In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. I've never actually used it, but the dependencyManagement [1] element is all about centrally managing dependency versions. Thanks. I've probably overlooked that. Seems to be a possibility we have to keep an eye on in case we do have to manage dependencies in a more general and centralized way for all our blocks to prevent version clashes (until we have classloader isolation for blocks). And BTW this might help keeping oversight for upgrading dependencies (which version do we use compared to which are available) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxhABLNdJvZjjVZARAralAJ4+EDOR4Gjn9cCYI+KX0Lx/inCDhACg2+V1 U50pJpAQYOJnR3SlzG0tOGw= =38L8 -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
Hi, This must be a typo because as far as I know, there is only a jcr-1.0.jar which is the API library for the JCR: Hope, this helps. Regards Felix Meschberger Stefano Mazzocchi schrieb: Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? I'm copying this to jackrabbit-dev because I honestly don't have an answer for this.
Re: [M10N] cocoon-jcr
Hi, Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. As far as I am concerned, I would argue that based on the JCP licensing the Spec-Lead of a JSR as the owner of the intellectual property is probably the most legitimate source to distribute the resulting JAR-File of an API. Thoughts? regards, david
[M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxPfnLNdJvZjjVZARAgjwAKComo2a5T2m/37CGYnCxX5IzDxSvQCfU0FO 6EQ/PEkqszPi4uUu8/BNg48= =igIG -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
Giacomo Pati schrieb: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? Dumb question, but why don't you use version 1.0 of tje jcr? We have this in our distribution for a very long time and I think it's also on the apache repository. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] cocoon-jcr
Carsten Ziegeler wrote: Giacomo Pati schrieb: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? Dumb question, but why don't you use version 1.0 of tje jcr? We have this in our distribution for a very long time and I think it's also on the apache repository. Ah ok, sorry for my too fast response. Although we have the 1.0 version in svn, the corresponding licence file is missing. So, if we are not allowed to redistribute this we should remove it asap. (And it would be good if people would not forget about the licence file when they add jars) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread Making a redist of all the javax.* packages) Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? Jorg
Re: [M10N] cocoon-jcr
Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. /Daniel
Re: [M10N] cocoon-jcr
Daniel Fagerstrom schrieb: Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Actually, I meant 2.1.x where it is easy to see on what we depend and which licenses we have. But from time to time it just happens. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. Yepp. I guess the site plugin with the reports is the way to go. It should list all dependencies. I tried it out before 2.0 was out, but it failed...perhaps it's now working? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [M10N] cocoon-jcr
Daniel Fagerstrom wrote: With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. Check out the sample reports in [1]. The dependencies report turns up empty for cocoon-core though, there might be some additional info still missing. Jorg [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/
Re: [M10N] cocoon-jcr
Jorg Heymans wrote: Daniel Fagerstrom wrote: With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. Check out the sample reports in [1]. The dependencies report turns up empty for cocoon-core though, there might be some additional info still missing. Yes, that is the kind of report I'm looking for. So besides getting any content in the reports, we would need a dynamically updated Maven site for Cocoon. Then the project dependencies report should contain a licence URL by default, with some really disturbing visual desing for the case when the POM doesn't contain license info, so that it creates a social pressure to include licens info in all POMs ;) /Daniel [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/
Re: [M10N] cocoon-jcr
Jorg Heymans wrote: Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread Making a redist of all the javax.* packages) Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? careful. JCR is *NOT* part of J2EE, so looking for them in Geronimo is the wrong place. The reference implementation of JCR is JackRabbit, currently under incubation. NOTE: unlike much of the sun stuff, JCR is released under a compatible license that was written by our very own Roy Fielding and is very similar to the Apache License 2.0, and designed to be compatible with it. I don't know the status of the licensing releasing of JCR, though, but I'm sure the email I copied on jackrabbit will give us the answers we want. -- Stefano.
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? I'm copying this to jackrabbit-dev because I honestly don't have an answer for this. -- Stefano.
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Carsten Ziegeler wrote: Date: Wed, 11 Jan 2006 13:26:35 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati schrieb: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? Dumb question, but why don't you use version 1.0 of tje jcr? We have this in our distribution for a very long time and I think it's also on the apache repository. I must have had blinders on when looking into lib/optional. Sure we use jcr-1.0 not jcr-1.1. But anyway, couldn't find one on our repos nor on ibiblio. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxV8ELNdJvZjjVZARAgyGAJ9rd0jXjlFUj1yFVWUvRTqCOj+AkQCePUUc gSW65lpAX7Ci+fa8zeyrL5s= =svDF -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Jorg Heymans wrote: Date: Wed, 11 Jan 2006 14:40:02 +0100 From: Jorg Heymans [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati wrote: I'm trying to get the cocoon.jcr block compiling but cannot find a jcr-1.1.jar to download from any of the maven repos I know of. Anybody knows of one? I've found a jcr-1.0.jar at http://www.day.com/maven/jsr170/jars/ but I don't want to list the Day server in our poms. I also don't know whether that one is publically redistributable and the Maven 2 docs suggests downloading it from the official Sun site and installing it into each ones local Maven2 repository. Any ideas how to solve this? This is mentioned in the maven docs (though of not much help) : http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html Also read the discussion on repository@apache.org : http://mail-archives.apache.org/mod_mbox/www-repository/200512.mbox/thread (thread Making a redist of all the javax.* packages) Aren't there geronimo packages available for this, like eg geronimo-spec-javamail.jar ? Geronimo has all kinds of spec jars but not JCR :-( - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxWBaLNdJvZjjVZARAoO3AJ41ArVEvT9kzyk5mg6NUtRJuH5EUACgrO2R 348Fm6cqb6AOGYftxp1fFgs= =5yXD -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Daniel Fagerstrom wrote: Date: Wed, 11 Jan 2006 16:48:10 +0100 From: Daniel Fagerstrom [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. I was to write a mail about it but you raised it before. We are at the same trap as Maven 1 multiproject concerning dependencies. We will fall into it as well (maybe even faster because of transitive deps). BlockA depends on jarB-1.0 which depends on jarC-1.0 BlockD depends on jarE-1.0 which depends on jarC-2.0 BlockF depends on BlockA and depends on BlockD Version 1.0 and 2.0 of jarC are incompatible wrt backward compatibility. And voila we have the desaster. The above chain might look overseeable but imagine the chain is 5 times deeper. You might exclude jarC-2.0 from dependency resolution, after a possibly excessive debugging session where you finally figured you have a version problem, and hope all still runs well. OSGI blocks may solve this (with classloader isolation) but ATM we don't have it. Anybody solved this in an elegant way - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxWhMLNdJvZjjVZARAtLnAJ0VcA+4JV4/jrOfzkKCXIeOGz+YZwCeM/Df WRP4gWw6BIHKVCQQXLwOI8U= =z4gn -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jan 2006, Giacomo Pati wrote: Date: Wed, 11 Jan 2006 21:19:22 +0100 (CET) From: Giacomo Pati [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr --[PinePGP]--[begin]-- On Wed, 11 Jan 2006, Daniel Fagerstrom wrote: Date: Wed, 11 Jan 2006 16:48:10 +0100 From: Daniel Fagerstrom [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Carsten Ziegeler wrote: ... (And it would be good if people would not forget about the licence file when they add jars) With M2s transitive dependence handling it is harder to keep track of what we actually depend on. Is there some reporting plugin or switch, so that one can get a report of all dependencies of a block or a multi project POM? Otherwise we risk to get an unwelcome suprise when we genrate a binary release. I was to write a mail about it but you raised it before. We are at the same trap as Maven 1 multiproject concerning dependencies. We will fall into it as well (maybe even faster because of transitive deps). BlockA depends on jarB-1.0 which depends on jarC-1.0 BlockD depends on jarE-1.0 which depends on jarC-2.0 BlockF depends on BlockA and depends on BlockD Version 1.0 and 2.0 of jarC are incompatible wrt backward compatibility. And voila we have the desaster. The above chain might look overseeable but imagine the chain is 5 times deeper. You might exclude jarC-2.0 from dependency resolution, after a possibly excessive debugging session where you finally figured you have a version problem, and hope all still runs well. OSGI blocks may solve this (with classloader isolation) but ATM we don't have it. Anybody solved this in an elegant way In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxW5OLNdJvZjjVZARAnB8AKDGx4MFW2/BX3oXdr+KPySYzQV0lQCfRl7n B/CJ8ikMJjRF8RqQ1J9wXOo= =bmDr -END PGP SIGNATURE-
Re: [M10N] cocoon-jcr
Giacomo Pati wrote: In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. I've never actually used it, but the dependencyManagement [1] element is all about centrally managing dependency versions. HTH Jorg [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Re: [M10N] cocoon-jcr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jan 2006, Jorg Heymans wrote: Date: Thu, 12 Jan 2006 00:19:47 +0100 From: Jorg Heymans [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [M10N] cocoon-jcr Giacomo Pati wrote: In a big multiproject Maven 1 project we solved this by an entity file in the root directory where all dependant jar had entities for their groupId, artifactId and version (strictly sorted by groupId and artifactId) and each (sub) project.xml file included it and used those entity to define their individual dependency. This way we prevented version clashes easily and relatively early. This has worked fine (even if not recommended by Maven itself. In another project it has hit us hard when we used automated integration tests with Continuum which wasn't able to locate the entity file anymore because of relative paths in the project.xml. I've never actually used it, but the dependencyManagement [1] element is all about centrally managing dependency versions. Thanks. I've probably overlooked that. Seems to be a possibility we have to keep an eye on in case we do have to manage dependencies in a more general and centralized way for all our blocks to prevent version clashes (until we have classloader isolation for blocks). - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxgp4LNdJvZjjVZARAjzkAJ9kJEL46BDHw3wX5C6MF2igeCXKEQCgtXda PSOLSfpogxJMT22sEfdtJho= =LIJM -END PGP SIGNATURE-
