Tapestry 5.5 beta and Java Modularity

[croth]

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 H de Paula Figueiredo]

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

[croth]

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]

[Thiago H de Paula Figueiredo]

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

[Thiago H de Paula Figueiredo]

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

[croth]

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]