Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support.
We're experimenting with it now under Java 11 (since only 8 and 11 have long-term-support). We're finding that we must use java modules (module-info.java) in order to compile, due to issues with the java.xml packages that we use. (Long story.) Has anyone done this (i.e., use java modules) successfully with Tapestry 5.5? I keep getting errors like: error: the unnamed module reads package org.apache.tapestry5.internal.beaneditor from both tapestry.core and beanmodel ...which suggests that the Tapestry jars may have 'split packages', i.e. the same package name in different jars. We're still learning the ins-and-outs of Java Modularity, so it may simply be my confusion. But any thoughts are most welcome! One possible (crude) workaround may be to merge the tapestry jars into a new (single) jar, and treat that as a single "automatic module". I'll try that if nothing else works, and report back. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Fri, Nov 8, 2019 at 8:03 PM Charles Roth <[hidden email]> wrote:
Hello! Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support. > Our pleasure! One nitpick: it has support for Java 9, 10 and 11 bytecode. Tapestry itself wasn't modularized yet. > Has anyone done this (i.e., use java modules) successfully with Tapestry > 5.5? I keep getting errors like: > > error: the unnamed module reads package > org.apache.tapestry5.internal.beaneditor from both tapestry.core and > beanmodel > Did you try making modules out of Tapestry JARs? I'd guess that wouldn't work. > ...which suggests that the Tapestry jars may have 'split packages', i.e. > the same package name in different jars. > Yes, this is a situation which happens now and will need to be addressed when Tapestry itself is modularized. > We're still learning the ins-and-outs of Java Modularity, so it may > simply be my confusion. But any thoughts are most welcome! > > One possible (crude) workaround may be to merge the tapestry jars into a > new (single) jar, and treat that as a single "automatic module". I'll > try that if nothing else works, and report back. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Thiago |
Hmm, thanks for the quick response.
It looks like I will have to try the unpack-all-the-tapestry-jars and pack-them-into-a-single-jar as an "automatic module", after all. I will report back if that is successful. (This is partly caused by another conflict in our project, with javax.xml, that is forcing us to use modules. Many people may be able to use Tapestry as-is by telling their build process to ignore the module rules.) On 11/12/2019 5:42 PM, Thiago H. de Paula Figueiredo wrote: > On Fri, Nov 8, 2019 at 8:03 PM Charles Roth <[hidden email]> wrote: > > Hello! > > Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support. > Our pleasure! > > One nitpick: it has support for Java 9, 10 and 11 bytecode. Tapestry itself > wasn't modularized yet. > > >> Has anyone done this (i.e., use java modules) successfully with Tapestry >> 5.5? I keep getting errors like: >> >> error: the unnamed module reads package >> org.apache.tapestry5.internal.beaneditor from both tapestry.core and >> beanmodel >> > Did you try making modules out of Tapestry JARs? I'd guess that wouldn't > work. > > >> ...which suggests that the Tapestry jars may have 'split packages', i.e. >> the same package name in different jars. >> > Yes, this is a situation which happens now and will need to be addressed > when Tapestry itself is modularized. > > >> We're still learning the ins-and-outs of Java Modularity, so it may >> simply be my confusion. But any thoughts are most welcome! >> >> One possible (crude) workaround may be to merge the tapestry jars into a >> new (single) jar, and treat that as a single "automatic module". I'll >> try that if nothing else works, and report back. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Tue, Nov 12, 2019 at 8:36 PM Charles Roth <[hidden email]> wrote:
> Hmm, thanks for the quick response. > We strive to please! :D > It looks like I will have to try the unpack-all-the-tapestry-jars and > pack-them-into-a-single-jar as an "automatic module", after all. > > I will report back if that is successful. > > (This is partly caused by another conflict in our project, with > javax.xml, that is forcing us to use modules. Many people may be able > to use Tapestry as-is by telling their build process to ignore the > module rules.) > I haven't really worked with Java 9+ modules yet, but couldn't you have the non-modularized Tapestry JARs in the classpath instead of the modulepath? > > On 11/12/2019 5:42 PM, Thiago H. de Paula Figueiredo wrote: > > On Fri, Nov 8, 2019 at 8:03 PM Charles Roth <[hidden email]> wrote: > > > > Hello! > > > > Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support. > > Our pleasure! > > > > One nitpick: it has support for Java 9, 10 and 11 bytecode. Tapestry > itself > > wasn't modularized yet. > > > > > >> Has anyone done this (i.e., use java modules) successfully with Tapestry > >> 5.5? I keep getting errors like: > >> > >> error: the unnamed module reads package > >> org.apache.tapestry5.internal.beaneditor from both tapestry.core and > >> beanmodel > >> > > Did you try making modules out of Tapestry JARs? I'd guess that wouldn't > > work. > > > > > >> ...which suggests that the Tapestry jars may have 'split packages', i.e. > >> the same package name in different jars. > >> > > Yes, this is a situation which happens now and will need to be addressed > > when Tapestry itself is modularized. > > > > > >> We're still learning the ins-and-outs of Java Modularity, so it may > >> simply be my confusion. But any thoughts are most welcome! > >> > >> One possible (crude) workaround may be to merge the tapestry jars into a > >> new (single) jar, and treat that as a single "automatic module". I'll > >> try that if nothing else works, and report back. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > >> For additional commands, e-mail: [hidden email] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Thiago |
In reply to this post by croth
Hello, Charles!
TAP5-2641 is taking care of fixing the split packages problem, plus setting automatic module names for all the Tapestry JARs ("org.apache.tapestry" + project name, except for tapestry5-annotations, which will be org.apache.tapestry-annotations'). Lots of classes needed to be moved around, but I'll try to provide a tool to rewrite imports to alleviate the problem. On Fri, Nov 8, 2019 at 7:03 PM Charles Roth <[hidden email]> wrote: > Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support. > We're experimenting with it now under Java 11 (since only 8 and 11 have > long-term-support). > > We're finding that we must use java modules (module-info.java) in order > to compile, due to issues with the java.xml packages that we use. (Long > story.) > > Has anyone done this (i.e., use java modules) successfully with Tapestry > 5.5? I keep getting errors like: > > error: the unnamed module reads package > org.apache.tapestry5.internal.beaneditor from both tapestry.core and > beanmodel > > ...which suggests that the Tapestry jars may have 'split packages', i.e. > the same package name in different jars. > > We're still learning the ins-and-outs of Java Modularity, so it may > simply be my confusion. But any thoughts are most welcome! > > One possible (crude) workaround may be to merge the tapestry jars into a > new (single) jar, and treat that as a single "automatic module". I'll > try that if nothing else works, and report back. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > -- Thiago |
Thank you! On 10/3/2020 4:29 PM, Thiago H. de
Paula Figueiredo wrote:
Hello, Charles! TAP5-2641 is taking care of fixing the split packages problem, plus setting automatic module names for all the Tapestry JARs ("org.apache.tapestry" + project name, except for tapestry5-annotations, which will be org.apache.tapestry-annotations'). Lots of classes needed to be moved around, but I'll try to provide a tool to rewrite imports to alleviate the problem. On Fri, Nov 8, 2019 at 7:03 PM Charles Roth [hidden email] wrote:Thanks for announcing the Tapestry 5.5 beta, with Java 9+ support. We're experimenting with it now under Java 11 (since only 8 and 11 have long-term-support). We're finding that we must use java modules (module-info.java) in order to compile, due to issues with the java.xml packages that we use. (Long story.) Has anyone done this (i.e., use java modules) successfully with Tapestry 5.5? I keep getting errors like: error: the unnamed module reads package org.apache.tapestry5.internal.beaneditor from both tapestry.core and beanmodel ...which suggests that the Tapestry jars may have 'split packages', i.e. the same package name in different jars. We're still learning the ins-and-outs of Java Modularity, so it may simply be my confusion. But any thoughts are most welcome! One possible (crude) workaround may be to merge the tapestry jars into a new (single) jar, and treat that as a single "automatic module". I'll try that if nothing else works, and report back. --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] --
|
Free forum by Nabble | Edit this page |