Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
Pier Fumagalli wrote: > David Crossley wrote: > >>> > >>>http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html > >> > >>Darn... I wish you found that when I posted the license before > >>committing... > >> > >>http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html > > > >The License that Pier shows in msg34406 is not > >the same one as was commented on in msg18202. > >The main comments do not match, only the nuclear > >thing still remains. > > As far as I can see I can't see any difference between the one that > was discussed in 2004 (the thread Antonio pointed out) and the one I > posted last week: > > Original 2k4 thread: > > http://www.mail-archive.com/dev@cocoon.apache.org/msg18195.html > > My post: > > http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html Ah i see now where my extra comments in msg18202 came from: I refererred to an additional file called "copyright.txt" which must have had extra restrictions. Don't know if that is still the same today. Anyway, legal-discuss@ is the place to take it and if it gets complex then Cliff will probably pick up the issue from there. -David
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On Sunday 11 September 2005 09:24, Pier Fumagalli wrote: > Skolnick or Wooley? Cliff Schmidt Cheers Niclas
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On 11 Sep 2005, at 01:23, Stefano Mazzocchi wrote: We have a Legal VP now :-) Pier, if you want to use that code, send a comment to Cliff. Skolnick or Wooley? Also, we could also tell sun to remove that clause or to relicense under CDDL. Nah, just make some mock classes and re-distribute... We've got 90% of the functionality in there implemented. Someone smart might even be able to use Xerces to do DTD validation, rather than using MSV. For now, I just want to finalize the API for validation and clean up that block... Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On 11 Sep 2005, at 01:19, David Crossley wrote: I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html The License that Pier shows in msg34406 is not the same one as was commented on in msg18202. The main comments do not match, only the nuclear thing still remains. As far as I can see I can't see any difference between the one that was discussed in 2004 (the thread Antonio pointed out) and the one I posted last week: Original 2k4 thread: http://www.mail-archive.com/dev@cocoon.apache.org/msg18195.html My post: http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html Pier smime.p7s Description: S/MIME cryptographic signature
svn line-endings config (Was: svn commit: r279905 - in /cocoon/site/site/link: livesites-2.1.html livesites-2.1.pdf)
Erk, something went wrong. This generated file has Windows end-of-line markers, so that makes it look like the whole file was changed. It is not your fault Jorg. The svn:eol-style property is not set, so this is the effect. Each time someone generates it on different platforms, then line endings will change and therefore huge diffs. I will try to clean up the mess. Would everyone please make sure that their SVN client is properly configured. http://www.apache.org/dev/version-control.html#https-svn -David > Author: jheymans > Date: Fri Sep 9 15:57:35 2005 > New Revision: 279905 > > URL: http://svn.apache.org/viewcvs?rev=279905&view=rev > Log: > publishing new livesites > > Modified: > cocoon/site/site/link/livesites-2.1.html > cocoon/site/site/link/livesites-2.1.pdf > > Modified: cocoon/site/site/link/livesites-2.1.html > URL: > http://svn.apache.org/viewcvs/cocoon/site/site/link/livesites-2.1.html?rev=279905&r1=279904&r2=279905&view=diff > == > --- cocoon/site/site/link/livesites-2.1.html (original) > +++ cocoon/site/site/link/livesites-2.1.html Fri Sep 9 15:57:35 2005 > @@ -1,687 +1,821 @@ > - "http://www.w3.org/TR/html4/loose.dtd";> > - > -
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
David Crossley wrote: Pier Fumagalli wrote: Antonio Gallardo wrote: Ralph Goers wrote: Ralph Goers wrote: I seem to remember reading on legal-discuss that the "nuclear clause" is incompatible with the ASL. If true, any components with such a license can not be disctributed with our code or reside in SVN. Ralph Faulty memory. The only reference I could find was at http:// wiki.apache.org/jakarta/LicenceIssues which, of course, is not "official" ASF policy. I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html The License that Pier shows in msg34406 is not the same one as was commented on in msg18202. The main comments do not match, only the nuclear thing still remains. We are not lawyers, so someone should clear this up with the ASF license-discuss list. We have a Legal VP now :-) Pier, if you want to use that code, send a comment to Cliff. Also, we could also tell sun to remove that clause or to relicense under CDDL. -- Stefano.
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
Pier Fumagalli wrote: > Antonio Gallardo wrote: > >Ralph Goers wrote: > >>Ralph Goers wrote: > >>> > >>>I seem to remember reading on legal-discuss that the "nuclear > >>>clause" is incompatible with the ASL. If true, any components > >>>with such a license can not be disctributed with our code or > >>>reside in SVN. > >>> > >>>Ralph > >>> > >>> > >>Faulty memory. The only reference I could find was at http:// > >>wiki.apache.org/jakarta/LicenceIssues which, of course, is not > >>"official" ASF policy. > > > >I found it! > > > >http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html > > Darn... I wish you found that when I posted the license before > committing... > > http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html The License that Pier shows in msg34406 is not the same one as was commented on in msg18202. The main comments do not match, only the nuclear thing still remains. We are not lawyers, so someone should clear this up with the ASF license-discuss list. -David
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
On 10 Sep 2005, at 20:17, Antonio Gallardo wrote: Ralph Goers wrote: Ralph Goers wrote: I seem to remember reading on legal-discuss that the "nuclear clause" is incompatible with the ASL. If true, any components with such a license can not be disctributed with our code or reside in SVN. Ralph Faulty memory. The only reference I could find was at http:// wiki.apache.org/jakarta/LicenceIssues which, of course, is not "official" ASF policy. I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Darn... I wish you found that when I posted the license before committing... http://www.mail-archive.com/dev@cocoon.apache.org/msg34406.html Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r279762 - in /cocoon/branches/BRANCH_2_1_X: legal/msv-20030225.jar.license.txt lib/optional/msv-20030225.jar src/blocks/validation/java/org/apache/cocoon/components/validation/Validator.java
Ralph Goers wrote: Ralph Goers wrote: I seem to remember reading on legal-discuss that the "nuclear clause" is incompatible with the ASL. If true, any components with such a license can not be disctributed with our code or reside in SVN. Ralph Faulty memory. The only reference I could find was at http://wiki.apache.org/jakarta/LicenceIssues which, of course, is not "official" ASF policy. I found it! http://www.mail-archive.com/dev@cocoon.apache.org/msg18202.html Best Regards, Antonio Gallardo Ralph
Re: cocoon maven repository
On Saturday 10 September 2005 23:33, Jorg Heymans wrote: > Stefan Podkowinski wrote: > > The project will be hosted on sourceforge so I can't really setup my > > own repository for this. Another option would be to ship dependencies > > not available on public repos with my distribution. But I want do > > avoid this if possible to keep download size for updates as small as > > possible. > > Actually, i think we have created a small m2 cocoon repository somewhere > on the Apache servers. I can't remember exactly where and how, but > possibly we could provide an m1 style repository as well. There is a general "avoid snapshots" policy for ASF repositories, as they will not be guaranteed to be there 'forever' which may cause trouble to users, and a "no snapshot" policy for the repository that gets replicated to ibiblio.org. If special builds, snapshots and what not can't be avoided, the best practice is probably to ship those explicitly. Cheers Niclas
Re: cocoon maven repository
Stefan Podkowinski wrote: > The project will be hosted on sourceforge so I can't really setup my > own repository for this. Another option would be to ship dependencies > not available on public repos with my distribution. But I want do > avoid this if possible to keep download size for updates as small as > possible. > Actually, i think we have created a small m2 cocoon repository somewhere on the Apache servers. I can't remember exactly where and how, but possibly we could provide an m1 style repository as well. WDOT? Jorg
Re: cocoon maven repository
The project will be hosted on sourceforge so I can't really setup my own repository for this. Another option would be to ship dependencies not available on public repos with my distribution. But I want do avoid this if possible to keep download size for updates as small as possible. On 9/10/05, Jorg Heymans <[EMAIL PROTECTED]> wrote: > > Stefan Podkowinski wrote: > > > I'm currently working on a project that does bundle the cform and > > portal block + core classes and is being build by maven1. This works > > quite well, the only problem is that some of cocoons dependencies > > cannot be found in the well known public repositories, mostly > > snapshot/dated jars such as rhino. > > > I usually put these in a company-wide maven proxy [1], not a perfect > solution but for apps deployed inside the company domain it does the trick. > > > dependences. Creating pom descriptors for each block would also be > > helpfull. > > pom descriptors are being created for every block yes. > > > Regards > Jorg > > [1] http://maven-proxy.codehaus.org/ > >
Re: cocoon maven repository
Stefan Podkowinski wrote: > I'm currently working on a project that does bundle the cform and > portal block + core classes and is being build by maven1. This works > quite well, the only problem is that some of cocoons dependencies > cannot be found in the well known public repositories, mostly > snapshot/dated jars such as rhino. > I usually put these in a company-wide maven proxy [1], not a perfect solution but for apps deployed inside the company domain it does the trick. > dependences. Creating pom descriptors for each block would also be > helpfull. pom descriptors are being created for every block yes. Regards Jorg [1] http://maven-proxy.codehaus.org/
cocoon maven repository
Hi Dev Team I'm currently working on a project that does bundle the cform and portal block + core classes and is being build by maven1. This works quite well, the only problem is that some of cocoons dependencies cannot be found in the well known public repositories, mostly snapshot/dated jars such as rhino. Now I noticed that you guys are porting the whole cocoon project to maven2. How are you managing dependencies? It would be great if you could support maven1 as well by providing a remote repo with the dependences. Creating pom descriptors for each block would also be helpfull. Regards, Stefan
Re: [vote] Arje Cahn as a new Cocoon committer
Sylvain Wallez wrote: I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. +1 Guido
Re: [vote] Arje Cahn as a new Cocoon committer
On Thu, 8 Sep 2005, Sylvain Wallez wrote: I'd like to be the voice of a general opinion among Cocoon developers that Arjé Cahn should be made a Cocoon committer. Please cast your votes! +1 Giacomo
Re: Tree view?
Ralph Goers wrote: Does CForms provide any way of generating a tree view? I was looking at http://www.tonymarston.net/xml-xsl/xml-and-xsl-treeview.html and would like to do something similar, but I'd like to use CForms to do it. I would also like to not have to collect all the data for the whole tree, but only collect data when a node is expanded. That's exactly the purpose of the Tree widget that was added in trunk some time ago [1]. It has a lightweight tree model that loads data on demand. I will port this widget to 2.1 very soon. Sylvain http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111894513815242&w=2 -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: howto update the website using forrest (was Re: patch commit request)
Le 10 sept. 05, à 01:06, Jorg Heymans a écrit : ...The updated livesites page is now on minotaur. It is not visible to the outside world yet, there's probably a cache in between waiting to expire... Websites are replicated from there to the machine that serves the public sites, every few hours. That's the why changes don't appear immediately. -Bertrand smime.p7s Description: S/MIME cryptographic signature
