Re: [Vote] Release 2.1.10
Joerg Heinicke wrote: Those tests do not involve any sitemap processing, so JXTemplateGenerator is not involved. It's more likely that the upgrade of the XML libs [1] caused this not quite unwanted side effects (removing a marked DIRTY HACK). But this commit was on 27th of November. If the tests were really successful last week, I don't know what caused this failure now. Your recent changes fixed these problems for me, thanks! - so our test cases were buggy and I think this is not a showstopper for the release. But for me now org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase fails in testExecuteRunnablelonglong: This one fails for me from time to time; invoking the test again runs successfully... Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Carsten Ziegeler escribió: I am not so firm in ASF rules. Does the one who called the vote have the right to withdraw the motion? Or does somebody else want to call a vote to undo this vote? I think you can just withdraw the vote (if you would have a vote to undo a vote, someone could vote there -1 ... would be funny somehow) I already voted -1. :) The remaining question is, if we want to keep the notice in the status.xml for 2.1.10? I don't think it is a good idea to keep the notice there. It makes a precedent that cocoon breaks user contracts and open the door for future user contract breaks. It is not good for the project reputation. We worked and cared to keep the java 1.3 compatibilty *only* because we (as project) told that. Best Regards, Antonio Gallardo.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Vadim Gritsenko escribió: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. +1 Best Regards, Antonio Gallardo.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Hi Alfred, Alfred Nathaniel escribió: On Mon, 2006-12-18 at 16:24 +0100, Reinhard Poetz wrote: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. I agree. I agree, too. The last thing I want is to hold up the 2.1.10. If I had known what I stirred up here, I would not have started it. I apologize for the short time for discusion and vote but the idea was to get it into 2.1.10. Otherwise it will stay forever. Don't worry. Everything is ok. I think Vadim solution is great is the best scape pod we can get. :) Quoting: get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. Also given the current status, I am wondering if we should reconsider java 1.4 as the minimum for cocoon 2.2. We should keep in mind java 1.6 is out, hence if we agree to have java 1.4 as minimum we will have to support it for the next 2 years or so (based on the current release time). Thinking in 2 years for now. I wonder who will still be using java 1.4 and hence we will met the same issue as today, isn't? Best Regards, Antonio Gallardo. Personally I think trunk is still too immature and unapproachable that there must a way open for 2.1.11+ release. I have nothing against staying JDK1.3 compatible, only I doubt that is is still useful. I think it is simply a non-issue, and we are making life unnecessarily hard for ourselves. Hands up, who has still a working 1.3 JVM on his computer to support it? If we weren't nailed down with trunk == 2.2, it would be sensible to save face by calling the 2.1.1 already 2.2. But that is too late now... I am not so firm in ASF rules. Does the one who called the vote have the right to withdraw the motion? Or does somebody else want to call a vote to undo this vote? Cheers, Alfred.
Re: [2.2] Duplicate (and different) versions of batik on classpath
I removed the dependency on batik-1.5-fop, thanks for spotting the problem. I haven't done much testing yet, please report if there are any problems. /Daniel Bart Molenkamp skrev: Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
Re: Cocoon 2.2 - Use a block for the root sitemap
Reinhard Poetz wrote: Reinhard Poetz wrote: Patrick Refondini wrote: Daniel Fagerstrom wrote: The root servlet should be mounted at not /. Alexander had the same problem. So even if I find the current behavior intuitive, no one else seem to agree ;). So we should probably have special handling of / as you suggest. I just tested configuration and it does exactly what I was looking for, uh ! Although having special handling of /, if found acceptable in term of coding, could be valuable for dummy users like I :O) or those who won't read the docs. Talking about documentation, would this: http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1291.html be the place where the block protocol and configurations like these could be best described ? The block documentation should go to http://cocoon.zones.apache.org/daisy/cdocs-core/g5/1266.html or to one of its siblings in the menu tree. The document that you refered to should contain a short recipie how to add another block to an existing block and continues where Your first Cocoon application (http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html) and Your first Cocoon pipeline (http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1290.html) end. Thank you for clarifications. I need more block usage knowledge before pretending to produce any useful documentation, but this comes together with understanding the existing documentation structure. Best Regards, Patrick
Re: [Vote] Release 2.1.10
IMPORTANT: I reassembled the release as I included recent changes: a) Added the fixes for the failing junit tests in cforms b) Added the patch for a failing xsp soap sample c) Removed the remark about jdk 1.3 So, you can download the new version from http://people.apache.org/~cziegeler/cocoon/ The corresponding sources are under: https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/ Everything else stays the same! Which means *if* the vote passes, I will release on thursday. All votes so far are invalid (there was only one from me anyway)! So please cast your votes Carsten Carsten Ziegeler wrote: Please cast your votes on the 2.1.10 release. The release candidate can be downloaded from: http://people.apache.org/~cziegeler/cocoon/ The corresponding sources are under: https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/ The vote will be open for 72 hours. If the vote passes, I will rename the tag to RELEASE_2_1_10, rename the downloadable archives, sign them etc. and put them up for download. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[result] [vote] Releasing org.apache.cocoon:cocoon:2
Reinhard Poetz wrote:
As recently discussed
(http://marc.theaimsgroup.com/?t=11659205261r=1w=2), I rebuilt
org.apache.cocoon:cocoon:2, our root POM again. Compared to the first
artifact, that we voted on, I changed the tagBase to
https://svn.apache.org/repos/asf/cocoon/tags/${project.artifactId}. This
should help that the tags directory remains useable.
I redid the release of it because otherwise we would have to release all
the POM artifacts again, which is very time-consuming and should be
avoided.
The artifact can be found at
http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon/2/.
Please cast your votes!
The vote was accepted by 3 binding +1 votes. I'm going to copy all the
artifacts, that we voted on recently, to the m2-ibiblio-sync directory.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
RE: [2.2] Duplicate (and different) versions of batik on classpath
It seems to work. Thanks for that. However, I think I found another problem related to Eclipse. Batik has a dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to rhino:js:1.6R5. When I build my block, or when I build from the root pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath). This is correct. But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to the classpath. That is wrong, IMO. It should add the dependency to rhino:js:1.6R5 (transitively trough cocoon-core's dependencies). You can see it for yourself by creating all the eclipse descriptors for trunk, and then opening the block cocoon-batik-impl (you'll see the wrong version of rhino:js on the classpath). Is this a known problem, or better, does anybody know how to solve this? Thanks, Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 19 december 2006 9:51 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on classpath I removed the dependency on batik-1.5-fop, thanks for spotting the problem. I haven't done much testing yet, please report if there are any problems. /Daniel Bart Molenkamp skrev: Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
Re: [2.2] Duplicate (and different) versions of batik on classpath
Bart Molenkamp wrote:
It seems to work. Thanks for that.
However, I think I found another problem related to Eclipse. Batik has a
dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to
rhino:js:1.6R5. When I build my block, or when I build from the root
pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath).
This is correct.
But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to
the classpath. That is wrong, IMO. It should add the dependency to
rhino:js:1.6R5 (transitively trough cocoon-core's dependencies).
You can see it for yourself by creating all the eclipse descriptors for
trunk, and then opening the block cocoon-batik-impl (you'll see the
wrong version of rhino:js on the classpath). Is this a known problem, or
better, does anybody know how to solve this?
Try to exclude the dependeny on rhino:js:1.5R4.1 from the batik library and add
explicitly add the dependency on rhino:js:1.6R5. I haven't tried it myself but I
guess it could work.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Releasing to http://www.apache.org/dist/cocoon
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have
to make the files available at http://www.apache.org/dist/cocoon/
too.
I'd say the jar files (cocoon-core, cocoon-template-impl,
cocoon-flowscript-impl, cocoon-blocks-fw-impl) only. The pom
artifacts and the archetypes are pretty useless without Maven so I
don't think it makes much sense to put them there.
What's the point of uploading jars to mirrors if nothing usefule can
be done with it?
Right, a Maven 2 user wouldn't need them but for those that use an
alternative build tool, it is the default place where Apache projects
put there released artifacts and where people look for them.
Also, reading http://www.apache.org/dev/release.html, I understand that
we have to put our releases there, haven't we?
It should at least be accompanied with a webapp archive.
would be great
And source code archives.
right, forgot about the source artifacts.
As Vadim pointed out, the value of publishing all the released artifacts to
http://www.apache.org/dist/cocoon isn't high as the usage without Maven requires
some understanding of how Cocoon 2.2 works. As there aren't any guides
available, the barrier for somebody who is unfamiliar will be too high.
On the other hand I want to work on the guide and
http://www.apache.org/dist/cocoon is the official location for all Apache releases.
Therefore I would like to see the artifacts being signed and also released from
http://www.apache.org/dist/cocoon.
Opinions?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Releases from trunk
Reinhard Poetz wrote:
I think it's time to release the next milestone of some of our modules:
- org.apache.cocoon:cocoon(pom)
- org.apache.cocoon:cocoon-core-modules (pom)
- org.apache.cocoon:cocoon-core (jar)
- org.apache.cocoon:cocoon-blocks-modules (pom)
- org.apache.cocoon:cocoon-template (pom)
- org.apache.cocoon:cocoon-flowscript (pom)
- org.apache.cocoon:cocoon-template-impl (jar)
- org.apache.cocoon:cocoon-flowscript-impl(jar)
- org.apache.cocoon:cocoon-blocks-fw (pom)
- org.apache.cocoon:cocoon-blocks-fw-impl (jar)
- org.apache.cocoon:cocoon-tools-modules (pom)
- org.apache.cocoon:cocoon-archetypes (pom)
- org.apache.cocoon:cocoon-22-archetype-block (archetype jar)
I copied the artifacts to the m2-ibibio-sync directory on people.apache.org. If
the automatic synchronization works correctly, the new artifacts should be
available from the central Maven repository (repo1.maven.org) very soon.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
RE: [2.2] Duplicate (and different) versions of batik on classpath
Ok, I found http://jira.codehaus.org/browse/MECLIPSE-122. Seems to be fixed, but not yet released... (looking at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plu gin/ Bart. -Oorspronkelijk bericht- Van: Bart Molenkamp Verzonden: dinsdag 19 december 2006 11:19 Aan: dev@cocoon.apache.org Onderwerp: RE: [2.2] Duplicate (and different) versions of batik on classpath It seems to work. Thanks for that. However, I think I found another problem related to Eclipse. Batik has a dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to rhino:js:1.6R5. When I build my block, or when I build from the root pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath). This is correct. But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to the classpath. That is wrong, IMO. It should add the dependency to rhino:js:1.6R5 (transitively trough cocoon-core's dependencies). You can see it for yourself by creating all the eclipse descriptors for trunk, and then opening the block cocoon-batik-impl (you'll see the wrong version of rhino:js on the classpath). Is this a known problem, or better, does anybody know how to solve this? Thanks, Bart. -Oorspronkelijk bericht- Van: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 19 december 2006 9:51 Aan: dev@cocoon.apache.org Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on classpath I removed the dependency on batik-1.5-fop, thanks for spotting the problem. I haven't done much testing yet, please report if there are any problems. /Daniel Bart Molenkamp skrev: Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Antonio Gallardo wrote: Vadim Gritsenko escribió: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. Well looking at the release cycle of the last 2 versions ,which was 2.1.9 in april 2006 and 2.1.8 in november 2005, I guess another five-eight months to get 2.2 out should be feasable. So it makes sence that we should stop the 2.1.x branch and move on to 2.2. So here is my (non-binding) +1. Kind regards, Jeroen Reijn
Re: [Vote] Release 2.1.10
On 12/19/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...IMPORTANT: I reassembled the release as I included recent changes... Sorry to rain on this party again, but Junit tests in your release candidates fail on non-Windows systems, due to debugging statements which try to create files like d:/enum.xml. I have committed fixes, all junit tests pass on my macosx system now. Five of the htmlunit tests fail here, I won't have time to investigate ATM. If you redo the distribution files, could you post the new md5 digests here to avoid any confusion? -Bertrand
Re: [Vote] Release 2.1.10
Bertrand Delacretaz wrote: On 12/19/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...IMPORTANT: I reassembled the release as I included recent changes... Sorry to rain on this party again, but Junit tests in your release candidates fail on non-Windows systems, due to debugging statements which try to create files like d:/enum.xml. As I have the right os they worked for me :) Anyway, thanks for finding this! I have committed fixes, all junit tests pass on my macosx system now. Five of the htmlunit tests fail here, I won't have time to investigate ATM. If you redo the distribution files, could you post the new md5 digests here to avoid any confusion? Yepp, I just did the 3rd attempt which will be the final one; if we find anything else I will reschedule the release for the end of the year and start from scratch. So here are the md5's: MD5 (cocoon-2.1.10rc-src.zip) = 3dfee1d2d8b5f3e761eb763809249073 MD5 (cocoon-2.1.10rc-src.tar.gz) = d073b36274ab359b59bbb760e083a934 Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Release 2.1.10
Bertrand Delacretaz bdelacretaz at apache.org writes: Sorry to rain on this party again, but Junit tests in your release candidates fail on non-Windows systems, due to debugging statements which try to create files like d:/enum.xml. Oh, sorry for this. Needed this for comparing the files. Carsten should probably clean up his D: drive as well. If i could execute the tests in Eclipse, I would not need those debug statements :-/ After fixing the classpath by adding test-resources dir for *.xtest files, I got NPEs somewhere in Xalan. Remote debugging the test (ant target 'junit-test-debug' or so) did neither work due to ClassNotFoundException. It probably only works with core tests. Regards Jörg
Re: [Vote] Release 2.1.10
+1 Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: [2.2] Duplicate (and different) versions of batik on classpath
Yes, that works! Thanks!
Bart.
-Oorspronkelijk bericht-
Van: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Verzonden: dinsdag 19 december 2006 11:26
Aan: dev@cocoon.apache.org
Onderwerp: Re: [2.2] Duplicate (and different) versions of batik on
classpath
Bart Molenkamp wrote:
It seems to work. Thanks for that.
However, I think I found another problem related to Eclipse. Batik has a
dependency to rhino:js:1.5R4.1, but cocoon-core has a dependency to
rhino:js:1.6R5. When I build my block, or when I build from the root
pom, Maven builds against 1.6R5 (it removes 1.5R4.1 from the classpath).
This is correct.
But when I build the Eclipse descriptors, it adds rhino:js:1.5R4.1 to
the classpath. That is wrong, IMO. It should add the dependency to
rhino:js:1.6R5 (transitively trough cocoon-core's dependencies).
You can see it for yourself by creating all the eclipse descriptors for
trunk, and then opening the block cocoon-batik-impl (you'll see the
wrong version of rhino:js on the classpath). Is this a known problem, or
better, does anybody know how to solve this?
Try to exclude the dependeny on rhino:js:1.5R4.1 from the batik library
and add
explicitly add the dependency on rhino:js:1.6R5. I haven't tried it myself
but I
guess it could work.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail:
http://mail.yahoo.de
Re: [Vote] Release 2.1.10
On 12/19/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...So here are the md5's: MD5 (cocoon-2.1.10rc-src.zip) = 3dfee1d2d8b5f3e761eb763809249073 MD5 (cocoon-2.1.10rc-src.tar.gz) = d073b36274ab359b59bbb760e083a934... Thanks Carsten, and thanks Joerg for the bugfixing. +1 on the release. On my macosx/JDK1.5, all junit tests pass, and one of the htmlunit tests fails: RedirectTestCase, testSendStatus fails, NPE in IOUtils.copy, looks like a a defect in the test code, not a release blocker IMO. -Bertrand
Re: [Vote] Release 2.1.10
My +1 too. Many thanks guys. regards Jeremy On 19 Dec 2006, at 12:46, Bertrand Delacretaz wrote: Thanks Carsten, and thanks Joerg for the bugfixing. +1 on the release. smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Release 2.1.10
Here is my (non-binding) +1 :-) Kind regards, Jeroen Reijn Jeremy Quinn wrote: My +1 too. Many thanks guys. regards Jeremy On 19 Dec 2006, at 12:46, Bertrand Delacretaz wrote: Thanks Carsten, and thanks Joerg for the bugfixing. +1 on the release.
Re: [Vote] Release 2.1.10
On 12/19/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: IMPORTANT: I reassembled the release as I included recent changes: a) Added the fixes for the failing junit tests in cforms b) Added the patch for a failing xsp soap sample c) Removed the remark about jdk 1.3 So, you can download the new version from http://people.apache.org/~cziegeler/cocoon/ The corresponding sources are under: https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/ Everything else stays the same! Which means *if* the vote passes, I will release on thursday. All votes so far are invalid (there was only one from me anyway)! +1 !!! -- Peter Hunsberger
[jira] Created: (COCOON-1972) [Link] NameOfMyCocoonSite
[Link] NameOfMyCocoonSite - Key: COCOON-1972 URL: http://issues.apache.org/jira/browse/COCOON-1972 Project: Cocoon Issue Type: Wish Components: - Documentation Reporter: Marc Bigler As described here http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed we would like to apply to get our Cocoon website listed on your live sites page http://cocoon.apache.org/link/livesites-2.1.html I didn't find the Cocoon product anymore in Bugzilla so I inserted here in Jira as a wish, I hope this is fine too. Else please instruct me the new procedure to get our website listed. Many thanks in advance. Here are the questions answered as required: URL of the website: www.nmf.ch Title of the website: New Media Factory GmbH Cocoon version used: 2.1.7 Short summary: The New Media Factory GmbH is an agency for new media, multimedia, e-commerce, CMS, web design, internet programming, search machine optimization and marketing located in Basel, Switzerland. Its range of services offered covers everything in the new media branch. How can we verify this site is actually built with Cocoon? Just use a URL that doesn't exist in the /xml/ directory, for example: http://www.nmf.ch/xml/non_existing_page - If you have already provided the same/a similar link for the LiveSites pages, No, that's the first time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1972) [www.nmf.ch] New Media Factory GmbH
[ http://issues.apache.org/jira/browse/COCOON-1972?page=all ] Marc Bigler updated COCOON-1972: Summary: [www.nmf.ch] New Media Factory GmbH (was: [Link] NameOfMyCocoonSite) [www.nmf.ch] New Media Factory GmbH --- Key: COCOON-1972 URL: http://issues.apache.org/jira/browse/COCOON-1972 Project: Cocoon Issue Type: Wish Components: - Documentation Reporter: Marc Bigler As described here http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed we would like to apply to get our Cocoon website listed on your live sites page http://cocoon.apache.org/link/livesites-2.1.html I didn't find the Cocoon product anymore in Bugzilla so I inserted here in Jira as a wish, I hope this is fine too. Else please instruct me the new procedure to get our website listed. Many thanks in advance. Here are the questions answered as required: URL of the website: www.nmf.ch Title of the website: New Media Factory GmbH Cocoon version used: 2.1.7 Short summary: The New Media Factory GmbH is an agency for new media, multimedia, e-commerce, CMS, web design, internet programming, search machine optimization and marketing located in Basel, Switzerland. Its range of services offered covers everything in the new media branch. How can we verify this site is actually built with Cocoon? Just use a URL that doesn't exist in the /xml/ directory, for example: http://www.nmf.ch/xml/non_existing_page - If you have already provided the same/a similar link for the LiveSites pages, No, that's the first time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1972) [Link] New Media Factory GmbH
[ http://issues.apache.org/jira/browse/COCOON-1972?page=all ] Marc Bigler updated COCOON-1972: Summary: [Link] New Media Factory GmbH (was: [www.nmf.ch] New Media Factory GmbH) [Link] New Media Factory GmbH - Key: COCOON-1972 URL: http://issues.apache.org/jira/browse/COCOON-1972 Project: Cocoon Issue Type: Wish Components: - Documentation Reporter: Marc Bigler As described here http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed we would like to apply to get our Cocoon website listed on your live sites page http://cocoon.apache.org/link/livesites-2.1.html I didn't find the Cocoon product anymore in Bugzilla so I inserted here in Jira as a wish, I hope this is fine too. Else please instruct me the new procedure to get our website listed. Many thanks in advance. Here are the questions answered as required: URL of the website: www.nmf.ch Title of the website: New Media Factory GmbH Cocoon version used: 2.1.7 Short summary: The New Media Factory GmbH is an agency for new media, multimedia, e-commerce, CMS, web design, internet programming, search machine optimization and marketing located in Basel, Switzerland. Its range of services offered covers everything in the new media branch. How can we verify this site is actually built with Cocoon? Just use a URL that doesn't exist in the /xml/ directory, for example: http://www.nmf.ch/xml/non_existing_page - If you have already provided the same/a similar link for the LiveSites pages, No, that's the first time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote] Release 2.1.10
On 18.12.2006 09:39, Carsten Ziegeler wrote: Please cast your votes on the 2.1.10 release. +1 Jörg
[continuum] BUILD SUCCESSFUL: Pipeline API
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/51/buildId/1143 Build statistics: State: Ok Previous Build: No previous build. Started at: Tue, 19 Dec 2006 19:33:50 + Finished at: Tue, 19 Dec 2006 19:34:03 + Total time: 13s Build Trigger: Forced Exit code: 0 Building machine hostname: cocoon.zones.apache.org Operating system : SunOS(unknown) Java version : 1.4.2_06(Sun Microsystems Inc.) Changes No files changed Output: [INFO] Scanning for projects... [INFO] [INFO] Building Pipeline API [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 25 source files to /home/maven/continuum-data/working-directory/51/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: /home/maven/continuum-data/working-directory/51/target/cocoon-pipeline-api-1.0.0-SNAPSHOT.jar [INFO] [install:install] [INFO] Installing /home/maven/continuum-data/working-directory/51/target/cocoon-pipeline-api-1.0.0-SNAPSHOT.jar to /home/maven/.m2/repository/org/apache/cocoon/cocoon-pipeline-api/1.0.0-SNAPSHOT/cocoon-pipeline-api-1.0.0-SNAPSHOT.jar [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Tue Dec 19 19:34:03 GMT 2006 [INFO] Final Memory: 6M/12M [INFO]
[help-needed] Documentation
After releasing cocoon-core-m2, I have continued to work on the documentation
again. As a first step I have started with the main site
(http://cocoon.zones.apache.org/daisy/cdocs-site-main/ or
http://cocoon.zones.apache.org/dev-docs/), which will be published at
http://cocoon.apache.org.
I created a new homepage (honestly, I have never visited the RoR website ;-))
and a new navigation structure. Most of the documents are still empty. It would
be of great help if you could work on following tasks:
o short description What is Apache Cocoon?
The former description doesn't fit to Cocoon 2.2
o short descripton What are Cocoon blocks?
o fill the empty documents presentations, books, articles
o write How to contribute?
o update History
o write Your first XML pipeline (continue the Your first Cocoon
application using Maven 2 introduction)
Thanks in advance!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [Vote] Release 2.1.10
+1 Cheers, Alfred.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tue, 2006-12-19 at 02:50 -0600, Antonio Gallardo wrote: Also given the current status, I am wondering if we should reconsider java 1.4 as the minimum for cocoon 2.2. We should keep in mind java 1.6 is out, hence if we agree to have java 1.4 as minimum we will have to support it for the next 2 years or so (based on the current release time). Thinking in 2 years for now. I wonder who will still be using java 1.4 and hence we will met the same issue as today, isn't? AT may day job we recently switched to Java5, and I started to convert the code base. Generics are useful to better understand code which makes extensive use of Lists and Maps, and the new for-loop I find really neat. But it is only syntactic sugar. I don't see a killer feature to justify giving up just yet compatibility to 1.4, which is still the production JVM version for many enterprises (including the one I work for). In order to avoid the same squeeze we are in atm for 2.1/1.3 we should call *the next big thing* Cocoon 3.0. Then we can close 2.2 and start 2.3 with 1.5 as minimum JVM whenever it makes sense. Cheers, Alfred. PS congrats for you little boy.
Re: [Vote] Release 2.1.10
Carsten Ziegeler wrote: So here are the md5's: MD5 (cocoon-2.1.10rc-src.tar.gz) = d073b36274ab359b59bbb760e083a934 -0 ... meaning that i don't want to stop the release, however i am concerned that we are not following the new licensing which all releases after early November are asked to follow. A while ago i said that although i had done all the work to replace the license headers in the source files, there is still the task of adding whatever third-party attributions into the NOTICE.txt and declaring the licenses in LICENSE.txt -David
