Re: ant git commit: Generate manifest files and add automatic module names for JPMS

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

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Stefan Bodewig

> Generate manifest files and add automatic module names for JPMS

-1

please remove the Automatic-Module-Name attributes as our jars are no
proper JPMS modules.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
I adjusted the proposal and I hope that I addressed your criticism.
Most of the non-JPMS stuff is deprecated anyway, we need maybe decide what
to do with BCEL support.

Gintas

2018-02-05 21:11 GMT+01:00 Stefan Bodewig <[hidden email]>:

>
> > Generate manifest files and add automatic module names for JPMS
>
> -1
>
> please remove the Automatic-Module-Name attributes as our jars are no
> proper JPMS modules.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
Besides, we can move classes and build an apache-bwc.jar that contains
placeholders and/or deprecated classes.
ScriptRunner is a good example of that.

Gintas

2018-02-05 21:38 GMT+01:00 Gintautas Grigelionis <[hidden email]>:

> I adjusted the proposal and I hope that I addressed your criticism.
> Most of the non-JPMS stuff is deprecated anyway, we need maybe decide what
> to do with BCEL support.
>
> Gintas
>
> 2018-02-05 21:11 GMT+01:00 Stefan Bodewig <[hidden email]>:
>
>>
>> > Generate manifest files and add automatic module names for JPMS
>>
>> -1
>>
>> please remove the Automatic-Module-Name attributes as our jars are no
>> proper JPMS modules.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Jaikiran Pai
In reply to this post by Stefan Bodewig
I agree. -1.

On a related note, I don't think we should be doing any of these commits
especially when there's a RC out which we plan to release. IMO, only
blocker issues need to be addressed when the RC is out.

-Jaikiran


On 06/02/18 1:41 AM, Stefan Bodewig wrote:

>> Generate manifest files and add automatic module names for JPMS
> -1
>
> please remove the Automatic-Module-Name attributes as our jars are no
> proper JPMS modules.
>
> Stefan
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Jaikiran Pai
Just to be clear, my -1 was meant for both this commit as well as a
subsequent commit where some specific jars have been tagged as JPMS
modules. I think adding this automatic module names just for the sake of
it isn't a good thing.

-Jaikiran


On 06/02/18 9:38 AM, Jaikiran Pai wrote:

> I agree. -1.
>
> On a related note, I don't think we should be doing any of these
> commits especially when there's a RC out which we plan to release.
> IMO, only blocker issues need to be addressed when the RC is out.
>
> -Jaikiran
>
>
> On 06/02/18 1:41 AM, Stefan Bodewig wrote:
>>> Generate manifest files and add automatic module names for JPMS
>> -1
>>
>> please remove the Automatic-Module-Name attributes as our jars are no
>> proper JPMS modules.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> 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]

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
I understand the intent of your votes. I do experiment with using module
path in a real world application, so it's not an art for art's sake.
I will move the proposal to a PR. Talking of which, have you any comments
on IVY-1485 (aka PR-65)?

Gintas

2018-02-06 9:46 GMT+01:00 Jaikiran Pai <[hidden email]>:

> Just to be clear, my -1 was meant for both this commit as well as a
> subsequent commit where some specific jars have been tagged as JPMS
> modules. I think adding this automatic module names just for the sake of it
> isn't a good thing.
>
> -Jaikiran
>
>
>
> On 06/02/18 9:38 AM, Jaikiran Pai wrote:
>
>> I agree. -1.
>>
>> On a related note, I don't think we should be doing any of these commits
>> especially when there's a RC out which we plan to release. IMO, only
>> blocker issues need to be addressed when the RC is out.
>>
>> -Jaikiran
>>
>>
>> On 06/02/18 1:41 AM, Stefan Bodewig wrote:
>>
>>> Generate manifest files and add automatic module names for JPMS
>>>>
>>> -1
>>>
>>> please remove the Automatic-Module-Name attributes as our jars are no
>>> proper JPMS modules.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Stefan Bodewig
In reply to this post by Gintautas Grigelionis
On 2018-02-05, Gintautas Grigelionis wrote:

> I adjusted the proposal and I hope that I addressed your criticism.

Unfortunately it doesn't.

I'm afraid that we would be sending a wrong signal here. On top of that
I don't think Ant would actually work if parts of it are used as
modules. We use classloaders and Class.forName all over the place, not
ServiceLoader, for example.

If the taskdef/typedef implementation classes are loaded via a module
path and a custom task lives on the CLASSPATH will taskdef be able to
load it at all?

