Grails classpath container problem

[kalan]

Hi everyone,

I'm having a problem with grails classpath integration in sts.

When I create a new project or import an existing one, the "Grails Dependencies" library container is allways empty. No matter how many times I refresh my dependencies.

I've found that the project-dependencies.xml stored in ".metadata\.plugins\com.springsource.sts.grails.co re" contains all jar dependeny entries pointing to my ".ivy2" directory and a entry pointing to my ".grails" project plugins directory.

I also have 2 different installations, the standard sts release and an eclipse 3.5.1 with all groovy, spring ide and sts plugins installed, and the same problem happens in both of them.

I can't imagine what it's wrong!
Could someone please give a hand?

[Christian Dupuis]

Hey,

can you attach the -dependencies.xml to this post? Also some more details about your Grails, STS and OS version would be useful.

Cheers, Christian

[kalan]

Sorry, I forgot to mention that I'm using Grails 1.2.0 and STS 2.3.0 on a WinXP.

I've attached an example of -dependencies.xml for a new project called "test"

Thank you Christian

[Christian Dupuis]

kalan,

can you take a look into your Error Log (Windows -> Show View -> Other... -> Error Log). Is there anything that could be relevant?

Also please attach your test's projects .classpath and .project file, please.

Christian

[kalan]

mmm.. before looking at error log I've been suspecting about the accent mark in my username in this computer (Héctor), and probably here it is.
I should have started looking at this log...

com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of 3-byte UTF-8 sequence.
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(UTF8Reader.java:684)
at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:405)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1742)
at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(XMLEntityScanner.java:1242)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(XMLDocumentFragmentScannerImpl.java:1646)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2977)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:208)
at com.springsource.sts.grails.core.internal.classpath.GrailsClasspathContainer.refreshClasspathEntries(GrailsClasspathContainer.java:150)
at com.springsource.sts.grails.core.internal.classpath.GrailsClasspathContainer.getClasspathEntries(GrailsClasspathContainer.java:103)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2590)
at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2685)
at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1872)
at org.eclipse.jdt.core.JavaCore.initializeAfterLoad(JavaCore.java:3443)
at org.eclipse.jdt.internal.ui.InitializeAfterLoadJob$RealJob.run(InitializeAfterLoadJob.java:35)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

what do you think?

[Christian Dupuis]

Yeah, that pretty much seems to be the problem.

I'll look into fixing this issue. Let me see.

Christian

[kalan]

ok, thank you!!

[Christian Dupuis]

As a workaround, you can just add the following to the top of your test-dependencies.xml:

<?xml version="1.0" encoding="ISO-8859-1"?>

Restart your STS and you should see content in your classpath container.

Christian

[kalan]

Yes, definitely that was the problem.

I've added a new artifact in my BuildConfig DSL just to try the dependency management and works perfectly.

I will include the xml encoding for the moment

Thank you very much!

[Christian Dupuis]

kalan,

I committed a fix for this issue. Could you verify that this fix works in your environment, please? Encoding issues are hard to re-test and verify on all the different platforms and OSs.

You can update to tomorrow's nightly snapshot from the following update site:

http://www.springsource.com/snapshot/e3.5

Thanks for your help.

Christian