I am updating one of our S4 SDK projects to use the latest version of the SDK and I noticed then when I try to build the project I got the error:
cannot find symbol> [ERROR] symbol: class TimeSheetEntryField
When I look at the Javadocs I can see that this class existed in version 2.7.0 but is missing in the next version 2.8.0
This import throws an error as it cannot find the class in the newer version:
com.sap.cloud.sdk.s4hana.datamodel.odata.namespaces.workforcetimesheet.TimeSheetEntryField;
I can't see any notice of deprecation. Can you help?
Thanks,
Simon
This class has been moved to a new package com.sap.cloud.sdk.s4hana.datamodel.odata.namespaces.workforcetimesheet.field (see Javadoc) with version 2.8.0. Please update your import accordingly by adding .field to the package name.
As mentioned in the release notes, this was necessary to avoid potential name clashes in the virtual data model of the SAP S/4HANA Cloud SDK.
Related
I'm trying to configure the Test task inside a custom Gradle plugin written in Java.
Applying the plugins I need like so in build.gradle.kts:
plugins {
`java-gradle-plugin`
`maven-publish`
}
I can compile the code successfully through the command line as in ./gradlew clean build
But, IntelliJ complains about Test.class in the following code:
public static void configureTesting(final Project project) {
project.getTasks().withType(Test.class).configureEach(task -> {
});
}
Saying:
Required type: java.lang.Class <S>
Provided: java.lang.Class <Test>
reason: no instance(s) of type variable(s) exist so that T conforms to Task
I import the Test class like this:
import org.gradle.api.tasks.testing.Test;
Gradle version: 6.7.1
IntelliJ: 2020.2.3
I spent some (a lot of) time googling this. Eventually I found a comment somewhere saying that one could try to use the internal SDK (jbr) that ships with IntelliJ instead of a manually downloaded SDK. That made it work. The internal SDK is Java 11 and I've also installed the latest version of Java 11 from Oracle. Even though they are both Java 11, the internal SDK (jbr) is working as it should, but not the external SDK. For other projects the external SDK is working fine, but not for building a Gradle plugin.
unable to resolve class org.codehaus.groovy.grails.web.servlet.mvc.GrailsParameterMap
# line 4, column 1.
import org.codehaus.groovy.grails.web.servlet.mvc.GrailsParameterMap
This happened when I upgraded grails from 2.2.4 to 3.1.3.
Is there some new place I need to import this too? Or is there a dependency I need to add to my gradle build file?
See step 5 on this page, https://docs.grails.org/3.0.x/guide/upgrading.html
Step 5 - Modify Package Imports In Grails 3.x all internal APIs can be
found in the org.grails package and public facing APIs in the grails
package. The org.codehaus.groovy.grails package no longer exists.
All package declaration in sources should be modified for the new
location of the respective classes. Example
org.codehaus.groovy.grails.commons.GrailsApplication is now
grails.core.GrailsApplication.
I have maven project where i am adding the dependencies which are not resolvable as below.
My servlet is as follows:
LocaleUtil is getting resolve but its sub packages are throwing error when including.
I have tried invalidate cache and restart. But this didn't work for me.
Thanks,
The packages you are trying to import are internal, non-exported packages of the bundle com.adobe.granite.i18n. In fact, that bundle only exports the following packages:
Export-Package
com.adobe.granite.i18n {version=1.0, imported-as=[1.0.0,1.1)}
com.day.cq.i18n {version=5.4.0}
You should not attempt to use private packages of a library. Limit yourself to using only the exported API.
We're running eXist-db version 3.0 and want to try running XProc within it.
We found that the XProcxq Module is now part of eXist: http://exist-db.org/exist/apps/doc/extensions.xml#module_xprocxq
However, in attempting to use it we get the error below and wondered if anyone had suggestions for where we could be going wrong?
As specified at the top of the module page linked to, we added the module to the conf.xml file and restarted eXist. (This could be where we went wrong, but that's a guess on our part)
This is what the module we added looks like in conf.xml:
<module uri="http://xproc.net/xproc" class="org.exist.xquery.modules.xprocxq.XProcxq/>
Here is the simple started XQuery I've attempted to use:
xquery version "1.0" encoding "UTF-8";
import module namespace const = "http://xproc.net/xproc/const";
import module namespace xproc = "http://xproc.net/xproc";
import module namespace u = "http://xproc.net/xproc/util";
declare variable $local:XPROCXQ_EXAMPLES := "/db/examples"; (:CHANGE ME:)
let $stdin :=document{<test>Hello World</test>}
let $pipeline :=document{
<p:pipeline name="pipeline"
xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step">
<p:identity/>
</p:pipeline>
}
return
xproc:run($pipeline,$stdin)
Here is the error:
error found while loading module xproc: IO exception while loading module 'http://xproc.net/xproc' from 'http://xproc.net/xproc'
I posed your question to the exist-open mailing list (where I'd encourage you to join for future eXist-db questions), and it appears XProc support in eXist is currently between a rock and a hard place. The xprocxq library you mentioned is woefully underdeveloped (abandoned by its original creator), and the much better developed Calabash module is incompatible with the current version of Saxon used in eXist, due to a dependency on that version of Saxon. I'd welcome you to join exist-open to discuss further. Perhaps there's some other workaround for you.
It needs to be rebuilt.
According to http://exist-db.org/exist/apps/wiki/blogs/eXist/eXist30RC1
EXPath packages that incorporate Java libraries may no longer work with eXist 3.0 and may need to be recompiled for our API changes; packages should now explicitly specify the eXist versions that they are compatible with.
I am working on the update to the XProc EXPath module.
The XMLCalabash module for eXist has now been rebuilt for a newer version of eXist and Calabash and should work with eXist 3.0.RC1.
To build your own Jar package for eXist 3.0.RC1 run:
$ git clone https://github.com/eXist-db/eXist-XMLCalabash.git
$ cd eXist-XMLCalabash
$ rm -rf src/test
$ mvn package
The Jar is then in the target/ folder. You should copy it to $EXIST_HOME/lib/user modify $EXIST_HOME/conf.xml to load the module and then restart eXist.
Updated
The XML Calabash module for eXist, now also has a PR so that it will support the upcoming eXist 3.0.RC2 -
https://github.com/eXist-db/eXist-XMLCalabash/pull/2
However you cannot built it remotely until eXist 3.0.RC2 is released.
In my project, I am getting package uses conflict with spring bundles. I used the techniques given in this link
http://njbartlett.name/2011/09/02/uses-constraints.html
I am getting package uses conflict for this:
initial#reference:file:../../../my_project_maven/my_project/myproject-core/ [2158]
Package uses conflict: Import-Package:org.springframework.orm.jpa.vendor; version="2.5.6"
I seached for bundles exporting org.springframework.orm.jpa.vendor; version="2.5.6" and found this:
osgi> p org.springframework.orm.jpa.vendor
org.springframework.orm.jpa.vendor; version="2.5.6"<org.springframework_2.5.6 [2201]>
osgi>
So I opened up the springframework jar and saw the uses for the exported package and found these
javax.persistence,
javax.persistence.spi,
oracle.toplink.essentials.sessions,
org.apache.openjpa.persistence,
org.eclipse.persistence.sessions,
org.hibernate,
org.springframework.dao,
org.springframework.jdbc.datasource,
org.springframework.orm.jpa,
org.springframework.transaction
Out of the above, the only ones that my core bundle is importing are
javax.persistence;version="1.0.0"
org.springframework.dao;version="2.5.6"
org.springframework.orm.jpa;version="2.5.6"
Springframework is importing javax.persistence version of 1.0.0 and my core bundle is also importing 1.0.0 so there are no version conflicts there. Also these imports
org.springframework.dao;version="2.5.6"
org.springframework.orm.jpa;version="2.5.6"
are exports from springframework bundle, so no version conflicts there too.
There are no version conflicts in the org.springframework.orm.jpa.vendor package uses and the imports in my core bundle. I do not understand what is causing this package uses conflict. Is there an easy way of debugging these?