Re: Drop module-info from tomcat*.jar?

[Romain Manni-Bucau]

Le mer. 15 sept. 2021 à 13:13, Mark Thomas  a écrit :

> On 15/09/2021 11:07, Romain Manni-Bucau wrote:
> > I think the last option is maybe the target: modularize tomcat properly.
>
> "Properly" is a highly subjective judgement. There are going to be
> wildly differing views on what constitutes a "proper" degree of modularity.
>

Ok, "properly" regarding the dependency graph, ie no reflection done nor
code relying on an optional dependency (all that replaced by a SPI or
alike).


>
> > The people willing to have as few as possible modules would just use a
> new
> > "bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
> > which provides a bundle way of building apps but is not flexible.
> > So regarding JPMS I think it is either being really modular or not being
> > modular since the in between state leads to unsatisfied people and the
> > biggest constraints come from JPMS.
> > Is it something targettable or do you think it is too much work?
>
> Don't know until we try.
>
> My instinct is that making more modules optional and then logging
> warnings if users try to use Tomcat features that depend on a missing
> optional module is doable - but I haven't done any analysis to back that
> up.
>
> I don't have a sense of how many more modules like SSI could be
> realistically created.
>
> Broadly, embedded is going to be the "bundle" module (well, modules) and
> if folks want a finer-grained selection then they can use the JARs from
> the standard distribution.
>

To be honest I never understood why the org.apache.tomcat.embed artifacts,
they are generally the same as org.apache.tomcat ones and embedded server
works very well with org.apache.tomcat artifacts so can be good to drop
embed groupId and replace it by an all in one? Still thinking out loud
indeed but current modularisation is surprising for consumers ;).


>
> Mark
>
>
> >
> > side note: fine for me if it targets only 10.1.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :
> >
> >> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> >>> Hi all,
> >>>
> >>> I was trying to strim down a JDK, all was smooth until I started to
> work
> >>> with Tomcat.
> >>
> >> I am assuming this is with embedded.
> >>
> >>> The issues I hit:
> >>>
> >>> - Tomcat is designed to be fully used with JPMS whereas I would like to
> >> be
> >>> able to use it in the CP if a jlink custom distro (without
> >> forking/patching
> >>> tomcat jar indeed)
> >>> - module-info use "requires" and no optional dependent modules which
> lead
> >>> to way too much dependencies (open the module-info from tomcat-catalina
> >> for
> >>> ex)
> >>>
> >>> Indeed there are always workaround and way to achieve what I wanted
> but I
> >>> think the JPMS deliveries of Tomat are not friendly so think it is
> worth
> >>> thinking about:
> >>>
> >>> 1. dropping it
> >>
> >> Not an option as we have users that have requested it.
> >>
> >>> 2. making it optional (I assume it can be released in jars with
> >> classifiers
> >>> only)
> >>
> >> Maybe, but it adds a bunch of artefacts.
> >>
> >>> 3. making it more accurate - but this highly depends how the user
> >> consumes
> >>> it (in particular for tomcat embed flavor)
> >>
> >> I think a variation of this is the way to go.
> >>
> >> Looking at the list of dependencies, I suspect most of them can be made
> >> optional. That involves fine-tuning the bnd configuration files.
> >>
> >> That does raise the question what we do when a user tries to use the
> >> optional features. I think we need to:
> >> - identify those Tomcat features that depend on optional modules
> >> - add a check for the presence of the module before using the feature
> >> and log an appropriate error message if the module is missing.
> >>
> >> Splitting embedded into lots of little modules where all the
> >> dependencies are correctly declared is another solution but we have
> >> users that have requested we provide Tomcat in as few JARs as possible.
> >>
> >> I think we are approaching "can't please all of the people, all of the
> >> time" territory here.
> >>
> >> Mark
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Drop module-info from tomcat*.jar?

[Mark Thomas]

On 15/09/2021 11:07, Romain Manni-Bucau wrote:

I think the last option is maybe the target: modularize tomcat properly.


"Properly" is a highly subjective judgement. There are going to be 
wildly differing views on what constitutes a "proper" degree of modularity.



