Comments (20)
Have you redeployed carte-util 3.5.1 too?
Redeployed everything with a "3.5.1".
from css4j-dom4j.
Hi Vincent,
Thanks for reporting. Yes it is a bug, I assumed that Gradle would configure 'implementation' dependencies (which are not transitive in Gradle) as optional Maven dependencies when declaring the POM, but that is not the case. Incidentally, it is similar to a bug that dom4j 2.1.3 has.
I'm preparing a 3.5.1 which should fix the problem.
Note that there doesn't seem to be an official xpp3 1.2.0 release so we're a bit hesitant to upgrade. In addition so far we've not bundled xpp3 at all in our XWiki WAR and we prefer to avoid that as much as possible, if possible.
The dependency comes from here:
https://github.com/xmlpull-xpp3/xmlpull-xpp3
although the old and "official" project would be this one:
which has been inactive for years.
If you ever modularize XWiki you are going to need 1.2.0, in any case I agree about avoiding to bundle it.
from css4j-dom4j.
I just deployed css4j 3.5.1 to the Maven repository. Does it solve the issue?
from css4j-dom4j.
Forgot to mention: now the xml-dtd
artifact is a separate project with a separate release cycle (and version). So your:
<dependency>
<groupId>io.sf.carte</groupId>
<artifactId>xml-dtd</artifactId>
<version>${css4j.version}</version>
</dependency>
now should be something like:
<dependency>
<groupId>io.sf.carte</groupId>
<artifactId>xml-dtd</artifactId>
<version>3.5.1</version>
</dependency>
or
<dependency>
<groupId>io.sf.carte</groupId>
<artifactId>xml-dtd</artifactId>
<version>${xmlDtd.version}</version>
</dependency>
from css4j-dom4j.
Thanks!
Would be nice that the dep to carte-util
in xml-dtd
3.5.1 be aligned with the one from css4j
:
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-upper-bounds) @ xwiki-platform-oldcore ---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireUpperBoundDeps failed with message:
Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for io.sf.carte:carte-util:3.4.0 paths to dependency are:
+-org.xwiki.platform:xwiki-platform-oldcore:13.5-SNAPSHOT
+-io.sf.carte:xml-dtd:3.5.1
+-io.sf.carte:carte-util:3.4.0
and
+-org.xwiki.platform:xwiki-platform-oldcore:13.5-SNAPSHOT
+-io.sf.carte:css4j-dom4j:3.5.1
+-io.sf.carte:css4j:3.5.1
+-io.sf.carte:carte-util:3.5.1
I know you said they have a different release cycle but is that really necessary? what's the problem of releasing it together and thus testing and ensuring that they all work together (including for this type of problem above), even if there's been no changes to xml-dtd
?
Anyway I'll need to add some exclude but it makes it just a bit more complex to use CSS4J/XDML DTD :)
Thanks again.
from css4j-dom4j.
@carlosame hmm is it possible that you build with a target of java 11?
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project xwiki-platform-oldcore: Compilation failure: Compilation failure:
[ERROR] /Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java:[74,29] cannot access io.sf.carte.doc.dom4j.CSSStylableElement
[ERROR] bad class file: /Users/vmassol/.m2/repository/io/sf/carte/css4j-dom4j/3.5.1/css4j-dom4j-3.5.1.jar(io/sf/carte/doc/dom4j/CSSStylableElement.class)
[ERROR] class file has wrong version 55.0, should be 52.0
[ERROR] Please remove or make sure it appears in the correct subdirectory of the classpath.
^^this is what I get with java 8 now.
from css4j-dom4j.
Would be nice that the dep to carte-util in xml-dtd 3.5.1 be aligned with the one from css4j:
Any recent version of carte-util can be used with xml-dtd. I had to put 3.4.0 because I had a bit of a chicken-and-egg problem with it :-)
is it possible that you build with a target of java 11?
Weird. I'm compiling for mixedJavaRelease 8
, compliling module-info
with Java 11 and the rest with 8, and it gives no error nor warnings about that. I'll investigate.
from css4j-dom4j.
At this point I have filed three issues and two pull requests at a Gradle plugin project, the problem may be fixed at some point but a serious regression about a new release cannot wait until that.
So I have reverted the removal of the Maven build and deployed 3.5.1 with Maven. That should fix this issue, please let me know if that is not the case.
And the carte-util
dependency is now a range, following my own advice that I initially missed. You do not need that dependency exclusion anymore.
When the next css4j version is released, the Gradle build shall have another opportunity —hopefully.
from css4j-dom4j.
Thanks a lot @carlosame . Trying now. Small note that it's best to release a new version instead of overwriting one (checksum validation may fail, local maven repo may fail, cached artifacts in IDE may fail, etc)... :)
from css4j-dom4j.
And the carte-util dependency is now a range, following my own advice that I initially missed. You do not need that dependency exclusion anymore.
Doesn't seem to work, I get the following:
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireUpperBoundDeps failed with message:
Failed while enforcing RequireUpperBoundDeps. The error(s) are [
Require upper bound dependencies error for io.sf.carte:carte-util:3.4.0 paths to dependency are:
+-org.xwiki.platform:xwiki-platform-oldcore:13.5-SNAPSHOT
+-io.sf.carte:xml-dtd:3.5.1
+-io.sf.carte:carte-util:3.4.0
and
+-org.xwiki.platform:xwiki-platform-oldcore:13.5-SNAPSHOT
+-io.sf.carte:css4j-dom4j:3.5.1
+-io.sf.carte:css4j:3.5.1
+-io.sf.carte:carte-util:3.5.1
]
After removing the exclusions part in:
<dependency>
<groupId>io.sf.carte</groupId>
<artifactId>xml-dtd</artifactId>
<!-- Note: has a different release cycle than CSS4J -->
<version>3.5.1</version>
<exclusions>
<!-- We're using a more recent version pulled from css4j -->
<exclusion>
<groupId>io.sf.carte</groupId>
<artifactId>carte-util</artifactId>
</exclusion>
</exclusions>
</dependency>
Thanks
from css4j-dom4j.
hmm I still get:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project xwiki-platform-oldcore: Compilation failure: Compilation failure:
[ERROR] /Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java:[74,29] cannot access io.sf.carte.doc.dom4j.CSSStylableElement
[ERROR] bad class file: /Users/vmassol/.m2/repository/io/sf/carte/css4j-dom4j/3.5.1/css4j-dom4j-3.5.1.jar(io/sf/carte/doc/dom4j/CSSStylableElement.class)
[ERROR] class file has wrong version 55.0, should be 52.0
[ERROR] Please remove or make sure it appears in the correct subdirectory of the classpath.
[ERROR] /Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/store/StoreConfiguration.java:[59,39] cannot find symbol
[ERROR] symbol: variable ROLEHINT
[ERROR] location: class com.xpn.xwiki.internal.XWikiCfgConfigurationSource
[ERROR] /Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/store/hibernate/HibernateConfiguration.java:[46,39] cannot find symbol
[ERROR] symbol: variable ROLEHINT
[ERROR] location: class com.xpn.xwiki.internal.XWikiCfgConfigurationSource
[ERROR] /Users/vmassol/dev/xwiki/xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/internal/XWikiCfgConfigurationSource.java:[52,35] cannot find symbol
[ERROR] symbol: variable ROLEHINT
[ERROR] location: class com.xpn.xwiki.internal.XWikiCfgConfigurationSource
Note that I've removed all my local maven repo files for ~/.m2/repository/io/sf/carte
from css4j-dom4j.
it's best to release a new version instead of overwriting one
Yes but I still hadn't tagged 3.5.1, nor released any other binaries...
Require upper bound dependencies error for io.sf.carte:carte-util:3.4.0 paths to dependency are:
Forgot that xml-dtd
3.5.1 is now independent and has the 3.4.0 dependency. Trying to do too many things too fast.
[ERROR] class file has wrong version 55.0, should be 52.0
Seems a redeployment shenanigan.
$ pwd
/***/css4j-3.5.1/css4j-dom4j/build/bin/io/sf/carte/doc/dom4j
$ javap -verbose CSSStylableElement.class|grep major
major version: 52
This weekend I plan to resume work on the thing, and perhaps the real fix would be a 3.5.2 once I can roll out my own fix for the Gradle build. Sigh.
from css4j-dom4j.
Seems a redeployment shenanigan.
Yes this was my fear. Since I removed my local maven repo, I believe the issue is on our nexus instance which cached it... This is why you should never re-release the same version with different code ;) I'll try to clear that cache.
from css4j-dom4j.
I'll try to clear that cache.
I've now cleared all caches I could think of and I get:
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.344 s <<< FAILURE! - in com.xpn.xwiki.pdf.impl.PdfExportImplTest
[ERROR] applyCSSWhenExistingStyleDefinedUsingShorthandNotation Time elapsed: 0.344 s <<< ERROR!
java.lang.UnsupportedClassVersionError: io/sf/carte/util/SimpleWriter has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at io.sf.carte.doc.dom4j.XHTMLDocumentFactory$DOM4JCSSStyleSheetFactory.createDocumentStyleSheet(XHTMLDocumentFactory.java:321)
at io.sf.carte.doc.dom4j.XHTMLDocumentFactory$DOM4JCSSStyleSheetFactory.getUserAgentStyleSheet(XHTMLDocumentFactory.java:482)
at io.sf.carte.doc.dom4j.XHTMLDocumentFactory$DOM4JCSSStyleSheetFactory.mergeUserSheets(XHTMLDocumentFactory.java:508)
at io.sf.carte.doc.dom4j.XHTMLDocumentFactory$DOM4JCSSStyleSheetFactory.getDefaultStyleSheet(XHTMLDocumentFactory.java:496)
at io.sf.carte.doc.dom4j.XHTMLDocumentFactory.getDefaultStyleSheet(XHTMLDocumentFactory.java:105)
at io.sf.carte.doc.dom4j.XHTMLDocument.mergeStyleSheets(XHTMLDocument.java:252)
at io.sf.carte.doc.dom4j.XHTMLDocument.getStyleSheet(XHTMLDocument.java:245)
at io.sf.carte.doc.dom4j.XHTMLDocument.addStyleSheet(XHTMLDocument.java:311)
at com.xpn.xwiki.pdf.impl.PdfExportImpl.applyCSS(PdfExportImpl.java:351)
Have you redeployed carte-util
3.5.1 too?
from css4j-dom4j.
Redeployed everything with a "3.5.1".
Thanks it works now!
from css4j-dom4j.
Thank you for your patience, Vincent!
from css4j-dom4j.
No problem and thanks again for your fast answer and fix (as always)!
from css4j-dom4j.
Today I managed to fix the Gradle build (even published a gist about it because I haven't spotted anything close out there), then found out something: when I redeployed 3.5.1 I did it with Maven, but Maven generated its *.pom
files and ignored the Gradle metadata files (which were already there at the repository from the previous deployment).
As a result, 3.5.1 still publishes the old (and wrong) Gradle metadata. That's not a problem affecting the full XWiki build (which uses Maven), but if somebody uses xwiki-platform
as a library in a separate Gradle project, that one is going to break badly.
So I'm preparing a release (and deployment) of all the involved artifacts (css4j-*, xml-dtd and carte-util), now with version 3.5.2.
Sorry for the noise, this migration to Gradle has been more difficult (and with more gotchas) than I anticipated.
from css4j-dom4j.
I'm preparing a release (and deployment) of all the involved artifacts
Turns out only css4j is affected, xml-dtd and carte-util are fine.
from css4j-dom4j.
css4j 3.5.2 is out. I took the time to verify both the Maven and Gradle metadata and everything seems fine.
from css4j-dom4j.
Related Issues (2)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from css4j-dom4j.