Re: VOTE Retire IvyDE

[Jean-Louis Boudart]

+1

Le 6 déc. 2016 6:51 PM, "Nicolas Lalevée"  a
écrit :

> +1
>
> Nicolas
>
> > Le 6 déc. 2016 à 17:22, Stefan Bodewig  a écrit :
> >
> > On 2016-12-05, Jan Matèrne (jhm) wrote:
> >
> >> I start a vote for retiring IvyDE.
> >
> > +0
> >
> > The discussion in the "Ivy" thread makes me think we'd probably want to
> > update it with new Ivy releases, even if nothing else changes in
> > between.
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: VOTE Retire EasyAnt subproject

[Jean-Louis Boudart]

+1

2016-12-07 1:05 GMT+01:00 Conor MacNeill :

> +1
>
> Conor
>
>
> On 5 December 2016 at 18:04, Jan Matèrne (jhm)  wrote:
> > I start a vote for retiring EasyAnt and all its components:
> >
> > - core
> >
> > - buildtypes
> >
> > - plugins
> >
> > - skeletons
> >
> > - tasks
> >
> > - easyant4e
> >
> >
> >
> > We never had a real release after the incubator.
> >
> > The last 'real' activity in vcs was in 09/2015 for EA-Core and 07/2013
> for
> > EA4E.
> >
> >
> >
> > It seems that we havent the community, committers and PMC to hold this
> > subproject.
> >
> >
> >
> > The general procedure is described in http://ant.apache.org/
> processes.html.
> >
> >
> >
> >
> >
> > I start with my +1.
> >
> >
> >
> >
> >
> > Jan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/

Re: VOTE Retire EasyAnt subproject

[Conor MacNeill]

+1

Conor


On 5 December 2016 at 18:04, Jan Matèrne (jhm)  wrote:
> I start a vote for retiring EasyAnt and all its components:
>
> - core
>
> - buildtypes
>
> - plugins
>
> - skeletons
>
> - tasks
>
> - easyant4e
>
>
>
> We never had a real release after the incubator.
>
> The last 'real' activity in vcs was in 09/2015 for EA-Core and 07/2013 for
> EA4E.
>
>
>
> It seems that we havent the community, committers and PMC to hold this
> subproject.
>
>
>
> The general procedure is described in http://ant.apache.org/processes.html.
>
>
>
>
>
> I start with my +1.
>
>
>
>
>
> Jan
>

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

Re: VOTE Retire IvyDE

[Nicolas Lalevée]

+1

Nicolas

> Le 6 déc. 2016 à 17:22, Stefan Bodewig  a écrit :
> 
> On 2016-12-05, Jan Matèrne (jhm) wrote:
> 
>> I start a vote for retiring IvyDE.
> 
> +0
> 
> The discussion in the "Ivy" thread makes me think we'd probably want to
> update it with new Ivy releases, even if nothing else changes in
> between.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Ivy - any future or is it also going to be retired?

[Nicolas Lalevée]

