Jigsaw / multi module / dependencies

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Jigsaw / multi module / dependencies

kiwiwings
Hi,

I'm currently reworking our dependencies and try to provide multi module [1] jars.

Currently I have the following:

- multi module xml schemas - the merged and lite schema is tbd

- removed the jaxb dependencies from the main module and provided my own XMLStreamReader based parser for PresetGeometries. The reason for this is, that JDK 11 dropped the JAXB support - now you have some com.sun or org.glassfish dependencies to choose from. Instead of increasing our dependencies even more, I think it makes more sense to provide some custom parser. This also renders the binding classes obsolete.

I'd like to also provide a multi module XmlBeans - maybe this fixes also a problem with opening the xml schemas to all.

I would mark the optional dependencies as static [2] - e.g. bouncycastle, batik ...

So the next release would contain ...
- new XmlBeans release
- new POi jars
- new ooxml-schema, ooxml-security

What I'm not so sure about is the effect on the user base, when suddenly the jars are multi module and the current automatic name (e.g. "poi") is overridden by a customized one (e.g. org.apache.poi.poi). This is a change we would face anyway - even if we would go with just providing an automatic name manifest entry.

What are your thoughts generally and about semantic versioning in this regards?

Andi

[1] https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/
[2] https://blog.codefx.org/java/module-system-optional-dependencies/



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

PJ Fanning
Thanks Andi,

Seems like the right way to go.

I'd like to see us update to XMLBeans 4 and POI 5 if the changes mean there is a user impact.

We could release XMLBeans 3 and POI 4 bug fix releases if the changes take a while to complete and test.






On Tuesday 5 May 2020, 12:44:35 GMT+2, Andreas Beeker <[hidden email]> wrote:





Hi,

I'm currently reworking our dependencies and try to provide multi module [1] jars.

Currently I have the following:

- multi module xml schemas - the merged and lite schema is tbd

- removed the jaxb dependencies from the main module and provided my own XMLStreamReader based parser for PresetGeometries. The reason for this is, that JDK 11 dropped the JAXB support - now you have some com.sun or org.glassfish dependencies to choose from. Instead of increasing our dependencies even more, I think it makes more sense to provide some custom parser. This also renders the binding classes obsolete.

I'd like to also provide a multi module XmlBeans - maybe this fixes also a problem with opening the xml schemas to all.

I would mark the optional dependencies as static [2] - e.g. bouncycastle, batik ...

So the next release would contain ...
- new XmlBeans release
- new POi jars
- new ooxml-schema, ooxml-security

What I'm not so sure about is the effect on the user base, when suddenly the jars are multi module and the current automatic name (e.g. "poi") is overridden by a customized one (e.g. org.apache.poi.poi). This is a change we would face anyway - even if we would go with just providing an automatic name manifest entry.

What are your thoughts generally and about semantic versioning in this regards?

Andi

[1] https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/
[2] https://blog.codefx.org/java/module-system-optional-dependencies/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

Axel Howind
In reply to this post by kiwiwings
Hi Andy,

That’s great news!

I think changing the module names makes this is breaking change, so will the release containing these changes be version 5.0 or a 4.x? I think I would go for 5.0 on the assumption that module and package names will stay stable for the foreseeable future.

But I think it is something that has to be done anyway to achieve compatibility with jlink, That would IMHO be a great step forward - currently I have to apply crude workarounds to get blink work with POI, and I think many are facing the same problems or just decided to not use jlink for the time being with projects using POI.

Another question: AFAIK some of the dependencies used by POI are not yet modularised. As you mentioned it, I think Batik is an example (unless this has changed since I last used it). As I am quite busy with my day job, I cannot put much effort into POI at the moment, but I might find some time to create patches (and PRs)  to some of the dependencies to make them modularized.

Axel


> Am 05.05.2020 um 12:44 schrieb Andreas Beeker <[hidden email]>:
>
> Hi,
>
> I'm currently reworking our dependencies and try to provide multi module [1] jars.
>
> Currently I have the following:
>
> - multi module xml schemas - the merged and lite schema is tbd
>
> - removed the jaxb dependencies from the main module and provided my own XMLStreamReader based parser for PresetGeometries. The reason for this is, that JDK 11 dropped the JAXB support - now you have some com.sun or org.glassfish dependencies to choose from. Instead of increasing our dependencies even more, I think it makes more sense to provide some custom parser. This also renders the binding classes obsolete.
>
> I'd like to also provide a multi module XmlBeans - maybe this fixes also a problem with opening the xml schemas to all.
>
> I would mark the optional dependencies as static [2] - e.g. bouncycastle, batik ...
>
> So the next release would contain ...
> - new XmlBeans release
> - new POi jars
> - new ooxml-schema, ooxml-security
>
> What I'm not so sure about is the effect on the user base, when suddenly the jars are multi module and the current automatic name (e.g. "poi") is overridden by a customized one (e.g. org.apache.poi.poi). This is a change we would face anyway - even if we would go with just providing an automatic name manifest entry.
>
> What are your thoughts generally and about semantic versioning in this regards?
>
> Andi
>
> [1] https://blog.codefx.org/tools/multi-release-jars-multiple-java-versions/
> [2] https://blog.codefx.org/java/module-system-optional-dependencies/
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

