2018-02-07 18:25 GMT+01:00 Stefan Bodewig :
>
> 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
On 2018-02-07, Gintautas Grigelionis wrote:
> 2018-02-07 11:44 GMT+01:00 Stefan Bodewig :
>> 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
2018-02-07 11:44 GMT+01:00 Stefan Bodewig :
> On 2018-02-06, Gintautas Grigelionis wrote:
>
> > 2018-02-06 11:05 GMT+01:00 Stefan Bodewig :
>
> >> If the taskdef/typedef implementation classes are loaded via a module
> >> path and a custom task lives on the
On 2018-02-06, Gintautas Grigelionis wrote:
> 2018-02-06 11:05 GMT+01:00 Stefan Bodewig :
>> 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
2018-02-06 11:05 GMT+01:00 Stefan Bodewig :
> 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
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
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
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
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
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
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 :
> I adjusted the proposal and I hope that I addressed your
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 :
>
> > Generate manifest files and add automatic module
> 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: dev-unsubscr...@ant.apache.org
13 matches
Mail list logo