Without really having tried a setup of some of our jars coming from a
module loader and the rest living on a CLASSPATH and trying out all the
different scenarios of custom tasks/types/loggers, taking into account
classes that do something like

public void add(SomeInterface foo) { ,,, }

in order to allow any typedeffed implementation of the interface to be
used as a nested child element and all the other edge cases, I wouldn't
want to send the slightest signal that Ant was supporting the module
system in any way. It simply has been designed for a classloader world
and heavily relies on it.

As for moving classes and adding stubs for backwards compatibility -
let's please evaluate what we'd gain with such a move.

Ant is used as a code dependency by way more things than we know. We do
know Gradle and SBT directly call into Ant classes under the
covers. Lots and lots of custom tasks have been written that rely on our
API. If you use some kind of Maven antrun construct then moving classes
around and adding a new jar means you have to add a new dependency when
you want to upgrade to a new version. This is inconvenient and may turn
out to cause difficult to diagnose problems.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Stefan Bodewig
In reply to this post by Jaikiran Pai
On 2018-02-06, Jaikiran Pai wrote:

>  don't think we should be doing any of these commits especially when
> there's a RC out which we plan to release.

In general we live in a commit then review world, so I think it is kind
of OK to perform bigger changes without discussion upfront. It would
have been good to get some kind of heads-up, tough.

As for commits while a vote is going on, personally I don't care too
much. The RC has been cut from a detached head and if some changes would
be required for a second RC they can be added and merged back to master
by turning the head into a proper branch.

What will happen though (assuming the vote passes) is that we get a
non-linear history where users may assume some changes to master were
part of the release because they happened before the tag was merged back
if they only look at the timestamps rather than the commit graph.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
In reply to this post by Stefan Bodewig
2018-02-06 11:05 GMT+01:00 Stefan Bodewig <[hidden email]>:

> On 2018-02-05, Gintautas Grigelionis wrote:
>
> > I adjusted the proposal and I hope that I addressed your criticism.
>
> Unfortunately it doesn't.
>
> I'm afraid that we would be sending a wrong signal here. On top of that
> I don't think Ant would actually work if parts of it are used as
> modules. We use classloaders and Class.forName all over the place, not
> ServiceLoader, for example.
>
> If the taskdef/typedef implementation classes are loaded via a module
> path and a custom task lives on the CLASSPATH will taskdef be able to
> load it at all?
>

Anything on the CLASSPATH is in the unnamed module.
The worst that can happen is the situation where a package split between
module path and classpath.
That's what --patch-module is for.


> As for moving classes and adding stubs for backwards compatibility -
> let's please evaluate what we'd gain with such a move.
>
> Ant is used as a code dependency by way more things than we know. We do
> know Gradle and SBT directly call into Ant classes under the
> covers. Lots and lots of custom tasks have been written that rely on our
> API. If you use some kind of Maven antrun construct then moving classes
> around and adding a new jar means you have to add a new dependency when
> you want to upgrade to a new version. This is inconvenient and may turn
> out to cause difficult to diagnose problems.
>

Modules is the way to take back control. There are switches in Java 9 to
enable access.
We should rather be doing now when JRE is still lenient. Who knows what to
expect from Java 11 LTS (6 months from now)?

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Stefan Bodewig
On 2018-02-06, Gintautas Grigelionis wrote:

> 2018-02-06 11:05 GMT+01:00 Stefan Bodewig <[hidden email]>:

>> If the taskdef/typedef implementation classes are loaded via a module
>> path and a custom task lives on the CLASSPATH will taskdef be able to
>> load it at all?

> Anything on the CLASSPATH is in the unnamed module.

I know. :-)

> The worst that can happen is the situation where a package split between
> module path and classpath.
> That's what --patch-module is for.

Or where a custom task lives inside of a module itself and you need to
add an import to that module to Ant. How do you enforce that from inside
the build file where the taskdef is written? Do you tell users of your
task to always start with ANT_OPTS=... or provide a wrapper script?

All I'm saying is that we need to try out a bunch of use cases to see
what works and what doesn't. What users could expect of a modularized
version of Ant and what exactly the benefit for users is going to be.

Personally I don't expect the "good old classpath world" to disappear
any time soon, but I've been wrong so many times ...

> Modules is the way to take back control.

Of the JDK. I really don't believe it helps writers of build tools in
any way :-)

> There are switches in Java 9 to enable access.  We should rather be
> doing now when JRE is still lenient. Who knows what to expect from
> Java 11 LTS (6 months from now)?