kiwiwings

Hi,

I think its OK to commit it now and release the next major version for POI / XmlBeans when we are ready with trunk.
When one of our remaining non-jigsaw dependencies switches we have to adapt, but I don't think we need to push that.

What bugs me a bit is the way our modules (main, scratchpad, ooxml) are tailored - but we've already discussed this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62355
http://apache-poi.1045710.n5.nabble.com/Single-Java-9-module-jar-td5730294.html
http://apache-poi.1045710.n5.nabble.com/Apache-POI-and-Maven-modules-mavenization-td5713558.html#a5713579
http://apache-poi.1045710.n5.nabble.com/Review-62355-td5730687.html#a5730762

Opposed to what I've said/planned in #62355, I think now, we should move to multi release module and keeping the module tailoring in POI 5.0.0. For POI 6.0.0 we might think of a different module layout.

WRT the dependencies, I would prefer to have strong dependencies opposed to static ones - and maybe a less amount for each module.
Instead of forcing the user to provide the whole lot, I rather would like to split certain features in its own modules, e.g. document signing and SVG rendering.

WRT the build, as our build is still JDK 8 based, I need to provide module-info.class files in our source.

Maybe we can rebase the build to JDK 9+ and use the "--release 8" option in javac instead ...
Maybe we could change our jenkins strategy to
* release on the latest stable JDK
* build / test on JDK 8
* integration test on JDK 8 with the binaries of the latest stable

This would have the benefit, that providing JDK release/version specific fixes wouldn't be a hassle.

I'll push my changes now in - as most of the code isn't affected (... yet).

Andi


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

Dominik Stadler
Hi,

Thanks for the work, good to progress towards that!

I would like to see a version 4.1.3 as there were some important
regressions fixed since 4.1.2. We can technically release from a branch,
right? I don't remember us doing it until now...

Thanks... Dominik.
Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

kiwiwings
Hi,

I haven't yet committed too much, which can't be reverted again.
Currently the trunk builds ok in the Ant build, but I regard it as unstable, because there are some smaller things to change in POI and some bigger changes to XmlBeans as far as I can see now.
If we want to push out a 4.1.3, I should comment out at least the multi release stuff in the build.xml - then it shouldn't be necessary to release from a branch.

In XmlBeans I try to use the JavaParser (https://javaparser.org/) as the JAM library is more than outdated and the Doclet API not accessible anymore. I have an orphaned branch (https://svn.apache.org/repos/asf/xmlbeans/branches/xmlbeans-536) where I've tried to make the XmlBeans file JDK9+ compatible ... but I left it unfinished, after some tests didn't succeed and I didn't find out (or lost joy in finding out ...) on how to fix it. So WRT JigSaw compatibility, there seems a lot to do in XmlBeans :(

Another concern is, how we cope with unstable module info in POI 5 / XmlBeans 4 - I think it will take at least another release until our external dependencies and our internal package names will be JigSaw ready.

Andi



On 07.05.20 15:14, Dominik Stadler wrote:

> Hi,
>
> Thanks for the work, good to progress towards that!
>
> I would like to see a version 4.1.3 as there were some important
> regressions fixed since 4.1.2. We can technically release from a branch,
> right? I don't remember us doing it until now...
>
> Thanks... Dominik.
>


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

kiwiwings
Hi devs,

I finally pull myself together and have a working version of XmlBeans and POI with the xmlschema files moved away from schemaorg_apache_xmlbeans to module specific directories like org.apache.xmlbeans.metadata for the internal XmlBeans schemas and org.apache.poi.schemas.ooxml / .security for POIs schemas.

Although both tests (ant test test-integration) are green, I think my version of XmlBeans is not downward compatible, i.e. you have to compile the schemas again.
Also the POI schemas use a trick for moving the files to the correct package.

*Is there someone who I can pair up, before I commit the changes?*

Open to-dos are the lite-schema and providing / testing for multi-release functionality.

Andi



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jigsaw / multi module / dependencies

fanningpj@apache.org
Hi Andi,

I might have time to pair with you. Email me if you want to arrange a time.

Regards,
PJ






On Friday 19 June 2020, 18:20:40 GMT+2, Andreas Beeker <[hidden email]> wrote:





Hi devs,

I finally pull myself together and have a working version of XmlBeans and POI with the xmlschema files moved away from schemaorg_apache_xmlbeans to module specific directories like org.apache.xmlbeans.metadata for the internal XmlBeans schemas and org.apache.poi.schemas.ooxml / .security for POIs schemas.

Although both tests (ant test test-integration) are green, I think my version of XmlBeans is not downward compatible, i.e. you have to compile the schemas again.
Also the POI schemas use a trick for moving the files to the correct package.

*Is there someone who I can pair up, before I commit the changes?*

Open to-dos are the lite-schema and providing / testing for multi-release functionality.


Andi


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]