You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Alfred Nathaniel <an...@apache.org> on 2007/07/10 22:52:35 UTC

2.2 does not build with JDK1.4.2

There seems to be a Maven-intrinsic problem with building trunk using a
1.4.2 JVM.  With maven version 2.0.6 and the command line

  $ MAVEN_OPTS="-Xmx200m"
  $ export MAVEN_OPTS
  $ mvn -Dmaven.test.skip=true -P allblocks clean install

I get consistent build failures for cocoon-databases-impl

        [INFO] Failed to resolve artifact.
        
        Missing:
        ----------
        1) org.springframework:spring-dao:jar:2.4.1
        
          Try downloading the file manually from the project website.
        
          Then, install it using the command:
              mvn install:install-file -DgroupId=org.springframework
        -DartifactId=spring-dao \
                  -Dversion=2.4.1 -Dpackaging=jar -Dfile=/path/to/file
        
          Path to dependency:
                1)
        org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT
                2) org.springframework:spring-jdbc:jar:2.0.6
                3) org.springframework:spring-dao:jar:2.4.1
        
        ----------
        1 required artifact is missing.
        
        for artifact:
          org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT

The version number 2.4.1 for spring-dao is phoney, the latest version
being 2.0.6.  The dependency in the spring-jdbc pom.xml is simply:

    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>spring-dao</artifactId>
      <version>${project.version}</version>
    </dependency>

This seems to be an incarnation of
http://jira.codehaus.org/browse/MNG-2653

I see this with Sun JDK1.4.2_13 on Linux.  (Is it by chance that 2.4.1
is 1.4.2 spelled backwards?)  With JDK1.5.0_09 the build runs through.

More fuel for the discussion on 1.4 vs 1.5 as minimum JVM for 2.2...

Cheers, Alfred.

Re: 2.2 does not build with JDK1.4.2

Posted by Grzegorz Kossakowski <gk...@apache.org>.
Alfred Nathaniel pisze:
> On Mon, 2007-07-16 at 14:32 -0400, Joerg Heinicke wrote:
> 
>> Can somebody please try out to add this dependency explicitly or exclude 
>> it if we don't need it.
> 
> I added the transtive dependencies to the two POMs which needed them.
> Now the build runs through and also the samples work again.
> The endorsed problem I had before has vanished by itself.
> Sigh - this habit of unreproducable behaviour is a real pain with 2.2

Alfred, since you didn't mention revision numbers I'm not sure what changes you were talking about. 
However, build has been failing with Java 1.4 up to my recent commit r567671. Now it compiles when 
Java 1.4 is used.

I spotted this issue thanks to our new Continuum setup.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Re: 2.2 does not build with JDK1.4.2

Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.07.2007 16:16, Alfred Nathaniel wrote:

>> Can somebody please try out to add this dependency explicitly or exclude 
>> it if we don't need it.
> 
> I added the transtive dependencies to the two POMs which needed them.
> Now the build runs through and also the samples work again.

Thanks very much, Alfred.

Joerg

Re: 2.2 does not build with JDK1.4.2

Posted by Alfred Nathaniel <an...@apache.org>.
On Mon, 2007-07-16 at 14:32 -0400, Joerg Heinicke wrote:

> Can somebody please try out to add this dependency explicitly or exclude 
> it if we don't need it.

I added the transtive dependencies to the two POMs which needed them.
Now the build runs through and also the samples work again.
The endorsed problem I had before has vanished by itself.
Sigh - this habit of unreproducable behaviour is a real pain with 2.2

Cheers, Alfred.

Re: 2.2 does not build with JDK1.4.2

Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.07.2007 02:49, Carsten Ziegeler wrote:

>>> What's so specific about this spring-dao.jar or it's pom that only for it
>>> this property is retrieved?
>> 
>> How does this dependency come in at all? It's not a direct dependency of
>> Cocoon. Aren't all direct and transitive dependencies supposed to be
>> declared in our POM?
>>
> I guess its an oversight

Can somebody please try out to add this dependency explicitly or exclude 
it if we don't need it.
I don't have a pc available at the moment (and probably another few 
days/weeks) where I can do this.

Thanks,
Joerg

Re: 2.2 does not build with JDK1.4.2