My fear is that if the classpath world stops working then a completely
different version of Ant will be required. A version that has to break
backwards compatibility in many ways. I'd appreciate anybody trying to
assess what would need to change in a pure module world, I know I cannot
be the one.

Ant plays well with the modularized JDK, we verified that in late 2016
before the rules were relaxed in Java9. Turning Ant into a "modular"
application in the sense of Java9 modules is a completely different can
of worms.

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
2018-02-07 11:44 GMT+01:00 Stefan Bodewig <[hidden email]>:

> On 2018-02-06, Gintautas Grigelionis wrote:
>
> > 2018-02-06 11:05 GMT+01:00 Stefan Bodewig <[hidden email]>:
>
> >> If the taskdef/typedef implementation classes are loaded via a module
> >> path and a custom task lives on the CLASSPATH will taskdef be able to
> >> load it at all?
>
> > Anything on the CLASSPATH is in the unnamed module.
>
> I know. :-)
>
> > The worst that can happen is the situation where a package split between
> > module path and classpath.
> > That's what --patch-module is for.
>
> Or where a custom task lives inside of a module itself and you need to
> add an import to that module to Ant. How do you enforce that from inside
> the build file where the taskdef is written? Do you tell users of your
> task to always start with ANT_OPTS=... or provide a wrapper script?
>

Well, that's the kind of situation that a modularised Ant would address.
My starting question is "what would happen if (parts of) Ant were moved to
the module path?"

All I'm saying is that we need to try out a bunch of use cases to see

> what works and what doesn't. What users could expect of a modularized
> version of Ant and what exactly the benefit for users is going to be.
>
> Personally I don't expect the "good old classpath world" to disappear
> any time soon, but I've been wrong so many times ...
>
> > Modules is the way to take back control.
>
> Of the JDK. I really don't believe it helps writers of build tools in
> any way :-)
>

I'm tending to give JPMS a benefit of doubt :-)


> My fear is that if the classpath world stops working then a completely
> different version of Ant will be required. A version that has to break
> backwards compatibility in many ways. I'd appreciate anybody trying to
> assess what would need to change in a pure module world, I know I cannot
> be the one.
>
> Ant plays well with the modularized JDK, we verified that in late 2016
> before the rules were relaxed in Java9. Turning Ant into a "modular"
> application in the sense of Java9 modules is a completely different can
> of worms.
>

 I'd like to peek into that can... would you be willing to revise a
proposal of
 what classes could be moved around and/or deprecated to start with?

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Stefan Bodewig
On 2018-02-07, Gintautas Grigelionis wrote:

> 2018-02-07 11:44 GMT+01:00 Stefan Bodewig <[hidden email]>:

>> My fear is that if the classpath world stops working then a completely
>> different version of Ant will be required. A version that has to break
>> backwards compatibility in many ways. I'd appreciate anybody trying to
>> assess what would need to change in a pure module world, I know I cannot
>> be the one.

>> Ant plays well with the modularized JDK, we verified that in late 2016
>> before the rules were relaxed in Java9. Turning Ant into a "modular"
>> application in the sense of Java9 modules is a completely different can
>> of worms.

>  I'd like to peek into that can... would you be willing to revise a
> proposal of what classes could be moved around and/or deprecated to
> start with?

Maybe it will be easier to digest if we start at a higher level of what
needs to be changed. I don't think moving classes so we don't have any
split packages anymore will be enough.

I'd expect we'd need to replace all code that deals with classloaders
and replace it with ServiceLoaders if we want to avoid complex startup
scenarios for example. Given there is no interface or base class tasks
or types must implement this may again force us to change this model. Or
maybe I'm just wrong.

If we want a broader audience we may want to change the subject :-)

Stefan

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

Reply | Threaded
Open this post in threaded view
|

Re: ant git commit: Generate manifest files and add automatic module names for JPMS

Gintautas Grigelionis
2018-02-07 18:25 GMT+01:00 Stefan Bodewig <[hidden email]>:

>
> Maybe it will be easier to digest if we start at a higher level of what
> needs to be changed. I don't think moving classes so we don't have any
> split packages anymore will be enough.
>
> I'd expect we'd need to replace all code that deals with classloaders
> and replace it with ServiceLoaders if we want to avoid complex startup
> scenarios for example. Given there is no interface or base class tasks
> or types must implement this may again force us to change this model. Or
> maybe I'm just wrong.
>
> If we want a broader audience we may want to change the subject :-)
>

I believe that the primary problem is that of classloaders behaving
differently in presence of the module path.
ServiceLoaders is a different problem, my understanding is that it could be
an alternative to CDI (which currently is Java EE/EE4J).

Gintas