You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/03/07 07:00:38 UTC
[jira] Created: (JCR-334) loadURI compile error with Maven 1.0.2
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
Assigned to: 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
[jira] Resolved: (JCR-334) loadURI compile error with Maven 1.0.2
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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