Posted by Carsten Ziegeler <cz...@apache.org>.
Joerg Heinicke schrieb:
> On 13.07.2007 15:30, Joerg Heinicke wrote:
> 
>> What's so specific about this spring-dao.jar or it's pom that only for it
>> this property is retrieved?
> 
> How does this dependency come in at all? It's not a direct dependency of
> Cocoon. Aren't all direct and transitive dependencies supposed to be
> declared in our POM?
> 
I guess its an oversight


Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: 2.2 does not build with JDK1.4.2

Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 15:30, Joerg Heinicke wrote:

> What's so specific about this spring-dao.jar or it's pom that only for it
> this property is retrieved?

How does this dependency come in at all? It's not a direct dependency of 
Cocoon. Aren't all direct and transitive dependencies supposed to be 
declared in our POM?

Joerg

Re: 2.2 does not build with JDK1.4.2

Posted by Joerg Heinicke <jo...@gmx.de>.
On 13.07.2007 06:23, Carsten Ziegeler wrote:

>> Actually in Jan you filed yourself a bugreport
>> http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
>> resolved to 2.4.1.  (You were then still using JDK1.4.2?)
> Yes, I used 1.4.2
>
>> <snip/>
>> I guess that is due an endorsed Xalan/Xerces problem.
> Yepp.

>From what I understand from all those uncountable and cross-linked Maven issues
is that they somehow retrieve a wrong system propery. And somehow the Xalan or
Xerces coming with JDK 1.4.2 sets this property. What's so specific about this
spring-dao.jar or it's pom that only for it this property is retrieved? Maybe
it's just a change necessary in the pom that might keep Maven away from that
property.

Joerg

Re: 2.2 does not build with JDK1.4.2

Posted by Carsten Ziegeler <cz...@apache.org>.
Alfred Nathaniel wrote:
> On Wed, 2007-07-11 at 07:50 +0200, Carsten Ziegeler wrote:
>> Hi,
>>
>> did you try maven 2.0.7 with jdk 1.4.2?
>>
>> While building Cocoon with 2.0.7 and jdk1.5, I noticed that the version
>> for the spring-dao was resolved to 2.0.4....which fortunately is
>> available :(
>>
>> Carsten
> 
> Nope, same problem with maven 2.0.7.
> 
> Actually in Jan you filed yourself a bugreport
> http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
> resolved to 2.4.1.  (You were then still using JDK1.4.2?)
Yes, I used 1.4.2

> 
> Reading http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
> I gather the problem it is deeply rooted in maven and may be tackled
> only with maven 2.1.x.
Yes, unfortunately - I still don't get why maven does not simply replace
the properties on deployment. sigh.

> 
> <snip/>
> I guess that is due an endorsed Xalan/Xerces problem.
Yepp.

> 
> This is really getting out of hands.  I am now dumping 1.4.2.
:)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: 2.2 does not build with JDK1.4.2