The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?


Don't know until we try.

My instinct is that making more modules optional and then logging 
warnings if users try to use Tomcat features that depend on a missing 
optional module is doable - but I haven't done any analysis to back that up.


I don't have a sense of how many more modules like SSI could be 
realistically created.


Broadly, embedded is going to be the "bundle" module (well, modules) and 
if folks want a finer-grained selection then they can use the JARs from 
the standard distribution.


Mark




side note: fine for me if it targets only 10.1.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :


On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to

be

able to use it in the CP if a jlink custom distro (without

forking/patching

tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina

for

ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with

classifiers

only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user

consumes

it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made
optional. That involves fine-tuning the bnd configuration files.

That does raise the question what we do when a user tries to use the
optional features. I think we need to:
- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the
dependencies are correctly declared is another solution but we have
users that have requested we provide Tomcat in as few JARs as possible.

I think we are approaching "can't please all of the people, all of the
time" territory here.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Drop module-info from tomcat*.jar?

[Romain Manni-Bucau]

I think the last option is maybe the target: modularize tomcat properly.
The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?

side note: fine for me if it targets only 10.1.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 15 sept. 2021 à 11:17, Mark Thomas  a écrit :

> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > I was trying to strim down a JDK, all was smooth until I started to work
> > with Tomcat.
>
> I am assuming this is with embedded.
>
> > The issues I hit:
> >
> > - Tomcat is designed to be fully used with JPMS whereas I would like to
> be
> > able to use it in the CP if a jlink custom distro (without
> forking/patching
> > tomcat jar indeed)
> > - module-info use "requires" and no optional dependent modules which lead
> > to way too much dependencies (open the module-info from tomcat-catalina
> for
> > ex)
> >
> > Indeed there are always workaround and way to achieve what I wanted but I
> > think the JPMS deliveries of Tomat are not friendly so think it is worth
> > thinking about:
> >
> > 1. dropping it
>
> Not an option as we have users that have requested it.
>
> > 2. making it optional (I assume it can be released in jars with
> classifiers
> > only)
>
> Maybe, but it adds a bunch of artefacts.
>
> > 3. making it more accurate - but this highly depends how the user
> consumes
> > it (in particular for tomcat embed flavor)
>
> I think a variation of this is the way to go.
>
> Looking at the list of dependencies, I suspect most of them can be made
> optional. That involves fine-tuning the bnd configuration files.
>
> That does raise the question what we do when a user tries to use the
> optional features. I think we need to:
> - identify those Tomcat features that depend on optional modules
> - add a check for the presence of the module before using the feature
>and log an appropriate error message if the module is missing.
>
> Splitting embedded into lots of little modules where all the
> dependencies are correctly declared is another solution but we have
> users that have requested we provide Tomcat in as few JARs as possible.
>
> I think we are approaching "can't please all of the people, all of the
> time" territory here.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Drop module-info from tomcat*.jar?

[Mark Thomas]

On 15/09/2021 08:34, Romain Manni-Bucau wrote:

Hi all,

I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.


I am assuming this is with embedded.


The issues I hit:

- Tomcat is designed to be fully used with JPMS whereas I would like to be
able to use it in the CP if a jlink custom distro (without forking/patching
tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina for
ex)

Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:

1. dropping it


Not an option as we have users that have requested it.


2. making it optional (I assume it can be released in jars with classifiers
only)


Maybe, but it adds a bunch of artefacts.


3. making it more accurate - but this highly depends how the user consumes
it (in particular for tomcat embed flavor)


I think a variation of this is the way to go.

Looking at the list of dependencies, I suspect most of them can be made 
optional. That involves fine-tuning the bnd configuration files.


That does raise the question what we do when a user tries to use the 
optional features. I think we need to:

- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
  and log an appropriate error message if the module is missing.

Splitting embedded into lots of little modules where all the 
dependencies are correctly declared is another solution but we have 
users that have requested we provide Tomcat in as few JARs as possible.


I think we are approaching "can't please all of the people, all of the 
time" territory here.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org