cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

groovy.util.XmlSlurper or groovy.xml.XmlSlurper?

benjaminnehring
Explorer
13,297

The Groovy script

import com.sap.gateway.ip.core.customdev.util.Message

Message slurper_test(Message message){
    def result = 'XmlSlurper: ' + new XmlSlurper().getClass() + '\n'
    result += 'Groovy version: ' + GroovySystem.getVersion()
    message.setBody(result)
    return message
}

gives currently the following output on my CPI trial:

XmlSlurper: class groovy.util.XmlSlurper

Groovy version: 2.4.21

In the Groovy documentation on the processing of xml are the xml parsers (XmlSlurper and XmlParser) discussed which are contained in the groovy.xml package. So I added the import statement

import groovy.xml.XmlSlurper

to the above script and ran it again, but I received the following error:

javax.script.ScriptException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: script1__Script.groovy: 2: unable to resolve class groovy.xml.XmlSlurper @ line 2, column 1. import groovy.xml.XmlSlurper

By consulting the Groovy documentation of the package groovy.xml for version 2.4.21 this error becomes clear as there is no XmlSlurper class within the groovy.xml package in this version of Groovy. However it seems that starting with Groovy version 3.0.0 the xml parser classes in the groovy.util package are marked as deprecated and with Groovy version 4.0.0 the xml parser classes are even removed from the groovy.util package. My questions are:

  1. Are there any major differences between the xml parser classes in the groovy.util and groovy.xml package or is groovy.xml just a more suitable package name?
  2. Is there a Groovy version update road map for CPI available such that it can be planned to migrate the scripts to use the xml parsers from package groovy.xml when version 3 becomes available on CPI before they are removed from package groovy.util in version 4? I could only find SAP note 3293904 which informs about a Camel version upgrade this year, but does this imply also an upgrade of the Groovy version?

Accepted Solutions (1)

Accepted Solutions (1)

MortenWittrock
SAP Mentor
SAP Mentor

Hi Benjamin

Interesting observation and some very nice research you did before posting your question - well done!

Looking at the documentation of groovy.util.XmlSlurper in 2.4.21 and groovy.xml.XmlSlurper in 3.0.0, I would assume that they are in fact the same class, only now located in a more appropriate package. So if you just skip the import, you'll instantiate the XmlSlurper that's on the classpath and your code will keep running.

(If you want to make absolutely sure, check the source code.)

Regarding your second question, updates to underlying components like the Groovy runtime are too low-level to be on the roadmap. That's actually why I created CPITracker a few years back, but it's not updating the Twitter feed at the moment (not since the Twitter API was changed (I'll get around to fixing it at some point)).

Regards,

Morten

benjaminnehring
Explorer

Hi 7a519509aed84a2c9e6f627841825b5a,

thanks for your response! I just tested this on my computer with Groovy version 3 and 4. If we don't specify any import in Groovy 3 we will keep using groovy.util.XmlSlurper and in Groovy 4 the compiler throws the error: unable to resolve class XmlSlurper. groovy.util belongs to the packages which are by default imported in Groovy, but groovy.xml does not. Maybe it makes sense to add the import

import groovy.xml.*

already to all Groovy scripts (to future proof them)? This way groovy.xml.XmlSlurper is used in Groovy 3 and 4.

BR, Benjamin

MortenWittrock
SAP Mentor
SAP Mentor
0 Likes

Hi bng

I see your point. I do feel fairly sure that this will not be implemented as a breaking change, though.

If you want to monitor it to make sure, you could implement a small, scheduled iflow that checks for XmlSlurper in those two packages and, for instance, sends you an email, if there is a change.

Regards,

Morten

Answers (0)

Ask a Question