Maven 2 transient dependency tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all Is anybody aware of a tool/plugin/option to show the hole dependency graph of a Maven 2 project? - -- 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.3 (GNU/Linux) iD8DBQFEbWBhLNdJvZjjVZARAu6NAKCR7mk2VKNQCZM+bPrn05Zk4HNJFwCg029J AXg1SKeOAhujxtYeEAx60Ig= =z7Ko -END PGP SIGNATURE-
Re: How long for a full trunk build
Giacomo Pati wrote: mvn -Dmaven.test.skip=true clean install To improve the build I usually build offline to prevent m2 from all these snapshot checkings, so adding -o to the command helps a lot. Of course if dependencies change an offline build doesn't work. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Maven 2 transient dependency tree
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all Is anybody aware of a tool/plugin/option to show the hole dependency graph of a Maven 2 project? http://mojo.codehaus.org/pomtools-maven-plugin/console-mojo.html not working for me right now though (the webpage, not the plugin :)) -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 09:18:26 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Classloading Reinhard already started the discussion on readding per sitemap classloading which I think is a good idea. I'll try to add the code over the weekend again. But I think we should go one step further: Let's always use the paranoid class loader for the whole webapp. I started a discussion about this a long time ago and I think noone disagreed at that time (haven't searched in the archives). I hope this is still the case. Now, my idea is to solve all class path related problems (xml apis, rhino, commons-logging) with this. I suggest that we: a) move the paranoid class loader code (3 classes without additional dependencies) to the core-webapp block. It doesn't make sense to make this code an own block. b) Configure this as the default (I already did this and it worked on my machine - as it didn't work on Reinhards he commented it out. We have to find out what went wrong). c) Change the deployer tool to *not* put all jars in WEB-INF/lib and classes in WEB-INF/classes. I think we should only put the paranoid servlet and classloader class into WEB-INF/lib and everything else goes into a different directory to hide these classes from the usual application container classpath. It doesn't make sense to add all these jars to the webapp classpath although they are not used at all. So we put them into an own directory, let's they WEB-INF/cocoon-lib and the paranoid class loader loads everything from there. How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? At the first glance it doesn't seem so easy to me - -- 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.3 (GNU/Linux) iD8DBQFEbXTPLNdJvZjjVZARAikiAJ90sMJ3HlV038W1nHHqhF64jVnXSACgpbvs C3MIBJcLWkEvALEh/DXsBRE= =Wkfg -END PGP SIGNATURE-
Re: Maven 2 transient dependency tree
Hi all Is anybody aware of a tool/plugin/option to show the hole dependency graph of a Maven 2 project? I think Carlos played with it http://jroller.com/page/carlossg/20060223 and I think the plugin is somewhere on codehause. Have a search on maven user/dev. I think someone brought that up lately. cheers -- Torsten
Re: [2.2] Classloading
Giacomo Pati wrote: How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. At the first glance it doesn't seem so easy to me Yes, you're right. Now I see two solutions (perhaps there are more?): a) We forget about the paranoid class loading completly as this causes too much problems with other servlets or filters defined in the webapp. This would require to rely on the application server when it comes to class loading. b) We require that every servlet and filter use our paranoid class loader. We could achieve this by wrapping our ParanoidServlet and our ParanoidFilter class around the real servlet/filter in the web.xml. So all you have to do is a little bit more configuration in web.xml. Instead of directly configuring your servlet/filter you configure the wrapper and give your class as a parameter. Together with the deployer tool everything else should be transparent. I would try to go for b) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CocoonTask
Upayavira wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: I was going through the list of dependencies because I was wondering why we have Ant artifacts in our web applications. I found the cause which is the CocoonTask and the question is, what we want to do with it. As IMO it shouldn't be part of a Cocoon core, I see two options: - create a cocoon-ant module - remove it BTW, is it supposed to work with Cocoon 2.2 at all? I guess it's currently not working anyway. Personally I see no real need in a cocoon ant task, so I would vote for removing it. There is forrest anyway. It likely isn't working, and would need the same attention as the CLI. I don't agree with the 'there is forrest' argument, as Forrest should be using the Ant task rather than calling the CLI. We have an old issue: http://issues.apache.org/jira/browse/FOR-102 One day soon we should investigate. So please leave it available. -David The Cocoon Ant task is really a better way of using the CLI. So by saying there's no need for the Ant task, you're effectively also saying there's no need for the CLI either. (Now that may well be true, wget and all, but that's a different discussion). However, moving it into a separate module makes sense, as both CLI and Ant are definitely not the main use-cases for Cocoon. In the end, if no-one is prepared to update it, then it would be better removed. And I'm not going to be in a position to update it myself. Regards, Upayavira
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 09:46:10 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Classloading Giacomo Pati wrote: How does this work if one has added ServletFilters or a top level Spring applicationContext? Does he has to take care of it's own to deploy the necessary jars at the right place? Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. Not sure we can (Reinhard?) At the first glance it doesn't seem so easy to me Yes, you're right. Now I see two solutions (perhaps there are more?): a) We forget about the paranoid class loading completly as this causes too much problems with other servlets or filters defined in the webapp. This would require to rely on the application server when it comes to class loading. b) We require that every servlet and filter use our paranoid class loader. We could achieve this by wrapping our ParanoidServlet and our ParanoidFilter class around the real servlet/filter in the web.xml. So all you have to do is a little bit more configuration in web.xml. Instead of directly configuring your servlet/filter you configure the wrapper and give your class as a parameter. Together with the deployer tool everything else should be transparent. I would try to go for b) b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.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.3 (GNU/Linux) iD8DBQFEbXx4LNdJvZjjVZARAm06AKDy+im44BQGReqTkvb3/95zI9iv0ACg5HeF 5lEmkhjGegX+9cVFHRzesJI= =T6+R -END PGP SIGNATURE-
[2.2] Error building trunk
After the recent changes to our poms, I get the following error: It seems that we are now using the wrong xml-apis version for compilation. Carsten Downloading: http://mirrors.sunsite.dk/maven2/xerces/xercesImpl/2.8.0/xercesImpl -2.8.0.pom 1K downloaded Downloading: http://mirrors.sunsite.dk/maven2/xml-apis/xml-apis/1.3.03/xml-apis- 1.3.03.pom [WARNING] Unable to get resource from repository central (http://ibiblio.org/mav en2) Downloading: http://svn.apache.org/maven-snapshot-repository/xml-apis/xml-apis/1 .3.03/xml-apis-1.3.03.pom [WARNING] Unable to get resource from repository apache.snapshot (http://svn.apa che.org/maven-snapshot-repository) Downloading: http://svn.apache.org/repository/xml-apis/poms/xml-apis-1.3.03.pom [WARNING] Unable to get resource from repository apache-cvs (http://svn.apache.o rg/repository) Downloading: http://mirrors.sunsite.dk/maven2/xerces/xercesImpl/2.8.0/xercesImpl -2.8.0.jar 1178K downloaded [INFO] [compiler:compile] Compiling 651 source files to D:\dev\workspace\cocoon-2.2\core\cocoon-core\targe t\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[26,19] cannot resolve symbol symbol : class DOMConfiguration location: package dom D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[39,19] cannot resolve symbol symbol : class UserDataHandler location: package dom D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[913,11] cannot resolve symbol symbol : class DOMConfiguration location: class org.apache.cocoon.xml.dom.DocumentWrapper D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[1011,56] cannot resolve symbol symbol : class UserDataHandler location: class org.apache.cocoon.xml.dom.DocumentWrapper -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Error building trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 10:12:32 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Error building trunk After the recent changes to our poms, I get the following error: I've changed one to sync them to xercesImpl-2.8.0 (which another pom.xml was changed by someone to that version). But my trunk compiles without problems. It seems that we are now using the wrong xml-apis version for compilation. There is 2.0.2 available on ibiblio but I dunno whether this is needed (a change from 1.X to 2.X on an api jar makes me think about compatability problems). Giacomo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEbYGXLNdJvZjjVZARAkgBAJ4zuGyaAI4kcWHHYTxY3ssg+IXZ4QCg0SZF RgBgQkSO937dzVPEzvPGeno= =MR7y -END PGP SIGNATURE-
Re: [2.2] Classloading
Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 10:37:01 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Classloading Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? The web.xml in 2.2 is in the responsability of the developer (it was not so in 2.1 where you've build from the source and had to patch it to have a reproducable and automated build). And because of that I'd say go for b) :-) - -- 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.3 (GNU/Linux) iD8DBQFEbYT3LNdJvZjjVZARAsSdAKDw8t2VdUc88ZR57EHTqwRka3SQ7wCgx6vi G1rwpVZC7w6bHWWfsY7fPjQ= =hzTs -END PGP SIGNATURE-
Re: CocoonTask
Carsten Ziegeler wrote: Upayavira wrote: Do note that the CocoonTask is nothing but a wrapper around the CocoonBean, much as is the CLI (org.apache.cocoon.Main). Were you to get the CocoonBean working without changing its interfaces, the CocoonTask would start working again. Once someone has worked out the CLI, the ant task should be pretty simple. There was an older Ant task in the scratchpad that was a rewrite of the CLI - but I think/hope that was deleted long ago. No, it's still there. Can we delete it? IMO yes. I doubt it works anyway. Upayavira
Re: [2.2] Classloading
Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. /Daniel
Re: [2.2] Classloading
Daniel Fagerstrom wrote: Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. There are several problems, for example Rhino, Xerces and Xalan which usually are already in the classpath of the app server. Now, Cocoon requires specific versions of these jars and if the app server comes with different (possibly incompatible) versions, then you have problems. And updating the jars of the app server is a no-go. And the paranoid class loader is the only solution which works reliable. Other problems occur with logging when for example the app server uses the same logging frameworks but with a different configuration. Now, you *can* use Cocoon without the paranoid class loader, but I would like to make it the default and common practice. If you don't need this for your own app, you can change it and simply not configure the wrappers. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Carsten Ziegeler skrev: Giacomo Pati wrote: b) might work, but since you want it to be the default ClassLoader I expect problems users forgot about wrapping their stuff in web.xml. Yes, that's true - but apart from that what do you think about the idea? As, we want to make Cocoon less monolithic and easier to use together with other web frameworks, it seem like a step in the wrong direction to require all servlets and filters to be wrapped and use non-standard classloading. I don't remember what classloading problems we have, could you give some background or a link to the previous discussion you referred to, so that I can create a more informed opinion about the issue. There are several problems, for example Rhino, Xerces and Xalan which usually are already in the classpath of the app server. Now, Cocoon requires specific versions of these jars and if the app server comes with different (possibly incompatible) versions, then you have problems. And updating the jars of the app server is a no-go. And the paranoid class loader is the only solution which works reliable. Other problems occur with logging when for example the app server uses the same logging frameworks but with a different configuration. Now, you *can* use Cocoon without the paranoid class loader, but I would like to make it the default and common practice. If you don't need this for your own app, you can change it and simply not configure the wrappers. Seem reasonable. Then I don't have any problem with having the paranoid classloader as default. /Daniel
Re: [2.2] Error building trunk
Carsten Ziegeler wrote:
After the recent changes to our poms, I get the following error:
It seems that we are now using the wrong xml-apis version for compilation.
sorry, was my fault. I forgot to checkin some changes. The problem is that
Xerces 2.8.0 has a transitive dependency on xml-apis 1.3.03.
I'm not a DOM specialist, but could somebody upgrade the three or four classes
that have problems with 1.3.03 so that they work together?
--
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] Error building trunk
Giacomo Pati escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 10:12:32 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Error building trunk After the recent changes to our poms, I get the following error: I've changed one to sync them to xercesImpl-2.8.0 (which another pom.xml was changed by someone to that version). But my trunk compiles without problems. It seems that we are now using the wrong xml-apis version for compilation. There is 2.0.2 available on ibiblio but I dunno whether this is needed (a change from 1.X to 2.X on an api jar makes me think about compatability problems). In xml-apis, there was a versioning problem and for this reasons 2.0.2 is older than 1.3.03. 2.0.2 does not contain DOM 3. xml-apis 1.3.03 contains DOM 3 and is the latest version. Best Regards, Antonio Gallardo.
Re: [2.2] Error building trunk
Reinhard Poetz wrote: Carsten Ziegeler wrote: After the recent changes to our poms, I get the following error: It seems that we are now using the wrong xml-apis version for compilation. sorry, was my fault. I forgot to checkin some changes. The problem is that Xerces 2.8.0 has a transitive dependency on xml-apis 1.3.03. I'm not a DOM specialist, but could somebody upgrade the three or four classes that have problems with 1.3.03 so that they work together? The problem is that the version used by Xerces only supports Dom-level 2 while we support DOM level 3 in some classes. I think we can just keep our own dependency to xml-apis and are done. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Error building trunk
Hi Carsten: Seems like by error xml-apis jar in the ibiblio maven2 repository was stored as a maven 1 artifact: http://ibiblio.org/maven2/xml-apis/xml-apis/1.3.03/ Best Regards, Antonio Gallardo. Carsten Ziegeler escribió: After the recent changes to our poms, I get the following error: It seems that we are now using the wrong xml-apis version for compilation. Carsten Downloading: http://mirrors.sunsite.dk/maven2/xerces/xercesImpl/2.8.0/xercesImpl -2.8.0.pom 1K downloaded Downloading: http://mirrors.sunsite.dk/maven2/xml-apis/xml-apis/1.3.03/xml-apis- 1.3.03.pom [WARNING] Unable to get resource from repository central (http://ibiblio.org/mav en2) Downloading: http://svn.apache.org/maven-snapshot-repository/xml-apis/xml-apis/1 .3.03/xml-apis-1.3.03.pom [WARNING] Unable to get resource from repository apache.snapshot (http://svn.apa che.org/maven-snapshot-repository) Downloading: http://svn.apache.org/repository/xml-apis/poms/xml-apis-1.3.03.pom [WARNING] Unable to get resource from repository apache-cvs (http://svn.apache.o rg/repository) Downloading: http://mirrors.sunsite.dk/maven2/xerces/xercesImpl/2.8.0/xercesImpl -2.8.0.jar 1178K downloaded [INFO] [compiler:compile] Compiling 651 source files to D:\dev\workspace\cocoon-2.2\core\cocoon-core\targe t\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[26,19] cannot resolve symbol symbol : class DOMConfiguration location: package dom D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[39,19] cannot resolve symbol symbol : class UserDataHandler location: package dom D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[913,11] cannot resolve symbol symbol : class DOMConfiguration location: class org.apache.cocoon.xml.dom.DocumentWrapper D:\dev\workspace\cocoon-2.2\core\cocoon-core\src\main\java\org\apache\cocoon\xml \dom\DocumentWrapper.java:[1011,56] cannot resolve symbol symbol : class UserDataHandler location: class org.apache.cocoon.xml.dom.DocumentWrapper
Re: [2.2] Classloading
Reinhard Poetz schrieb: Giacomo Pati wrote: Hmm, good question. Do we need to clone the maven webapp-plugin (the one creating a war/webapp structure)? No, I think/hope that we can do this in our deployer tool. Not sure we can (Reinhard?) The cocoon-deployer-maven-plugin *extends* the maven-war-plugin as good as possible[1]. We only have to upgrade the dependency in the POM whenever we want to use a new maven-war-plugin. The only disadvantage of this is that implementing Carsten's idea c) Change the deployer tool to *not* put all jars in WEB-INF/lib and classes in WEB-INF/classes. would lead to a lot of code duplication as we would have to build the web application ourselves. So I'm -1 on this as at least I don't want to maintain this fork. Ok, are you -1 on the whole classloading idea or just on point c)? I haven't looked at your deployer tool and I only briefly looked at the maven war plugin some time ago, but couldn't we just extend the plugin (like you do) and move the jar files from WEB-INF/lib to whatever directory we want after the original code is finished building the webapp. So this would be a simple post processor. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Error building trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Antonio Gallardo wrote: Date: Fri, 19 May 2006 09:25:04 -0500 From: Antonio Gallardo [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [2.2] Error building trunk Giacomo Pati escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 May 2006, Carsten Ziegeler wrote: Date: Fri, 19 May 2006 10:12:32 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Error building trunk After the recent changes to our poms, I get the following error: I've changed one to sync them to xercesImpl-2.8.0 (which another pom.xml was changed by someone to that version). But my trunk compiles without problems. It seems that we are now using the wrong xml-apis version for compilation. There is 2.0.2 available on ibiblio but I dunno whether this is needed (a change from 1.X to 2.X on an api jar makes me think about compatability problems). In xml-apis, there was a versioning problem and for this reasons 2.0.2 is older than 1.3.03. 2.0.2 does not contain DOM 3. xml-apis 1.3.03 contains DOM 3 and is the latest version. Oh, I remember (long long ago IIRC) Thanks for clarification. - -- 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.3 (GNU/Linux) iD8DBQFEbdg9LNdJvZjjVZARAsbXAJ9+t6jQBA1Z7X43tUWVsvpc50CuegCfYcxT YQ8fZMlBrVOsnwdk7zYkKgQ= =nSLO -END PGP SIGNATURE-
Re: svn commit: r407804 - /cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Fri May 19 07:27:21 2006
New Revision: 407804
URL: http://svn.apache.org/viewvc?rev=407804view=rev
Log:
document Carsten's latest changes to classloading
Carsten, could you please verify if my changes to the comments are correct?
--
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] Error building trunk
Carsten Ziegeler escribió: The problem is that the version used by Xerces only supports Dom-level 2 while we support DOM level 3 in some classes. I think we can just keep our own dependency to xml-apis and are done. Hi Carsten, Would you send the result of ls -l ~/.m2/repository/xml-apis/xml-apis/1.3.03/ in your machine? Best Regards, Antonio Gallardo.
Re: svn commit: r407804 - /cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml
Reinhard Poetz schrieb: [EMAIL PROTECTED] wrote: Author: reinhard Date: Fri May 19 07:27:21 2006 New Revision: 407804 URL: http://svn.apache.org/viewvc?rev=407804view=rev Log: document Carsten's latest changes to classloading Carsten, could you please verify if my changes to the comments are correct? They are not correct :) Currently you have to wrap the CocoonServlet class with the ParanoidServlet. I'll add the remaining parts over the weekend and will then also update the comment. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Classloading
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
Giacomo Pati wrote:
Hmm, good question.
Do we need to clone the maven webapp-plugin (the one creating a
war/webapp structure)?
No, I think/hope that we can do this in our deployer tool.
Not sure we can (Reinhard?)
The cocoon-deployer-maven-plugin *extends* the maven-war-plugin as good as
possible[1]. We only have to upgrade the dependency in the POM whenever we want
to use a new maven-war-plugin.
The only disadvantage of this is that implementing Carsten's idea c) Change the
deployer tool to *not* put all jars in WEB-INF/lib and classes in
WEB-INF/classes. would lead to a lot of code duplication as we would have to
build the web application ourselves. So I'm -1 on this as at least I don't want
to maintain this fork.
Ok, are you -1 on the whole classloading idea or just on point c)?
only point c)
except we find some way so that we don't have to reinvent the maven-war-plugin
I
haven't looked at your deployer tool and I only briefly looked at the
maven war plugin some time ago, but couldn't we just extend the plugin
(like you do) and move the jar files from WEB-INF/lib to whatever
directory we want after the original code is finished building the
webapp. So this would be a simple post processor.
hmmm, that would be easy but I'm not sure if we should really do this. If the
ParanoidClassloader is not used, the developer has to take care that he
configures the cocoon-deployer-plugin correctly too.
--
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] Error building trunk
Antonio Gallardo wrote: Hi Carsten, Would you send the result of ls -l ~/.m2/repository/xml-apis/xml-apis/1.3.03/ in your machine? I don't have a 1.3.03 directory there. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Error building trunk
Carsten Ziegeler escribió: Antonio Gallardo wrote: Hi Carsten, Would you send the result of ls -l ~/.m2/repository/xml-apis/xml-apis/1.3.03/ in your machine? I don't have a 1.3.03 directory there. Hence this is the problem. ;-) Best Regards, Antonio Gallardo.
Re: [2.2] Error building trunk
Carsten Ziegeler wrote: After the recent changes to our poms, I get the following error: It seems that we are now using the wrong xml-apis version for compilation. The only thing that i absolutely don't understand is why continuum did not send a notification to the mailing list. It is scheduled to do a clean build at 3am of all blocks that have scm changes, it should have flagged this. puzzled ... Jorg
[continuum] BUILD ERROR: paranoid Block
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/88/buildId/1201 Build statistics: State: Error Previous State: Ok Started at: Sat, 20 May 2006 03:34:00 + Finished at: Sat, 20 May 2006 03:34:02 + Total time: 1s Build Trigger: Schedule 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 Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
[continuum] BUILD ERROR: paranoid Block Implementation
Online report : http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/89/buildId/1202 Build statistics: State: Error Previous State: Ok Started at: Sat, 20 May 2006 03:34:02 + Finished at: Sat, 20 May 2006 03:34:06 + Total time: 3s Build Trigger: Schedule 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 Build Error: Provider message: The svn command failed. Command output: --- svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within ---