> Le 6 déc. 2016 à 17:21, Stefan Bodewig  a écrit :
> 
> On 2016-12-05, Jaikiran Pai wrote:
> 
>> I have been following the latest emails on retiring sub projects in
>> Ant. I just see a proposal to retire IvyDE (the Eclipse plugin) for
>> valid reasons (given the lack of any real activity in there). Given
>> this, I would like to understand what the future of Ivy project itself
>> is. 
> 
> This isn't easy to answer. It looks as if we could manage to gain
> momentum again. Looking at the number of people who responded in this
> thread, there seems to be enough interest of people willing to get their
> hands dirty.
> 
> For now there we don't intend to retire Ivy, but it sure looks pretty
> much asleep.
> 
> Honestly I don't think the problem is that nobody knows how to cut a
> release, this should be automated mostly anyway and would be extremely
> hard to do without access to ASF infrastructure. What we seem to lack is
> people who actually know the Ivy code base and have the time to review
> patches/develop new features.
> 
> Taking myself as an example I have never looked much at Ivy's code and
> have completely ignored all issues over there. My plate is full anyway
> and I wouldn't know how to find the time needed to learn the ins and
> outs. Of course there is a catch here, if we don't manage to apply
> patches we'll never find people who are willing to contribute.
> 
> Ivy may be in use by other projects (I think gradle 3 has moved off of
> Ivy, may be wrong

As far as I can tell, Ivy is still a dependency for dependency management:
https://github.com/gradle/gradle/blob/master/gradle/dependencies.gradle#L41
https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/dependency-management.gradle#L19

Now to answer to globally to the discussion about Ivy’s future, it is indeed 
not bright.

As pointed, the few people who know the code are still around, so it is not 
technically dead. But it needs more than that to continue to be maintained. To 
continue the point made by Stefan, we need people which understand the code, 
but I think more than providing patches. We need people who code but also can 
decide when to cut a release, do some ticket triage, give some time to answer 
to the user mailing list.

We are in a weird state here because the bylaws of Apache still enforce the 
decisions to be taken by people which are not much active. But if some people 
are willing to contribute and make the Ivy project healthy again, I am sure 
some of us will make the effort to make the transition work.

For instance, if somebody here really want a new release of Ivy happen, there 
are a lot of stuff which doesn’t require to be a committer:
- first it will be great to see a summary of what will be in the release, 
explain if it will a bug fix release, or a major release, or if it requires to 
be a release candidate
- maybe there is some jira triage to do, is there any pending patch we've 
missed which could be easily included in the release
- test if the release process is still working, if there is anything to fix (I 
don’t even remember if we have done our first Ivy release while the sources 
being hosted on git).
- we still have trouble to release the doc I think, because there is a mix of 
svn and git. Probably some work to do here, even maybe suggest a better process
- I think building the release artifacts itself doesn’t require much 
credentials, so anybody could provide some

These are just ideas poping up my mind to show that if people are enough 
motivated, they can make things happen. And obviously, if things work well, 
credentials will be granted.

I think this is the same for IvyDE, but it requires much more effort because 
the build is broken since we migrated to git, and so the release process has to 
be reviewed. Too much effort for me. Note though that we have a process to 
reactivate sub projects, so this is not for life (I kind of hope a reborn, this 
is the project which made me an Apache committer!).

Nicolas


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

Re: VOTE Retire EasyAnt subproject

[Nicolas Lalevée]

+1

Nicolas

> Le 5 déc. 2016 à 08:04, Jan Matèrne (jhm)  a écrit :
> 
> I start a vote for retiring EasyAnt and all its components:
> 
> - core
> 
> - buildtypes
> 
> - plugins
> 
> - skeletons
> 
> - tasks
> 
> - easyant4e
> 
> 
> 
> We never had a real release after the incubator.
> 
> The last 'real' activity in vcs was in 09/2015 for EA-Core and 07/2013 for
> EA4E. 
> 
> 
> 
> It seems that we havent the community, committers and PMC to hold this
> subproject. 
> 
> 
> 
> The general procedure is described in http://ant.apache.org/processes.html.
> 
> 
> 
> 
> 
> I start with my +1.
> 
> 
> 
> 
> 
> Jan
> 


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

Re: VOTE Retire EasyAnt subproject

[Stefan Bodewig]

On 2016-12-05, Jan Matèrne (jhm) wrote:

> I start a vote for retiring EasyAnt and all its components:

> - core
> - buildtypes
> - plugins
> - skeletons
> - tasks
> - easyant4e

+1

Stefan

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

Re: VOTE Retire IvyDE

[Stefan Bodewig]

On 2016-12-05, Jan Matèrne (jhm) wrote:

> I start a vote for retiring IvyDE.

+0

The discussion in the "Ivy" thread makes me think we'd probably want to
update it with new Ivy releases, even if nothing else changes in
between.

Stefan

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

Re: Ivy - any future or is it also going to be retired?

[Stefan Bodewig]

On 2016-12-05, Jaikiran Pai wrote:

> I have been following the latest emails on retiring sub projects in
> Ant. I just see a proposal to retire IvyDE (the Eclipse plugin) for
> valid reasons (given the lack of any real activity in there). Given
> this, I would like to understand what the future of Ivy project itself
> is. 

This isn't easy to answer. It looks as if we could manage to gain
momentum again. Looking at the number of people who responded in this
thread, there seems to be enough interest of people willing to get their
hands dirty.

For now there we don't intend to retire Ivy, but it sure looks pretty
much asleep.

Honestly I don't think the problem is that nobody knows how to cut a
release, this should be automated mostly anyway and would be extremely
hard to do without access to ASF infrastructure. What we seem to lack is
people who actually know the Ivy code base and have the time to review
patches/develop new features.

Taking myself as an example I have never looked much at Ivy's code and
have completely ignored all issues over there. My plate is full anyway
and I wouldn't know how to find the time needed to learn the ins and
outs. Of course there is a catch here, if we don't manage to apply
patches we'll never find people who are willing to contribute.

Ivy may be in use by other projects (I think gradle 3 has moved off of
Ivy, may be wrong) but that still shouldn't stop us from retiring it
once we'd find that we aren't able to fix bugs anymore.

Stefan

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

[GitHub] ant pull request #27: Bug 58661: avoid duplicate characters in stack traces

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ant/pull/27


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] ant issue #27: Bug 58661: avoid duplicate characters in stack traces

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/ant/pull/27
  
Thanks a lot.

I vaguely recall looking at the original patch and thinking "this is big", 
but strangely never commented.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] ant pull request #27: Bug 58661: avoid duplicate characters in stack traces

[barney2k7]

GitHub user barney2k7 opened a pull request:

https://github.com/apache/ant/pull/27

Bug 58661: avoid duplicate characters in stack traces

This fixes https://bz.apache.org/bugzilla/show_bug.cgi?id=58661

As suspected, the problem is in the 'br-replace' template that is off by 
one character in some cases:
$secondhalflen is actually less than string-length($secondhalfword) in case 
the number of chars in word is
even. This leads to $firsthalflen being calculated too long, resulting in a 
duplicated character.

Note that unlike the patch attached to the bug, this pull requests solves 
just the duplicate character problem - nothing else.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/barney2k7/ant Bug-58661

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/27.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #27


commit 0633fe53fb8c49792dcd3ad36e2dcb580763ecea
Author: barney2k7 
Date:   2016-12-06T14:25:41Z

Bug 58661: avoid duplicate characters in stack traces

The problem was that $secondhalflen is actually less than
string-length($secondhalfword) in case the number of chars in word is
even. This leads to $firsthalflen being calculated too long, resulting
in a duplicated character.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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