jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-334) loadURI compile error with Maven 1.0.2
Date Tue, 07 Mar 2006 06:09:41 GMT
     [ http://issues.apache.org/jira/browse/JCR-334?page=all ]
     
Jukka Zitting resolved JCR-334:
-------------------------------

    Resolution: Fixed

Committed a workaround fix in revision 383794.

The problem was, as pointed out by Peeter, that Maven 1.0.2 placed an older version (2.4.0)
of the Xerces library in the class path before the version (2.6..2) used by Jackrabbit. The
Xerces 2.4.0 version of the XMLSchemaLoader class does not have the loadURI() method available
in the newer version.

The committed fix works around this problem by using the DOM3 implementation registry mechanism
to get a reference to a correct XMLSchemaLoader instance. A nice feature of this fix is that
it also removes the direct dependency to the org.apache.xerces.impl package.

> loadURI compile error with Maven 1.0.2
> --------------------------------------
>
>          Key: JCR-334
>          URL: http://issues.apache.org/jira/browse/JCR-334
>      Project: Jackrabbit
>         Type: Bug
>   Components: maven
>  Environment: Maven 1.0.2
>     Reporter: Jukka Zitting
>     Assignee: Jukka Zitting
>      Fix For: 1.0

>
> As reported on the mailing list by Ashley Martens:
> ----
> C:\apache\jackrabbit-contrib\nt-ns-util>maven
>  __  __
> |  \/  |__ _Apache__ ___
> | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> Attempting to download jackrabbit-1.0-SNAPSHOT.jar.
> Artifact /org.apache.jackrabbit/jars/jackrabbit-1.0-SNAPSHOT.jar doesn't exists in remote
repository, but it exists locally
> Attempting to download jackrabbit-commons-1.0-SNAPSHOT.jar.
> Artifact /org.apache.jackrabbit/jars/jackrabbit-commons-1.0-SNAPSHOT.jar doesn't exists
in remote repository, but it exists locally
> build:start:
> java:prepare-filesystem:
> java:compile:
>    [echo] Compiling to C:\apache\jackrabbit-contrib\nt-ns-util/target/classes
>    [javac] Compiling 1 source file to C:\apache\jackrabbit-contrib\nt-ns-util\target\classes
> C:\apache\jackrabbit-contrib\nt-ns-util\src\main\java\org\apache\jackrabbit\util\nodetype\SchemaConverter.java:71:
cannot resolve symbol
> symbol  : method loadURI (java.lang.String)
> location: class org.apache.xerces.impl.xs.XMLSchemaLoader
>        XSModel xsModel = loader.loadURI(uri);
>                                ^
> 1 error
> BUILD FAILED
> File...... C:\Documents and Settings\ashleym\.maven\cache\maven-java-plugin-1.5\plugin.jelly
> Element... ant:javac
> Line...... 63
> Column.... 48
> Compile failed; see the compiler error output for details.
> Total time: 8 seconds
> Finished at: Mon Jan 02 10:40:47 EST 2006
> ----
> Peeter Piegaze found out the problem:
> ----
> I was able to build it without a problem using maven-1.1-beta-2 and JDK 1.4.2.
> However, it sounds to me like in your case maven has set up its
> on-build classpath so that it sees the older xerces-2.4.0.jar before
> the new xerxesImpl.-2.6.2.jar. Maven seems to download the old
> xerces-2.4.0 into its repository for internal use, while my code uses
> the newer xerxesImpl-2.6.2.jar. The old jar overlaps class-wise with
> the new one, but the new one implements the additional loadURI method
> (among others).
> I am not sure exactly why your maven build process is looking in the
> wrong jar. But that is what is doing, almost certainly.
> ----

-- 
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


Mime
View raw message