I am using maven3.03 and Eclipse 3.5 on Windows XP. I converted old web project to be in maven configuration style. When i compile the project in eclipse everything compile.Note: The classpath contains: Maven Dependencies and JDK(1.6_018).
When i compile from command line using mvn, I get few errors:
1.package com.sun.xml.internal.stream.buffer.stax does not exist.
2.package com.sun.xml.internal.stream.writers does not exist
3.cannot find symbol - symbol : class XMLDOMWriterImpl
4.package com.sun.xml.internal.messaging.saaj.util does not exist
5.package com.sun.xml.internal.bind.v2.runtime.unmarshaller does not exist
6.cannot find symbol - symbol : class NamespaceContexHelper
7.cannot find symbol symbol : class ByteOutputStream

I can see that this something with sun jar. But i just can not understand why eclipse is ok and command line is not. Please Help!

In Eclipse i get warning and in maven i get error. I did check the org.eclipse.jdt.core.prefs and see the setting is org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning.

Update:
I got read of some of the above errors. The "problem" is that in eclipse it appears as unused import. Stangly maven report this as error. After removing this unused import the error was gone. But still problem 3 and 7 occures

Conclusion: I guess that the warnings become errors in the javac. since I don't use any supressWarnings. I am just suprised that the error is different.
What is it?
Thanks!!

3 Answers
3

" Jerome is right that it's not recommended practice to use com.sun
classes from rt.jar. And especially ones marked "internal"; you're just
asking for trouble.

However I was curious about this, so tried it out. The above class can
indeed be accessed by Eclipse. However compiling the code on the
commandline using javac fails with the "does not exist" error. So my
assumption is that Sun's java compiler detects when a special
"internal" class is being accessed, and refuses to import the class.
Eclipse uses a different compiler which presumably does not have this check.

Maven just uses the javac compiler available in the system execution
path. Therefore the problem is nothing to do with Maven at all. It's the
compiler that maven is invoking which is refusing to compile the source.
I can't see any public flags in the javac commandline to disable this
"blocking" of internal access, so unless you want to avoid using Sun's
javac compiler you'll just have to avoid using this internal class.

Just for fun, I tried out Jerome's suggestion of putting rt.jar on the
classpath:
javac -cp /usr/java/jdk1.6.0_03/jre/lib/rt.jar Foo.java
but that still failed to compile.

The ByteOutputStream class can be loaded at runtime via
Class.forName("..").

Interestingly, a project I'm working on does happen to import class
com.sun.org.apache.xml.internal.utils.SAXSourceLocator;
and this works ok. Warnings are issued, but the code compiles (and yes,
it's on my TODO list to fix this :-). So it's not all internal classes
that are being blocked, just selected ones. "

+1 if the java version differs, adding the maven-compiler-plugin with configuration of source and target pointing towards 1.6 and updating the project configuration from the Maven project context menu will solve the problem in many cases
–
OmnaestJul 3 '11 at 17:12

To be clear, I'm talking about the actual directory for which Java is being used rather than Java 5 vs Java 6
–
Jeanne BoyarskyJul 3 '11 at 17:44

Ok i added it as separate answer to not confuse someone
–
OmnaestJul 3 '11 at 18:27

Jeanne, I didn't understand - what do you mean in "that are included in some versions of Java and not others" and "actual directory"?
–
ronkJul 3 '11 at 19:00

IBM likes to include things in their JDK that shouldn't be/aren't in the runtime. This means if you compile with the IBM JDK, things seem fine and when you compile with another JDK, classes are missing.
–
Jeanne BoyarskyJul 3 '11 at 19:44

with configuration of source and target pointing towards 1.6 and
updating the project configuration from the Maven project context menu will solve the out of sync problem in many cases (which leads to different compilation results):

thank you. I tried the maven-compiler-plugin as you wrote and it didn't help. I didn't try your second suggestion ("Update Project Configuration") (it sometimes change my .classpath in a strange way) but I will try that again and let you know. Thanks again.
–
ronkJul 3 '11 at 18:54

Didn't work. The strange thing is that it changes the .classpath file with J2SE_1.6 instead of eclipse that is using JDK1.6_018.
–
ronkJul 4 '11 at 9:14