Re: [M2] Compilation problems with latest from SVN
Carsten Ziegeler wrote: Brett Porter wrote: This be related to the compiler changes that have been going on. Carsten - can you svn up with th elogging I just added and check the library is passed in? Sure, I can't at the moment, but I'll try tonight and report back tomorrow. Carsten Attached is the log containing the classpath. Now the problem is, that we depend on xml-apis.1.3.02 - which is the official version of the xml-apis containing DOM level 3 classes. As you can see from the log, xml-apis-2.0.2 is used instead. I guess this comes from the transitive dependencies from some other project. Unfortunately 2.0.2 is a faulty number and it is higer than 1.3.02, so 2.0.2 is preferred over 1.3.02. So, is there any way to turn of transitive dependencies and is there any way to tell that 1.3.02 should always be used? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
(This time with log attached) Carsten Ziegeler wrote: Brett Porter wrote: This be related to the compiler changes that have been going on. Carsten - can you svn up with th elogging I just added and check the library is passed in? Sure, I can't at the moment, but I'll try tonight and report back tomorrow. Carsten Attached is the log containing the classpath. Now the problem is, that we depend on xml-apis.1.3.02 - which is the official version of the xml-apis containing DOM level 3 classes. As you can see from the log, xml-apis-2.0.2 is used instead. I guess this comes from the transitive dependencies from some other project. Unfortunately 2.0.2 is a faulty number and it is higer than 1.3.02, so 2.0.2 is preferred over 1.3.02. So, is there any way to turn of transitive dependencies and is there any way to tell that 1.3.02 should always be used? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ [DEBUG] Source directories: [D:\dev\workspace\cocoon-2.2\core\..\src\java] [DEBUG] Classpath: [D:\dev\workspace\cocoon-2.2\core\target\classes D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-instrumented\2.0.0\excalibur-pool-instrumented-2.0.0.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-log_all\1.0.0\knopflerfish-log_all-1.0.0.jar D:\dev\maven-repo\repository\jakarta-bcel\jakarta-bcel\20040329\jakarta-bcel-20040329.jar D:\dev\maven-repo\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar D:\dev\maven-repo\repository\commons-beanutils\commons-beanutils\1.4\commons-beanutils-1.4.jar D:\dev\maven-repo\repository\excalibur-store\excalibur-store\1.0\excalibur-store-1.0.jar D:\dev\maven-repo\repository\rhino\rhino\1.6R1\rhino-1.6R1.jar D:\dev\maven-repo\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar D:\dev\maven-repo\repository\commons-jxpath\commons-jxpath\1.2\commons-jxpath-1.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-logcommands\1.0.0\knopflerfish-logcommands-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-api\2.0.0\excalibur-pool-api-2.0.0.jar D:\dev\maven-repo\repository\ant\ant-optional\1.5.1\ant-optional-1.5.1.jar D:\dev\maven-repo\repository\xml-apis\xml-apis\2.0.2\xml-apis-2.0.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-framework\1.3.3\knopflerfish-framework-1.3.3.jar D:\dev\maven-repo\repository\excalibur-io\excalibur-io\1.1\excalibur-io-1.1.jar D:\dev\maven-repo\repository\xmlbeans\xmlbeans\1.0.3\xmlbeans-1.0.3.jar D:\dev\maven-repo\repository\regexp\regexp\1.3\regexp-1.3.jar D:\dev\maven-repo\repository\commons-httpclient\commons-httpclient\2.0.2\commons-httpclient-2.0.2.jar D:\dev\maven-repo\repository\xerces\xercesImpl\2.7.1\xercesImpl-2.7.1.jar D:\dev\maven-repo\repository\excalibur-naming\excalibur-naming\1.0\excalibur-naming-1.0.jar D:\dev\maven-repo\repository\excalibur-instrument\excalibur-instrument\1.0\excalibur-instrument-1.0.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-impl\4.2.0\avalon-framework-impl-4.2.0.jar D:\dev\maven-repo\repository\commons-jci\commons-jci\r159148\commons-jci-r159148.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-http_all\1.1.0\knopflerfish-http_all-1.1.0.jar D:\dev\maven-repo\repository\xml-resolver\xml-resolver\1.1\xml-resolver-1.1.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-cm_api\1.0.0\knopflerfish-cm_api-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-impl\2.0.0\excalibur-pool-impl-2.0.0.jar D:\dev\maven-repo\repository\xalan\xalan\2.7.0\xalan-2.7.0.jar D:\dev\maven-repo\repository\excalibur-xmlutil\excalibur-xmlutil\1.0\excalibur-xmlutil-1.0.jar D:\dev\maven-repo\repository\log4j\log4j\1.2.11\log4j-1.2.11.jar D:\dev\maven-repo\repository\excalibur-sourceresolve\excalibur-sourceresolve\1.1\excalibur-sourceresolve-1.1.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-api\4.2.0\avalon-framework-api-4.2.0.jar D:\dev\maven-repo\repository\concurrent\concurrent\1.3.4\concurrent-1.3.4.jar D:\dev\maven-repo\repository\junit\junit\3.8.1\junit-3.8.1.jar D:\dev\maven-repo\repository\ant\ant\1.6.5\ant-1.6.5.jar D:\dev\maven-repo\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework\4.1.3\avalon-framework-4.1.3.jar D:\dev\maven-repo\repository\commons-cli\commons-cli\1.0\commons-cli-1.0.jar D:\dev\maven-repo\repository\commons-jexl\commons-jexl\1.0\commons-jexl-1.0.jar D:\dev\maven-repo\repository\logkit\logkit\1.2.2\logkit-1.2.2.jar D:\dev\maven-repo\repository\excalibur-logger\excalibur-logger\1.1\excalibur-logger-1.1.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-consoletty\1.0.0\knopflerfish-consoletty-1.0.0.jar D:\dev\maven-repo\repository\servletapi\servletapi\2.3\servletapi-2.3.jar
Re: [M2] Compilation problems with latest from SVN
That's actually a bug we need to fix. While the resolution technique might be latest instead of nearest, I think the version in the current POM should always win. You could actually do this by using [1.3.02] in the mean time, or you can add exclusions for those introducing the other xml-apis (trace that using -X). If you actually think they are erroneous in the first place, feel free to file a MEV JIRA issue. The xml-apis situation is quite a mess and unfortunately 2.0.2 seems very prevalent. It would be fantastic if we could get some sanctioned releases to use instead (or can we use jaxp-1.3?) - Brett Carsten Ziegeler wrote: (This time with log attached) Carsten Ziegeler wrote: Brett Porter wrote: This be related to the compiler changes that have been going on. Carsten - can you svn up with th elogging I just added and check the library is passed in? Sure, I can't at the moment, but I'll try tonight and report back tomorrow. Carsten Attached is the log containing the classpath. Now the problem is, that we depend on xml-apis.1.3.02 - which is the official version of the xml-apis containing DOM level 3 classes. As you can see from the log, xml-apis-2.0.2 is used instead. I guess this comes from the transitive dependencies from some other project. Unfortunately 2.0.2 is a faulty number and it is higer than 1.3.02, so 2.0.2 is preferred over 1.3.02. So, is there any way to turn of transitive dependencies and is there any way to tell that 1.3.02 should always be used? Carsten [DEBUG] Source directories: [D:\dev\workspace\cocoon-2.2\core\..\src\java] [DEBUG] Classpath: [D:\dev\workspace\cocoon-2.2\core\target\classes D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-instrumented\2.0.0\excalibur-pool-instrumented-2.0.0.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-log_all\1.0.0\knopflerfish-log_all-1.0.0.jar D:\dev\maven-repo\repository\jakarta-bcel\jakarta-bcel\20040329\jakarta-bcel-20040329.jar D:\dev\maven-repo\repository\commons-logging\commons-logging\1.0.4\commons-logging-1.0.4.jar D:\dev\maven-repo\repository\commons-beanutils\commons-beanutils\1.4\commons-beanutils-1.4.jar D:\dev\maven-repo\repository\excalibur-store\excalibur-store\1.0\excalibur-store-1.0.jar D:\dev\maven-repo\repository\rhino\rhino\1.6R1\rhino-1.6R1.jar D:\dev\maven-repo\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar D:\dev\maven-repo\repository\commons-jxpath\commons-jxpath\1.2\commons-jxpath-1.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-logcommands\1.0.0\knopflerfish-logcommands-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-api\2.0.0\excalibur-pool-api-2.0.0.jar D:\dev\maven-repo\repository\ant\ant-optional\1.5.1\ant-optional-1.5.1.jar D:\dev\maven-repo\repository\xml-apis\xml-apis\2.0.2\xml-apis-2.0.2.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-framework\1.3.3\knopflerfish-framework-1.3.3.jar D:\dev\maven-repo\repository\excalibur-io\excalibur-io\1.1\excalibur-io-1.1.jar D:\dev\maven-repo\repository\xmlbeans\xmlbeans\1.0.3\xmlbeans-1.0.3.jar D:\dev\maven-repo\repository\regexp\regexp\1.3\regexp-1.3.jar D:\dev\maven-repo\repository\commons-httpclient\commons-httpclient\2.0.2\commons-httpclient-2.0.2.jar D:\dev\maven-repo\repository\xerces\xercesImpl\2.7.1\xercesImpl-2.7.1.jar D:\dev\maven-repo\repository\excalibur-naming\excalibur-naming\1.0\excalibur-naming-1.0.jar D:\dev\maven-repo\repository\excalibur-instrument\excalibur-instrument\1.0\excalibur-instrument-1.0.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-impl\4.2.0\avalon-framework-impl-4.2.0.jar D:\dev\maven-repo\repository\commons-jci\commons-jci\r159148\commons-jci-r159148.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-http_all\1.1.0\knopflerfish-http_all-1.1.0.jar D:\dev\maven-repo\repository\xml-resolver\xml-resolver\1.1\xml-resolver-1.1.jar D:\dev\maven-repo\repository\knopflerfish\knopflerfish-cm_api\1.0.0\knopflerfish-cm_api-1.0.0.jar D:\dev\maven-repo\repository\excalibur-pool\excalibur-pool-impl\2.0.0\excalibur-pool-impl-2.0.0.jar D:\dev\maven-repo\repository\xalan\xalan\2.7.0\xalan-2.7.0.jar D:\dev\maven-repo\repository\excalibur-xmlutil\excalibur-xmlutil\1.0\excalibur-xmlutil-1.0.jar D:\dev\maven-repo\repository\log4j\log4j\1.2.11\log4j-1.2.11.jar D:\dev\maven-repo\repository\excalibur-sourceresolve\excalibur-sourceresolve\1.1\excalibur-sourceresolve-1.1.jar D:\dev\maven-repo\repository\avalon-framework\avalon-framework-api\4.2.0\avalon-framework-api-4.2.0.jar D:\dev\maven-repo\repository\concurrent\concurrent\1.3.4\concurrent-1.3.4.jar D:\dev\maven-repo\repository\junit\junit\3.8.1\junit-3.8.1.jar D:\dev\maven-repo\repository\ant\ant\1.6.5\ant-1.6.5.jar D:\dev\maven-repo\repository\commons-lang\commons-lang\2.1\commons-lang-2.1.jar
Re: [M2] Compilation problems with latest from SVN
Carsten Ziegeler wrote: How do I specify this? version[1.3.02]/version creates a NPE. Another bug?! Does [1.3.02,1.3.02] work? I was thinking about using a new name like xml-commons-apis as it is a sub project of the xml-commons project. This would solve the mess but introduce a new name. Even better. We can just deprecate the old one entirely. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter wrote: That's actually a bug we need to fix. While the resolution technique might be latest instead of nearest, I think the version in the current POM should always win. Yes :) You could actually do this by using [1.3.02] in the mean time, How do I specify this? version[1.3.02]/version creates a NPE. or you can add exclusions for those introducing the other xml-apis (trace that using -X). If you actually think they are erroneous in the first place, feel free to file a MEV JIRA issue. The xml-apis situation is quite a mess and unfortunately 2.0.2 seems very prevalent. It would be fantastic if we could get some sanctioned releases to use instead (or can we use jaxp-1.3?) I was thinking about using a new name like xml-commons-apis as it is a sub project of the xml-commons project. This would solve the mess but introduce a new name. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter wrote: Carsten Ziegeler wrote: How do I specify this? version[1.3.02]/version creates a NPE. Another bug?! It seems so :( I get this stack trace: java.lang.NullPointerException: version was null for xml-apis:xml-apis at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtif act.java:295) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java: 202) at org.apache.maven.artifact.resolver.DebugResolutionListener.includeArt ifact(DebugResolutionListener.java:56) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent (DefaultArtifactCollector.java:275) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent (DefaultArtifactCollector.java:254) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(D efaultArtifactCollector.java:166) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(D efaultArtifactCollector.java:204) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(D efaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra Does [1.3.02,1.3.02] work? No, you get this message :) (which is ok) I tried [1.3.01,1.3.02] and [1.3.02,1.3.03] all resulting in the same NPE. Do you want me to file a JIRA issue? Carsten [INFO] Main Error: Error in dependency version Root error: Range cannot have identical boundaries: [1.3.02,1.3.02] [INFO] - --- [DEBUG] Trace org.apache.maven.artifact.resolver.ArtifactResolutionException: Error in depende ncy version at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende ncies(DefaultPluginManager.java:1180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:312) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:437) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:131) -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Do you want me to file a JIRA issue? Yep, I'll take a look tomorrow. Sorry about that. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Compilation problems with latest from SVN
After updating from alpha-3 to the latest from SVN I can't compile Cocoon anymore. I think the problem is related to classloading or handling of classes. As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 interfaces. Although we have declared this dependency in the POM and the jar is downloaded, the DOM level 3 classes are not found. So I guess that classes inside the org.w3c.dom package (and others) comming from the dependencies are ignored and the system classes are used instead. (But this is just a guess). Any idea how to solve this? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
I think I picked up a wrong subject, of course I don't mean that I have problems compiling m2 itself. I have problems while using m2 to compile my own project. Carsten Carsten Ziegeler wrote: After updating from alpha-3 to the latest from SVN I can't compile Cocoon anymore. I think the problem is related to classloading or handling of classes. As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 interfaces. Although we have declared this dependency in the POM and the jar is downloaded, the DOM level 3 classes are not found. So I guess that classes inside the org.w3c.dom package (and others) comming from the dependencies are ignored and the system classes are used instead. (But this is just a guess). Any idea how to solve this? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
This be related to the compiler changes that have been going on. Carsten - can you svn up with th elogging I just added and check the library is passed in? Thanks, Brett Carsten Ziegeler wrote: I think I picked up a wrong subject, of course I don't mean that I have problems compiling m2 itself. I have problems while using m2 to compile my own project. Carsten Carsten Ziegeler wrote: After updating from alpha-3 to the latest from SVN I can't compile Cocoon anymore. I think the problem is related to classloading or handling of classes. As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 interfaces. Although we have declared this dependency in the POM and the jar is downloaded, the DOM level 3 classes are not found. So I guess that classes inside the org.w3c.dom package (and others) comming from the dependencies are ignored and the system classes are used instead. (But this is just a guess). Any idea how to solve this? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
Brett Porter schrieb: This be related to the compiler changes that have been going on. Carsten - can you svn up with th elogging I just added and check the library is passed in? Sure, I can't at the moment, but I'll try tonight and report back tomorrow. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Compilation problems with latest from SVN
On Wed, Aug 24, 2005 at 12:03:55PM +0200, Carsten Ziegeler wrote: After updating from alpha-3 to the latest from SVN I can't compile Cocoon anymore. I think the problem is related to classloading or handling of classes. As one dependency we have the xml-apis-1.3.02 implementing DOM level 3 interfaces. Although we have declared this dependency in the POM and the jar is downloaded, the DOM level 3 classes are not found. So I guess that classes inside the org.w3c.dom package (and others) comming from the dependencies are ignored and the system classes are used instead. (But this is just a guess). Any idea how to solve this? Carsten It smelles as an endorsed problem. Maybe, there should be a way to annotate a dependency to be endorsed. Until that, you'd better to install that jar by hand somewhere in your java infrastructure. incze - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