Posted by Alfred Nathaniel <an...@apache.org>.
On Wed, 2007-07-11 at 07:50 +0200, Carsten Ziegeler wrote:
> Hi,
> 
> did you try maven 2.0.7 with jdk 1.4.2?
> 
> While building Cocoon with 2.0.7 and jdk1.5, I noticed that the version
> for the spring-dao was resolved to 2.0.4....which fortunately is
> available :(
> 
> Carsten

Nope, same problem with maven 2.0.7.

Actually in Jan you filed yourself a bugreport
http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
resolved to 2.4.1.  (You were then still using JDK1.4.2?)

Reading http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
I gather the problem it is deeply rooted in maven and may be tackled
only with maven 2.1.x.

As it seems, it affects only transitive dependencies.  So a possible
workaround is to spell out these dependencies in our own poms.
There are just two poms to patch:

cocoon-databases-impl:
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-dao</artifactId>
      <version>2.0.6</version>
    </dependency>    

cocoon-javaflow-impl:
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-util</artifactId>
      <version>2.2.1</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-attrs</artifactId>
      <version>2.2.1</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-analysis</artifactId>
      <version>2.2.1</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm-tree</artifactId>
      <version>2.2.1</version>
    </dependency>

Then the build runs through successfully (after increasing max memory to
-Xmx250m).  There are still trace messages "Downloading:
http://repo1.maven.org/maven2/org/springframework/spring-dao/2.4.1/spring-dao-2.4.1.pom which seem to be harmless.

However, the server does not run properly.  The homepage still loads but
http://localhost:8888/samples/ aborts with 

java.lang.NoSuchMethodError:
javax.xml.transform.dom.DOMResult.getNextSibling()Lorg/w3c/dom/Node;
	at org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:199)
	at org.apache.xalan.transformer.TransformerIdentityImpl.setDocumentLocator(TransformerIdentityImpl.java:880)
	at org.apache.cocoon.xml.AbstractXMLPipe.setDocumentLocator(AbstractXMLPipe.java:39)
	at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source)
	at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source)
	at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.apache.cocoon.core.xml.impl.JaxpSAXParser.parse(JaxpSAXParser.java:196)
	at org.apache.cocoon.core.xml.avalon.DefaultSAXParser.parse(DefaultSAXParser.java:47)
	at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:127)
	at org.apache.cocoon.components.source.util.SourceUtil.toSAX(SourceUtil.java:180)
	at org.apache.cocoon.components.source.util.SourceUtil.toDOM(SourceUtil.java:309)
	at org.apache.cocoon.generation.XPathTraversableGenerator.performXPathQuery(XPathTraversableGenerator.java:220)
	at org.apache.cocoon.generation.XPathTraversableGenerator.addContent(XPathTraversableGenerator.java:196)
	at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:482)
	at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464)
	at org.apache.cocoon.generation.TraversableGenerator.addPath(TraversableGenerator.java:464)
	at org.apache.cocoon.generation.TraversableGenerator.addAncestorPath(TraversableGenerator.java:383)
	at org.apache.cocoon.generation.TraversableGenerator.generate(TraversableGenerator.java:321)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
	at $Proxy6.generate(Unknown Source)
	at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:363)
	at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:437)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(PoolableProxyHandler.java:72)
	at $Proxy5.process(Unknown Source)
	at org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:143)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
	at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
	at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
	at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
	at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
	at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
	at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
	at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:115)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
	at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
	at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:151)
	at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
	at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
	at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:240)
	at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:171)
	at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:251)
	at org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:357)
	at org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:171)
	at org.apache.cocoon.servlet.SitemapServlet.service(SitemapServlet.java:41)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
	at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:119)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
	at org.mortbay.jetty.Server.handle(Server.java:303)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

I guess that is due an endorsed Xalan/Xerces problem.

This is really getting out of hands.  I am now dumping 1.4.2.

Cheers, Alfred.

Re: 2.2 does not build with JDK1.4.2

Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,

did you try maven 2.0.7 with jdk 1.4.2?

While building Cocoon with 2.0.7 and jdk1.5, I noticed that the version
for the spring-dao was resolved to 2.0.4....which fortunately is
available :(

Carsten

Alfred Nathaniel wrote:
> There seems to be a Maven-intrinsic problem with building trunk using a
> 1.4.2 JVM.  With maven version 2.0.6 and the command line
> 
>   $ MAVEN_OPTS="-Xmx200m"
>   $ export MAVEN_OPTS
>   $ mvn -Dmaven.test.skip=true -P allblocks clean install
> 
> I get consistent build failures for cocoon-databases-impl
> 
>         [INFO] Failed to resolve artifact.
>         
>         Missing:
>         ----------
>         1) org.springframework:spring-dao:jar:2.4.1
>         
>           Try downloading the file manually from the project website.
>         
>           Then, install it using the command:
>               mvn install:install-file -DgroupId=org.springframework
>         -DartifactId=spring-dao \
>                   -Dversion=2.4.1 -Dpackaging=jar -Dfile=/path/to/file
>         
>           Path to dependency:
>                 1)
>         org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT
>                 2) org.springframework:spring-jdbc:jar:2.0.6
>                 3) org.springframework:spring-dao:jar:2.4.1
>         
>         ----------
>         1 required artifact is missing.
>         
>         for artifact:
>           org.apache.cocoon:cocoon-databases-impl:jar:1.0.0-RC2-SNAPSHOT
> 
> The version number 2.4.1 for spring-dao is phoney, the latest version
> being 2.0.6.  The dependency in the spring-jdbc pom.xml is simply:
> 
>     <dependency>
>       <groupId>${project.groupId}</groupId>
>       <artifactId>spring-dao</artifactId>
>       <version>${project.version}</version>
>     </dependency>
> 
> This seems to be an incarnation of
> http://jira.codehaus.org/browse/MNG-2653
> 
> I see this with Sun JDK1.4.2_13 on Linux.  (Is it by chance that 2.4.1
> is 1.4.2 spelled backwards?)  With JDK1.5.0_09 the build runs through.
> 
> More fuel for the discussion on 1.4 vs 1.5 as minimum JVM for 2.2...
> 
> Cheers, Alfred.
> 
> 
> 
> 


-- 
Carsten Ziegeler
cziegeler@apache.org