from:"J Pai"

Re: new committer: Jaikiran Pai

2017-06-17 Thread J Pai

Thanks everyone for the warm welcome :) 

I’m really excited to be part of the team. 

I’m sure most of the long-timers in this list don’t know me much, given that I 
have been active in the lists only in the past year or so. So here’s a quick 
intro about me (you can read a bit more about me here[1]) - I have been a long 
time user of Ant (more than a decade) and continue to use it on a daily basis 
in my projects. A couple of years back, for our internal projects, we decided 
to use Ivy and I started lurking around in the user mailing list. Over a period 
of time, I realized that the development of the Ivy project had come to a halt. 
Although, for the projects where I use Ivy, we haven’t had any blocking issues, 
the fact that it was no longer active was both sad and inconvenient especially 
if you have to explain to your team mates its value. I decided to contribute 
fixes/patches to the project to try and revive it a bit. I really want to thank 
Nicolas and Jan, who volunteered to review and merge the patches and provide 
their inputs. It’s been a big factor in the revival of the project.

Over the next few weeks, I intend to primarily focus on getting Ivy to a stage 
where we can release a new version. Some of you probably have already read up 
some mails about this plan in this list. I intend to continue working on that 
plan. Being a committer is a honour as well as a responsibility. It definitely 
will make it easier for me to contribute to the project. Ivy codebase and usage 
is relatively large and I’m just getting to know it’s internal details as I go 
along fixing bugs and enhancing it. As such, at least for the next few weeks, 
if there’s some major code change that I am not fully confident about, I plan 
to continue to raise PRs so that it gives a chance for Nicolas, Jan and others 
to provide their inputs.

Thanks again!

[1]  http://ant.apache.org/contributors.html

-Jaikiran
On 17-Jun-2017, at 12:24 AM, Nicolas Lalevée  wrote:

Welcome Jaikiran!

Thank you for your great patches. You can now apply them yourself :)

Nicolas

> Le 16 juin 2017 à 17:51, Jan Matèrne (jhm)  a écrit :
> 
> The Project Management Committee (PMC) for Apache Ant has invited Jaikiran
> Pai to become a committer and we are pleased to announce that he has
> accepted.
> 
> 
> 
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
> 
> 
> 
> 
> 
> Jan
> 

-
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

IvyDE JIRA issues and changes for proposed release?

2017-06-13 Thread J Pai

There’s been some good progress on reviving the Ivy project (thanks Nicolas and 
Jan for helping out with the reviews and merging PRs) and we seem to be moving 
towards a state where the release is a possibility. The other project IvyDE 
(the Eclipse plugin) however needs a bit more push I think. 

I am not a Eclipse user nor do I have any experience with plugin development, 
so there’s not much I can contribute on that front. However, there has been an 
external community member whose team(?) seemed to be interested in contributing 
to that plugin and in fact seem to have built some features on top of the 
current state of the plugin, in their own fork. They even proposed the 
contribution on the mailing list[1]. I suggested they raise a PR (to make it 
easier for review), but haven’t heard back. Given that and things in general, 
do we have someone who has experience of the code base plus Eclipse plugins who 
can help review that code? Furthermore, is there anything else the user has to 
do (like signing some CLA) for that contribution?

I think in general, do we have someone experienced with the plugin who can look 
at some of the IvyDE open JIRA issues/enhancements and decide which ones to fix 
in the upcoming release and make sure things work fine with the proposed Ivy 
release itself?

[1] https://www.mail-archive.com/dev@ant.apache.org/msg45486.html

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

Re: IVYDE-382 proposed patch

2017-06-13 Thread J Pai

Hi Alexander,

I actually just realized that your initial mail actually had a patch file
attached. I didn’t notice that before and only today noticed it while looking
at the mail list archive. So assuming this applies cleanly on latest master
branch of IvyDE, I think this should be fine too, instead of creating a PR. I
am not experienced with Eclipse plugins, so I personally won’t be able to help
much, but hopefully someone from the IvyDE team will be able to review and
decide about this patch. Thank you again for contributing this.

-Jaikiran
On 26-May-2017, at 8:28 AM, J Pai <jai.forums2...@gmail.com> wrote:

Hi Alexander,

Thank you for volunteering to provide this feature patch. I had a look a the
repo you pointed to and read the README. It does seem to contain a good amount
of work in that branch in multiple commits.

To make it easier for whoever will decide about merging these to upstream
ant-ivyde project, would it to be possible for you to do the following:

1. *Fork* the ant-ivyde project (on github)
https://github.com/apache/ant-ivyde/ into your account. There’s a “Fork” button
on the right corner of the github page for the repo.
2. Once forked into your account, you can push your enhancement and bug fix
related commits to either your master branch of your repo or any specific
branch of your choice.
- If the bug fixes are independent of the feature, then it would be
good if they are done in separate branches, so that a separate pull request
(PR) can be issued.
3. Once you are ready with the commits, you can then issue a pull request (PR)
from your repo to the “master” branch of the ant-ivyde upstream repo
https://github.com/apache/ant-ivyde/. Typically PRs are meant to contain
commits that are all specific to a single feature or for a specific bug fix.

Once the PRs are submitted, I’m sure one or more members of the development
team who have relevant knowledge of Eclipse and the project will review this
and either merge it or provide inputs.

Thanks again for this, both Ivy and IvyDE project has been stagnant for a while
and with contributions like these, we should be able to release out a new
version soon.

-Jaikiran

On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:

Dear Sir or Madam,

as it was suggested in
https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
we are sending you our proposed patch for
https://issues.apache.org/jira/browse/IVYDE-382. The corresponding patch-file
is attached to this email. The source code is available at
https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the branch
"ivyDECredentials".

Yours sincerely,

Alexander Blaas

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

Re: [VOTE] Release Compress Antlib 1.5 based on RC2

2017-06-05 Thread J Pai

+1.

-Jaikiran
On 06-Jun-2017, at 9:56 AM, Stefan Bodewig  wrote:

On 2017-06-01, Stefan Bodewig wrote:

> I've created a new release candidate for Compress Antlib 1.5, this time
> with working Ivy coordinates and a release date three days into the
> future.

> git tag: 1_5_RC2
> on commit: f20847d
> tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
>  revision: 19857
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapacheant-1018/org/apache/ant/ant-compress/1.5/

> This Vote will be open at least for 72 hours and close no earlier than
> 2017-06-04 17:00UTC.

Making my own vote explicit

+1

Actually, time seems to be up. Any other votes?

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 nightly builds - Generate a full .zip/.tar.gz snapshots?

2017-06-05 Thread J Pai

This job worked and we now have 2 successful runs of it. Thank you for setting 
this up - I’m hoping this will now get us a bit more quicker inputs to bug 
fixes and other things from Ivy user community who might be willing to give it 
a try.

-Jaikiran
On 03-Jun-2017, at 3:51 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

merged.
We'll see the next nightly ...

Jan

> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Samstag, 3. Juni 2017 04:07
> An: Ant Developers List
> Betreff: Re: Ivy nightly builds - Generate a full .zip/.tar.gz
> snapshots?
> 
> Here’s the PR to fix the tutorial regressions
> https://github.com/apache/ant-ivy/pull/40
> 
> -Jaikiran
> On 03-Jun-2017, at 7:09 AM, J Pai <jai.forums2...@gmail.com> wrote:
> 
> Looked at the job logs. This indeed caught a genuine compilation error.
> Given that we don’t run these tutorials build daily, it wasn’t noticed
> this far. It looks like this might have been introduced by some of our
> recent changes. I’ll  take a look to fix it today.
> 
> -Jaikiran
> On 03-Jun-2017, at 1:28 AM, Jan Matèrne (jhm) <apa...@materne.de>
> wrote:
> 
>> Would it be feasible to have a Jenkins daily job (runs once at a
>> schedule) for Ivy which publishes the complete binary zip/tar.gz of
>> Ivy nightly snapshots? I know we have a daily job currently here[1]
>> which generates a jar as the artifact output of the job. Maybe this
>> job itself can be changed to generate the full distributable binary
>> .zip/.tar.gz?
>> 
>> Where I plan to use such a job is, to have Ivy users have quick
> access
>> to our nightly builds so that they can use those binaries just like
>> they would for released versions. That way, we can ask the users to
>> test out/verify any bug fixes we have pushed, in their own
>> environments by installing those snapshots. Especially in cases where
>> it’s hard to reproduce some bugs in first place (Windows OS for
>> example). I understand they could probably do it even now using those
>> jars we publish, but I would prefer the process of “installation” to
>> be almost the same as what we would do with released binaries - i.e.
>> use a .zip/.tar.gz with all relevant files in them.
>> 
>> [1] https://builds.apache.org/job/Ivy/
> 
> 
> Not sure if that is that the right.
> I set up a job which runs @daily, starts "ant -f build-release.xml
> snapshot-bin" and publishes build/distrib/dist/**.
> https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/
> 
> 
> Jan
> 
> 
> -
> 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



-
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] Release Compress Antlib 1.5 based on RC2

2017-06-02 Thread J Pai

Downloaded the tar and checked the docs and other files. Looks fine.

-Jaikiran
On 01-Jun-2017, at 10:25 PM, Stefan Bodewig  wrote:

Hi all

I've created a new release candidate for Compress Antlib 1.5, this time
with working Ivy coordinates and a release date three days into the
future.

git tag: 1_5_RC2
on commit: f20847d
tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
 revision: 19857
Maven artifacts:
 
https://repository.apache.org/content/repositories/orgapacheant-1018/org/apache/ant/ant-compress/1.5/

This Vote will be open at least for 72 hours and close no earlier than
2017-06-04 17:00UTC.

Cheers

   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 nightly builds - Generate a full .zip/.tar.gz snapshots?

2017-06-02 Thread J Pai

Here’s the PR to fix the tutorial regressions 
https://github.com/apache/ant-ivy/pull/40

-Jaikiran
On 03-Jun-2017, at 7:09 AM, J Pai <jai.forums2...@gmail.com> wrote:

Looked at the job logs. This indeed caught a genuine compilation error. Given 
that we don’t run these tutorials build daily, it wasn’t noticed this far. It 
looks like this might have been introduced by some of our recent changes. I’ll  
take a look to fix it today.

-Jaikiran
On 03-Jun-2017, at 1:28 AM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

> Would it be feasible to have a Jenkins daily job (runs once at a
> schedule) for Ivy which publishes the complete binary zip/tar.gz of Ivy
> nightly snapshots? I know we have a daily job currently here[1] which
> generates a jar as the artifact output of the job. Maybe this job
> itself can be changed to generate the full distributable binary
> .zip/.tar.gz?
> 
> Where I plan to use such a job is, to have Ivy users have quick access
> to our nightly builds so that they can use those binaries just like
> they would for released versions. That way, we can ask the users to
> test out/verify any bug fixes we have pushed, in their own environments
> by installing those snapshots. Especially in cases where it’s hard to
> reproduce some bugs in first place (Windows OS for example). I
> understand they could probably do it even now using those jars we
> publish, but I would prefer the process of “installation” to be almost
> the same as what we would do with released binaries - i.e. use a
> .zip/.tar.gz with all relevant files in them.
> 
> [1] https://builds.apache.org/job/Ivy/


Not sure if that is that the right.
I set up a job which runs @daily, starts "ant -f build-release.xml 
snapshot-bin" and publishes build/distrib/dist/**.
https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/


Jan


-
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 nightly builds - Generate a full .zip/.tar.gz snapshots?

2017-06-02 Thread J Pai

Looked at the job logs. This indeed caught a genuine compilation error. Given 
that we don’t run these tutorials build daily, it wasn’t noticed this far. It 
looks like this might have been introduced by some of our recent changes. I’ll  
take a look to fix it today.

-Jaikiran
On 03-Jun-2017, at 1:28 AM, Jan Matèrne (jhm)  wrote:

> Would it be feasible to have a Jenkins daily job (runs once at a
> schedule) for Ivy which publishes the complete binary zip/tar.gz of Ivy
> nightly snapshots? I know we have a daily job currently here[1] which
> generates a jar as the artifact output of the job. Maybe this job
> itself can be changed to generate the full distributable binary
> .zip/.tar.gz?
> 
> Where I plan to use such a job is, to have Ivy users have quick access
> to our nightly builds so that they can use those binaries just like
> they would for released versions. That way, we can ask the users to
> test out/verify any bug fixes we have pushed, in their own environments
> by installing those snapshots. Especially in cases where it’s hard to
> reproduce some bugs in first place (Windows OS for example). I
> understand they could probably do it even now using those jars we
> publish, but I would prefer the process of “installation” to be almost
> the same as what we would do with released binaries - i.e. use a
> .zip/.tar.gz with all relevant files in them.
> 
> [1] https://builds.apache.org/job/Ivy/


Not sure if that is that the right.
I set up a job which runs @daily, starts "ant -f build-release.xml 
snapshot-bin" and publishes build/distrib/dist/**.
https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/


Jan


-
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

Ivy nightly builds - Generate a full .zip/.tar.gz snapshots?

2017-06-02 Thread J Pai

Would it be feasible to have a Jenkins daily job (runs once at a schedule) for 
Ivy which publishes the complete binary zip/tar.gz of Ivy nightly snapshots? I 
know we have a daily job currently here[1] which generates a jar as the 
artifact output of the job. Maybe this job itself can be changed to generate 
the full distributable binary .zip/.tar.gz?

Where I plan to use such a job is, to have Ivy users have quick access to our 
nightly builds so that they can use those binaries just like they would for 
released versions. That way, we can ask the users to test out/verify any bug 
fixes we have pushed, in their own environments by installing those snapshots. 
Especially in cases where it’s hard to reproduce some bugs in first place 
(Windows OS for example). I understand they could probably do it even now using 
those jars we publish, but I would prefer the process of “installation” to be 
almost the same as what we would do with released binaries - i.e. use a 
.zip/.tar.gz with all relevant files in them.

[1] https://builds.apache.org/job/Ivy/

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

Re: IVY-1475 - cachefileset task and its inherent limitation

2017-06-02 Thread J Pai

This is now available for review https://github.com/apache/ant-ivy/pull/38

-Jaikiran
On 02-Jun-2017, at 5:39 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

+1
Jan

> -Ursprüngliche Nachricht-
> Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> Gesendet: Freitag, 2. Juni 2017 12:39
> An: Ant Developers List
> Betreff: Re: IVY-1475 - cachefileset task and its inherent limitation
> 
> 
>> Le 2 juin 2017 à 12:05, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> So that does mean cachefileset has a role to play in at least some
> cases. In that case, I think the approach we could take is to _not_
> deprecate it and instead include this limitation as part of the
> documentation *and* enhance the code of this task to explicit fail with
> a proper error when it can’t determine a common base directory.
>> 
> 
> Sounds good to me.
> 
> Nicolas
> 
> 
>> -Jaikiran
>> On 02-Jun-2017, at 2:55 PM, Nicolas Lalevée
> <nicolas.lale...@hibnet.org> wrote:
>> 
>> 
>>> Le 2 juin 2017 à 08:22, Jan Matèrne (jhm) <apa...@materne.de> a
> écrit :
>>> 
>>> From a naive user point of view, it doesnt matter (to me) if I use
>>> ivy:chachefileset or ivy:resources.
>>> I want to specify the dependency and have a 'thing' which contains
>>> all required jars, so I could use external tasks/antlibs.
>>> 
>>> Ant itself moved from fileset to resource collection some years ago
> and Ivy could follow.
>>> But I am not sure that we could use RCs _everywhere_.
>>> In the few exceptions you have to use ivy:cachefileset - maybe
>>> multiple …
>> 
>> One limitation of resource collections is that they doesn’t have
>> necessarily a basedir, contrary to a fileset :) For instance a
> basedir it is quite useful for the copy task, so a set of files be be
> copied with their relative paths to the basedir, rather than with their
> absolute paths.
>> 
>> Nicolas
>> 
>>> Jan
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>>>> Gesendet: Freitag, 2. Juni 2017 05:29
>>>> An: Ant Developers List
>>>> Betreff: IVY-1475 - cachefileset task and its inherent limitation
>>>> 
>>>> One of the Ivy users has pointed out to an issue in cachefileset
>>>> task[1] of Ivy here https://issues.apache.org/jira/browse/IVY-1475.
>>>> 
>>>> To summarize, the cachefileset task is expected to create a Ant
>>>> Fileset of the resolved artifacts in the cache(s). Ant Fileset
>>>> requires a
>>>> (single) basedir to work on and the Ivy cachefileset has a piece of
>>>> logic which tries to determine a common base directory for the
>>>> resolved artifacts. It’s very much possible that there won’t be a
>>>> common base directory for artifacts if the caches have been
>>>> configured to be on multiple different filesystem roots, as noted
> in
>>>> that JIRA. So essentially, to me, it looks like this cachefileset
>>>> has an inherent deficiency which can’t really be fixed.
>>>> 
>>>> The user in that JIRA notes that we can deprecate this task (and
>>>> also add a note about this limitation) in favour of “resources”
> task
>>>> [2] which provides a similar functionality but is much more
> flexible
>>>> and doesn’t suffer this limitation.
>>>> 
>>>> Any thoughts on how we should go about this JIRA and the
>>>> cachefileset task?
>>>> 
>>>> [1] https://ant.apache.org/ivy/history/latest-
>>>> milestone/use/cachefileset.html
>>>> [2] https://ant.apache.org/ivy/history/latest-
>>>> milestone/use/resources.html
>>>> 
>>>> -Jaikiran
>>>> ---
> -
>>>> - 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
>>> 
>> 
>> 
>> -
>> 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
>> 
> 
> 
> -
> 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



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

Re: IVY-1475 - cachefileset task and its inherent limitation

2017-06-02 Thread J Pai

So that does mean cachefileset has a role to play in at least some cases. In 
that case, I think the approach we could take is to _not_ deprecate it and 
instead include this limitation as part of the documentation *and* enhance the 
code of this task to explicit fail with a proper error when it can’t determine 
a common base directory.

-Jaikiran
On 02-Jun-2017, at 2:55 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:


> Le 2 juin 2017 à 08:22, Jan Matèrne (jhm) <apa...@materne.de> a écrit :
> 
> From a naive user point of view, it doesnt matter (to me) if I use
> ivy:chachefileset or ivy:resources.
> I want to specify the dependency and have a 'thing' which contains all 
> required jars, so I could
> use external tasks/antlibs.
> 
> Ant itself moved from fileset to resource collection some years ago and Ivy 
> could follow.
> But I am not sure that we could use RCs _everywhere_.
> In the few exceptions you have to use ivy:cachefileset - maybe multiple …

One limitation of resource collections is that they doesn’t have necessarily a 
basedir, contrary to a fileset :)
For instance a basedir it is quite useful for the copy task, so a set of files 
be be copied with their relative paths to the basedir, rather than with their 
absolute paths.

Nicolas

> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>> Gesendet: Freitag, 2. Juni 2017 05:29
>> An: Ant Developers List
>> Betreff: IVY-1475 - cachefileset task and its inherent limitation
>> 
>> One of the Ivy users has pointed out to an issue in cachefileset
>> task[1] of Ivy here https://issues.apache.org/jira/browse/IVY-1475.
>> 
>> To summarize, the cachefileset task is expected to create a Ant Fileset
>> of the resolved artifacts in the cache(s). Ant Fileset requires a
>> (single) basedir to work on and the Ivy cachefileset has a piece of
>> logic which tries to determine a common base directory for the resolved
>> artifacts. It’s very much possible that there won’t be a common base
>> directory for artifacts if the caches have been configured to be on
>> multiple different filesystem roots, as noted in that JIRA. So
>> essentially, to me, it looks like this cachefileset has an inherent
>> deficiency which can’t really be fixed.
>> 
>> The user in that JIRA notes that we can deprecate this task (and also
>> add a note about this limitation) in favour of “resources” task [2]
>> which provides a similar functionality but is much more flexible and
>> doesn’t suffer this limitation.
>> 
>> Any thoughts on how we should go about this JIRA and the cachefileset
>> task?
>> 
>> [1] https://ant.apache.org/ivy/history/latest-
>> milestone/use/cachefileset.html
>> [2] https://ant.apache.org/ivy/history/latest-
>> milestone/use/resources.html
>> 
>> -Jaikiran
>> -
>> 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
> 


-
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 website - fixing a Quickstart documentation live

2017-06-02 Thread J Pai

I just realized that attachments aren’t delivered to the mailing list. So 
here’s the gist link to the patch 
https://gist.github.com/jaikiran/992e642410afb5683e461d1bd6e01503 which I was 
talking about in my mail.

-Jaikiran
On 26-May-2017, at 12:36 PM, J Pai <jai.forums2...@gmail.com> wrote:

So I got this site generation working locally (had to fix a xooki script to 
make it work with Nashorn. The attached patch includes the fix). 

At this point, I need help to commit the newly generated doc fixes to the SVN. 
I’ve attached a patch file for it and will explain what it is doing.

The changes/patch relates to _one_ of the more important issues noted in the 
JIRA https://issues.apache.org/jira/browse/IVY-1542. That JIRA lists more than 
one issue with the latest docs. However, the missing .png and .css don’t 
directly contribute to anything noticeable, so I haven’t included it in this 
patch (and probably will look into it separately). The issue that this patch 
fixes is the more important one:

> Code examples are missing. About 2/3 of the way down the page are two code 
> examples that are rendering as just a black rectangle for me. The underlying 
> html looks like it has  tags with no content.

The way these tutorial docs are generated, during the build, it triggers the 
build of quickstart examples and dumps the logs into files. The log files are 
then referred to via xooki references and the contents of those log files are 
inlined within the div tags. So I went ahead and built these tutorials on 2.4.0 
tag of Ivy project, generated those logs and then regenerated the site with 
these logs in the relevant folder. The generated documentation now has these 
output inlined correctly in the quickstart and various other docs.

The attached patch was generated with 
https://svn.apache.org/repos/asf/ant/site/ as the root of the SVN checkout. So 
whoever is applying the patch will have to cd to that directory and then apply 
it. Let me know if you run into issues or if any changes are necessary in this 
patch.

As for the other two issues noted in that JIRA, I’m planning to remove 
references to the non-existent .css and .png files and submit that as a 
separate patch.

-Jaikiran

On 26-May-2017, at 10:39 AM, J Pai <jai.forums2...@gmail.com> wrote:

Thanks everyone for the inputs.

I’m trying to get a proper build going locally for the site generation (and 
running into issues). Once I get a proper build and the fixes to the issues 
noted in that JIRA, I’ll send out an update. Hopefully soon.

-Jaikiran
On 25-May-2017, at 5:26 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

The entire Ant site is in svn:
https://svn.apache.org/repos/asf/ant/site

There is a Readme.txt explaining a little bit stuff, but seems outdated since 
the migration to git. For Ivy and IvyDE, part of the site is built from the 
source for the projects. It used to be managed via svn:externals. Now there are 
ant tasks to run to the fetch of the sources. I have found an old discussion 
[1] we had about it which should help you.

By the way, the Ivy documentation is managed by an hand crafted html editor, 
xooki, just is good but quite slow. I did some work some time ago (2 years ago, 
time flies!) to try to migrate to asciidoc [2]. I can even see that locally I 
have a commit which for some reason I didn’t pushed. If we are still 
interested, I can revive this.

Nicolas

[1] 
http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html

<http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html>
[2] https://github.com/apache/ant-ivy/tree/xooki2asciidoc 
<https://github.com/apache/ant-ivy/tree/xooki2asciidoc>

> Le 25 mai 2017 à 06:12, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> What would be the process of having the live docs of Ivy project updated to 
> fix/update an issue in the documentation[1]? 
> 
> The quickstart documentation refers to certain log files that get 
> auto-generated during the doc build process. It looks like those log files 
> weren’t uploaded and are resulting in a blank text area showing up. I can run 
> the doc generation target locally (on 2.4.0 tag) and have someone upload 
> those files and see if shows up fine.
> 
> [1] https://issues.apache.org/jira/browse/IVY-1542
> 
> -Jaikiran
> -
> 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

IVY-1475 - cachefileset task and its inherent limitation

2017-06-01 Thread J Pai

One of the Ivy users has pointed out to an issue in cachefileset task[1] of Ivy 
here https://issues.apache.org/jira/browse/IVY-1475.

To summarize, the cachefileset task is expected to create a Ant Fileset of the 
resolved artifacts in the cache(s). Ant Fileset requires a (single) basedir to 
work on and the Ivy cachefileset has a piece of logic which tries to determine 
a common base directory for the resolved artifacts. It’s very much possible 
that there won’t be a common base directory for artifacts if the caches have 
been configured to be on multiple different filesystem roots, as noted in that 
JIRA. So essentially, to me, it looks like this cachefileset has an inherent 
deficiency which can’t really be fixed.

The user in that JIRA notes that we can deprecate this task (and also add a 
note about this limitation) in favour of “resources” task [2] which provides a 
similar functionality but is much more flexible and doesn’t suffer this 
limitation.

Any thoughts on how we should go about this JIRA and the cachefileset task?

[1] https://ant.apache.org/ivy/history/latest-milestone/use/cachefileset.html
[2] https://ant.apache.org/ivy/history/latest-milestone/use/resources.html

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

Re: Release notes for IVY-1528

2017-06-01 Thread J Pai

Thanks Nicolas.

-Jaikiran
On 01-Jun-2017, at 5:24 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

done.

Thanks
Nicolas

> Le 1 juin 2017 à 13:46, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> The PR for this issue https://issues.apache.org/jira/browse/IVY-1528 was 
> merged a few days back, but I think we forgot to resolve the JIRA and include 
> this in the release notes. Can someone with the access rights please do so?
> 
> -Jaikiran
> -
> 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



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

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

2017-06-01 Thread J Pai

The new organization being proposed “org.apache.ant” instead of “org/apache” is 
the right way to go IMO. It’s not just Ivy and applies to Maven co-ordinates 
(via pom.xml) as well. Ideally, they should match with each other. Using the 
org.apache.ant would make it fit with the groupId (in Maven land) and the 
organization naming schemes that I have seen for all the other projects out 
there.

-Jaikiran 
On 01-Jun-2017, at 2:27 AM, Maarten Coene  
wrote:

I don't see how Ivy could resolve the old ant-compress ivy.xml files without 
using very special artifact patterns.So my guess is that Ivy users of 
ant-compress just use the pom.xml file.

So I'd say we should fix the ivy.xml.
Maarten

 Van: Stefan Bodewig 
Aan: dev@ant.apache.org 
Verzonden: woensdag 31 mei 17:34 2017
Onderwerp: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

Hi all

this is an excerpt from the cancelled vote thread for the compress
antlib.

2017-05-31 16:40 GMT+02:00 Stefan Bodewig :

> I've just realized that the ivy.xml file I've published to Nexus has
> completely different coordinates from the one used in earlier
> releases. It used to be
> 
>module="ant" ...>
>  
> for 1.5 RC1 it is
> 
>module="ant-compress" ...>
>  
> and the current master branch would create
> 
>module="ant-compress"
>

Release notes for IVY-1528

2017-06-01 Thread J Pai

The PR for this issue https://issues.apache.org/jira/browse/IVY-1528 was merged 
a few days back, but I think we forgot to resolve the JIRA and include this in 
the release notes. Can someone with the access rights please do so?

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

Re: Ivy documentation with asciidoc

2017-05-31 Thread J Pai

One thing I just noticed in the generated adoc files is that “external” links 
that are part of the original xooki backed .html files are not being generated 
as links in the converted adoc. To see a couple of example, take a look at this 
hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache License” in this 
sentence:

> Ivy is open source and released under a very permissive Apache License.
> 

and the “features” in :

> Ivy has a lot of powerful features

are actually link references in the original xooki backed docs of the form 
[[license Apache License]] and [[features]].

-Jaikiran

On 31-May-2017, at 6:50 PM, J Pai <jai.forums2...@gmail.com> wrote:

I had some time today and decided to test this branch out locally. I was able 
to generate the docs without any hassle. The conversion works fine which is a 
great thing.

There are certain warning about the heading/section level we use in the 
generated adoc files, for top level heading:

> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
> title out of sequence: expected level 1, got level 2

but that’s pretty much it in terms of build time warnings/errors.

In one of my other mails I had noted that if not in this release then maybe in 
next release we can focus on this xooki to asciidoc conversion. But at that 
time I wasn’t aware that Nicolas had already done the bulk of this job by 
implementing this tool. 

So IMO, after fixing/finalizing some of those WARN related issues, we can 
probably just go ahead and use this tool to convert our current docs to adoc as 
a one time thing in our master branch. Till we are comfortable and are sure 
that the conversion is done fully, we can keep the old xooki backed docs as-is 
but just not update/add any new stuff in them. Given how nicely this tool works 
and the fact that it isn’t breaking anything, I don’t think we will have to 
maintain a separate branch to deal with this migration.

Any thoughts?

-Jaikiran

On 25-May-2017, at 7:55 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

> Le 25 mai 2017 à 16:17, Matt Sicker <boa...@gmail.com> a écrit :
> 
> Merge commits always spam the commits list which, while annoying, I've
> learned to mass-delete whenever it happens. ;)
> 
> I looked at some random changes and found a couple markup typos, but
> otherwise it looks like it converted well enough.

Yes, I have stopped one too. Some things will need to be manually fixed after 
the automatic conversion.

> I'm more familiar with the maven plugins for site management, so I'm not
> sure about the integration aspects, but worst case scenario, can't you just
> commit the parts to svnpubsub on release?

If you look at the menu on the left, it is present on each page, so it means 
that for any new file or deleted file, every page has to be regenerated. The 
consequence it that generating a page of the site has to be aware of the list 
of all the pages of the documentation.

But we can imagine that we uncouple the documentation, like it is being done 
for the old versions of the documentation, in the « history » section, by just 
having a link. So yes we could some manual copy and publish to svnpubsub on 
release.

Nicolas

> 
> On 25 May 2017 at 09:00, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:
> 
>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>> which I still find weird, I would expect just one mail about the commit of
>> the merge.
>> 
>> I can see the current status of the transformation of the xooki source
>> into asciidoc source and then the generated html from that here:
>> http://hibnet.org/tmp/ivy-asciidoc/index.html <http://hibnet.org/tmp/ivy-
>> asciidoc/index.html>
>> 
>> It seems pretty good, but I didn’t looked to most of the pages.
>> 
>> Before going further, we need to figure out how it would be integrated to
>> the website since it is also managed by xooki. The site and the
>> documentation are tidily coupled by the toc which is managed by xooki.
>> 
>> Nicolas
>> 
>> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>

-
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 documentation with asciidoc

2017-05-31 Thread J Pai

I had some time today and decided to test this branch out locally. I was able 
to generate the docs without any hassle. The conversion works fine which is a 
great thing.

There are certain warning about the heading/section level we use in the 
generated adoc files, for top level heading:

> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
> title out of sequence: expected level 1, got level 2

but that’s pretty much it in terms of build time warnings/errors.

In one of my other mails I had noted that if not in this release then maybe in 
next release we can focus on this xooki to asciidoc conversion. But at that 
time I wasn’t aware that Nicolas had already done the bulk of this job by 
implementing this tool. 

So IMO, after fixing/finalizing some of those WARN related issues, we can 
probably just go ahead and use this tool to convert our current docs to adoc as 
a one time thing in our master branch. Till we are comfortable and are sure 
that the conversion is done fully, we can keep the old xooki backed docs as-is 
but just not update/add any new stuff in them. Given how nicely this tool works 
and the fact that it isn’t breaking anything, I don’t think we will have to 
maintain a separate branch to deal with this migration.

Any thoughts?

-Jaikiran

On 25-May-2017, at 7:55 PM, Nicolas Lalevée  wrote:

> Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
> 
> Merge commits always spam the commits list which, while annoying, I've
> learned to mass-delete whenever it happens. ;)
> 
> I looked at some random changes and found a couple markup typos, but
> otherwise it looks like it converted well enough.

Yes, I have stopped one too. Some things will need to be manually fixed after 
the automatic conversion.

> I'm more familiar with the maven plugins for site management, so I'm not
> sure about the integration aspects, but worst case scenario, can't you just
> commit the parts to svnpubsub on release?

If you look at the menu on the left, it is present on each page, so it means 
that for any new file or deleted file, every page has to be regenerated. The 
consequence it that generating a page of the site has to be aware of the list 
of all the pages of the documentation.

But we can imagine that we uncouple the documentation, like it is being done 
for the old versions of the documentation, in the « history » section, by just 
having a link. So yes we could some manual copy and publish to svnpubsub on 
release.

Nicolas

> 
> On 25 May 2017 at 09:00, Nicolas Lalevée  wrote:
> 
>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>> which I still find weird, I would expect just one mail about the commit of
>> the merge.
>> 
>> I can see the current status of the transformation of the xooki source
>> into asciidoc source and then the generated html from that here:
>> http://hibnet.org/tmp/ivy-asciidoc/index.html > asciidoc/index.html>
>> 
>> It seems pretty good, but I didn’t looked to most of the pages.
>> 
>> Before going further, we need to figure out how it would be integrated to
>> the website since it is also managed by xooki. The site and the
>> documentation are tidily coupled by the toc which is managed by xooki.
>> 
>> Nicolas
>> 
>> 
> 
> 
> -- 
> Matt Sicker 

-
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: Problems Releaseing Antlibs

2017-05-31 Thread J Pai

Just had a look at that ivysettings-nexus.xml file. You are right, changing 
that file should fix it.

-Jaikiran
On 31-May-2017, at 5:43 PM, Stefan Bodewig <bode...@apache.org> wrote:

On 2017-05-31, J Pai wrote:

> These are the changes (which incorporates Gintas suggestion) that
> might help get us past the upload issue.

I've only modified ivysettings-nexus.xml obtained from common (locally,
not pushed, yet) and that seems to have done the trick. I didn't have to
change prepare-upload or upload.xml back from dots to slashes.

Thanks

   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: Problems Releaseing Antlibs

2017-05-31 Thread J Pai

These are the changes (which incorporates Gintas suggestion) that might help 
get us past the upload issue.

Change to ivy.xml of compress project:

diff --git a/ivy.xml b/ivy.xml
index eb034ac..6c5e823 100644
--- a/ivy.xml
+++ b/ivy.xml
@@ -18,7 +18,7 @@

 -->
 
-  
 
+  
value="${build.javarepository}/org/apache/ant/${artifact.name}/${artifact.version}"/>
 
 
 
diff --git a/upload.xml b/upload.xml
index d4910e6..a0165dc 100644
--- a/upload.xml
+++ b/upload.xml
@@ -35,7 +35,7 @@
 
 
 
   


Let us know if this doesn’t help.

-Jaikiran

On 31-May-2017, at 4:41 PM, Gintautas Grigelionis  
wrote:

Use different pattern [orgPath] rather than [organisation]

Gintas

http://ant.apache.org/ivy/history/latest-milestone/concept.html

2017-05-31 11:36 GMT+02:00 Stefan Bodewig :

> On 2017-05-31, Stefan Bodewig wrote:
> 
>> I'll fix common first (and update Ivy as I go, then fix Compress and
>> do a test deploy that I can easily drop again.
> 
> /devel/ASF/ant-antlibs-compress/common/upload.xml:40: impossible to
> publish artifacts for org.apache.ant#ant-compress;1.5.1:
> java.io.IOException: PUT operation to URL https://repository.apache.org/
> service/local/staging/deploy/maven2/org.apache.ant/ant-
> compress/ant-compress/1.5.1/ant-compress-1.5.1.pom failed with status
> code 400: Bad Request
> 
> I'm afraid Nexus doesn't like the organization. I just had a look at
> Ant's own ivy.xml[1]. It uses organisation="org/apache" (slashes rather
> than dots). I'll play with some variations later.
> 
> Stefan
> 
> [1] https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=
> release/ivy.xml
> 
> -
> 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] Increase minimum Java version for Ivy to Java7

2017-05-29 Thread J Pai

+1

-Jaikiran
On 29-May-2017, at 4:59 PM, Nicolas Lalevée  wrote:

+1

Nicolas


> Le 29 mai 2017 à 13:15, Jan Matèrne  a écrit :
> 
> Ivy uses Java7 from Ivy-2.5.x, so let us increase the minimum Java version
> for IvyDE from 1.4 [2] to Java7, too.
> 
> According to Eclipse Wiki [2] this will result in requiring Eclipse 4.4
> (from 2014) or newer.
> 
> 
> 
> According to the bylaws [3] this vote is open for one week (until
> 05.06.2017).
> 
> 
> 
> 
> 
> I'll start with +1.
> 
> 
> 
> 
> 
> Jan
> 
> 
> 
> [1]
> http://ant.apache.org/ivy/ivyde/history/latest-milestone/compatibility.html
> 
> [2] https://wiki.eclipse.org/Eclipse/Installation
> 
> [3]   http://ant.apache.org/bylaws.html
> 
> 
> 


-
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: PR-33: problems

2017-05-29 Thread J Pai

IMO, for each of these public classes/methods/fields that we are fixing for 
typos, we should mark them @Deprecated (and add a @deprecated javadoc too and 
point to the new field/method/class) and introduce the rightly named 
class/method/field. For methods it’s straightforward, the deprecated method 
internally calls the new method. For fields too it’s straightforward. The 
deprecated field uses the value of the new field. For classes, I think we can 
copy over the existing class into the new one and leave around the existing one 
just for possible external references (that we can’t control off) and migrate 
all internal references to the new one.

At some point, in some future version of Ivy, we remove/delete these deprecated 
method/field/class.


-Jaikiran


On 29-May-2017, at 1:43 PM, Jan Matèrne  wrote:

I did a review of  
https://github.com/apache/ant-ivy/pull/33

Here are the points I have problems with, so I want to discuss them here.

Basically it's about breaking BC. So how to deal with that?





Jan





Fixing the spell error in DelegateHandler$ChildElementHandler
(s/childHanlded/childHandled/) means breaking beakward compatiblity. 

We could introduce a delegetate for that:

 /** for BC */

 @Deprecated

 public void childHanlded(DH child) throws SAXParseException {

   childHandled(DH child);

 }

While refactoring you have renamed all occurences in the Ivy codebase. 

On the other hand I don't know the impact (maybe outside of Ivy). I'll bring
that to the dev-list.





src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the
public constant DEFAULT_BUNLDE_FILTER also means breaking BC.





src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes the
(IMO unneccessary) ParseException. But because it is a checked Exception we
break BC.





renaming EncrytedProperties to EncryptedProperties means breaking BC. If
required we could introduce a delegating class or a subclass.





ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If
required we could introduce a delegating method.











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

Re: IVY-1485, resolve report and resolved versions

2017-05-26 Thread J Pai

Thank you very much Nicolas for digging more into this and getting hold of 
these details. What you explain, backed by the details, makes clear sense.

I will attempt to go with this option that you suggest:

> - drop this property file, make the xml report always produced, and make the 
> deliver read the report rather than the property file.

From looking at the code and documentation, the option that decides whether to 
create the XML report seems to be an internal only option (in Ivy 2.x world) 
i.e. not exposed or documented as something that the user can fiddle with. 
That’s a good thing since removing it or fiddling with its semantics, won’t 
affect the users.

P.S: I don’t mean to step on your toes here if you were planning to work on 
this. If not, I’ll gladly try and come up with the suggested fix.

-Jaikiran

On 26-May-2017, at 2:20 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

After some digging, I found out that the resolved revisions property file is 
very old (git is awesome, even better within sourcetree). It is so old that at 
that time the xml resolve report didn’t exist. And this property file seems to 
have been created just in order to make the deliver task work [1]. And a 
comment still state this too [2]. And the purpose of the lines from 248 to 326 
are about to compute these versions and write them down, it can be extracted in 
a function without side effect.

So most probably this property file is redundant with the xml resolve report. 
But the thing is the resolve may not be produced, it is an option [3], 
defaulting to true [4].

Two options:
- continue to support the property file and correctly produce it to fix 
IVY-1485 [5].
- drop this property file, make the xml report always produced, and make the 
deliver read the report rather than the property file.

Makes sense ?

Nicolas

[1] 
https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325

<https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325>
[2] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247

<https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247>
[3] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338

<https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338>
[4] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99

<https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99>
[5] https://issues.apache.org/jira/browse/IVY-1485 
<https://issues.apache.org/jira/browse/IVY-1485>
> Le 25 mai 2017 à 12:11, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit :
> 
> Thank you very much Jaikiran for your detailed explanation.
> 
> I have to admit that I don’t know the answer to which is the source of truth 
> about the resolution report. I have also wondered why the resolve report 
> should have to be always wrote and then read from file. I’ll try to get an 
> answer myself too while reading the code.
> 
> Nicolas
> 
>> Le 22 mai 2017 à 07:37, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> One other thing about this issue - this is reproducible (as shown in the 
>> test case) with static revisions too and isn’t specific to any dynamic 
>> revision resolution.
>> 
>> -Jaikiran
>> On 22-May-2017, at 11:02 AM, J Pai <jai.forums2...@gmail.com> wrote:
>> 
>> I have had a look at that issue, this last week and I have been able to 
>> reproduce it in a simple test case[1]. I kind of understand what the issue 
>> is in there, but given my lack of knowledge of the Ivy codebase, I haven’t 
>> been able to figure how to fix this correctly. In fact, this issue is what 
>> prompted me to ask this question [2] in the dev list a day or so back, since 
>> basically comes down to those files. Here’s my understanding of the problem 
>> (backed by that test case[1] which reproduces it).
>> 
>> Imagine you have a module org:hello-world and imagine it has 2 
>> configurations conf1 and conf2. Now consider the case where this hello-world 
>> module depends on org:module1:1.0 in conf1 (a direct dependency) and on 
>> org:module2:1.0 in conf2 (a direct dependency). That translates to a module 
>> descriptor like:
>> 
>> 
>> >   module="hello-world"
>>   revision="1.2.3"
>> 
>> />
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Now take this one step further and consider that org:module2:1.0 (th

Re: Ivy website - fixing a Quickstart documentation live

2017-05-26 Thread J Pai

So I got this site generation working locally (had to fix a xooki script to 
make it work with Nashorn. The attached patch includes the fix). 

At this point, I need help to commit the newly generated doc fixes to the SVN. 
I’ve attached a patch file for it and will explain what it is doing.

The changes/patch relates to _one_ of the more important issues noted in the 
JIRA https://issues.apache.org/jira/browse/IVY-1542. That JIRA lists more than 
one issue with the latest docs. However, the missing .png and .css don’t 
directly contribute to anything noticeable, so I haven’t included it in this 
patch (and probably will look into it separately). The issue that this patch 
fixes is the more important one:

> Code examples are missing. About 2/3 of the way down the page are two code 
> examples that are rendering as just a black rectangle for me. The underlying 
> html looks like it has  tags with no content.

The way these tutorial docs are generated, during the build, it triggers the 
build of quickstart examples and dumps the logs into files. The log files are 
then referred to via xooki references and the contents of those log files are 
inlined within the div tags. So I went ahead and built these tutorials on 2.4.0 
tag of Ivy project, generated those logs and then regenerated the site with 
these logs in the relevant folder. The generated documentation now has these 
output inlined correctly in the quickstart and various other docs.

The attached patch was generated with 
https://svn.apache.org/repos/asf/ant/site/ as the root of the SVN checkout. So 
whoever is applying the patch will have to cd to that directory and then apply 
it. Let me know if you run into issues or if any changes are necessary in this 
patch.

As for the other two issues noted in that JIRA, I’m planning to remove 
references to the non-existent .css and .png files and submit that as a 
separate patch.

-Jaikiran

On 26-May-2017, at 10:39 AM, J Pai <jai.forums2...@gmail.com> wrote:

Thanks everyone for the inputs.

I’m trying to get a proper build going locally for the site generation (and 
running into issues). Once I get a proper build and the fixes to the issues 
noted in that JIRA, I’ll send out an update. Hopefully soon.

-Jaikiran
On 25-May-2017, at 5:26 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

The entire Ant site is in svn:
https://svn.apache.org/repos/asf/ant/site

There is a Readme.txt explaining a little bit stuff, but seems outdated since 
the migration to git. For Ivy and IvyDE, part of the site is built from the 
source for the projects. It used to be managed via svn:externals. Now there are 
ant tasks to run to the fetch of the sources. I have found an old discussion 
[1] we had about it which should help you.

By the way, the Ivy documentation is managed by an hand crafted html editor, 
xooki, just is good but quite slow. I did some work some time ago (2 years ago, 
time flies!) to try to migrate to asciidoc [2]. I can even see that locally I 
have a commit which for some reason I didn’t pushed. If we are still 
interested, I can revive this.

Nicolas

[1] 
http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html

<http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html>
[2] https://github.com/apache/ant-ivy/tree/xooki2asciidoc 
<https://github.com/apache/ant-ivy/tree/xooki2asciidoc>

> Le 25 mai 2017 à 06:12, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> What would be the process of having the live docs of Ivy project updated to 
> fix/update an issue in the documentation[1]? 
> 
> The quickstart documentation refers to certain log files that get 
> auto-generated during the doc build process. It looks like those log files 
> weren’t uploaded and are resulting in a blank text area showing up. I can run 
> the doc generation target locally (on 2.4.0 tag) and have someone upload 
> those files and see if shows up fine.
> 
> [1] https://issues.apache.org/jira/browse/IVY-1542
> 
> -Jaikiran
> -
> 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 website - fixing a Quickstart documentation live

2017-05-25 Thread J Pai

Thanks everyone for the inputs.

I’m trying to get a proper build going locally for the site generation (and 
running into issues). Once I get a proper build and the fixes to the issues 
noted in that JIRA, I’ll send out an update. Hopefully soon.

-Jaikiran
On 25-May-2017, at 5:26 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

The entire Ant site is in svn:
https://svn.apache.org/repos/asf/ant/site

There is a Readme.txt explaining a little bit stuff, but seems outdated since 
the migration to git. For Ivy and IvyDE, part of the site is built from the 
source for the projects. It used to be managed via svn:externals. Now there are 
ant tasks to run to the fetch of the sources. I have found an old discussion 
[1] we had about it which should help you.

By the way, the Ivy documentation is managed by an hand crafted html editor, 
xooki, just is good but quite slow. I did some work some time ago (2 years ago, 
time flies!) to try to migrate to asciidoc [2]. I can even see that locally I 
have a commit which for some reason I didn’t pushed. If we are still 
interested, I can revive this.

Nicolas

[1] 
http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html

<http://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html>
[2] https://github.com/apache/ant-ivy/tree/xooki2asciidoc 
<https://github.com/apache/ant-ivy/tree/xooki2asciidoc>

> Le 25 mai 2017 à 06:12, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> What would be the process of having the live docs of Ivy project updated to 
> fix/update an issue in the documentation[1]? 
> 
> The quickstart documentation refers to certain log files that get 
> auto-generated during the doc build process. It looks like those log files 
> weren’t uploaded and are resulting in a blank text area showing up. I can run 
> the doc generation target locally (on 2.4.0 tag) and have someone upload 
> those files and see if shows up fine.
> 
> [1] https://issues.apache.org/jira/browse/IVY-1542
> 
> -Jaikiran
> -
> 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: IVYDE-382 proposed patch

2017-05-25 Thread J Pai

Hi Alexander,

Thank you for volunteering to provide this feature patch. I had a look a the
repo you pointed to and read the README. It does seem to contain a good amount
of work in that branch in multiple commits.

To make it easier for whoever will decide about merging these to upstream
ant-ivyde project, would it to be possible for you to do the following:

Once the PRs are submitted, I’m sure one or more members of the development
team who have relevant knowledge of Eclipse and the project will review this
and either merge it or provide inputs.

Thanks again for this, both Ivy and IvyDE project has been stagnant for a while
and with contributions like these, we should be able to release out a new
version soon.

-Jaikiran

On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:

Dear Sir or Madam,

Yours sincerely,

Alexander Blaas

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

Re: Ivy website - fixing a Quickstart documentation live

2017-05-25 Thread J Pai

On 25-May-2017, at 5:26 PM, Nicolas Lalevée  wrote:

> By the way, the Ivy documentation is managed by an hand crafted html editor, 
> xooki, just is good but quite slow. I did some work some time ago (2 years 
> ago, time flies!) to try to migrate to asciidoc [2]. I can even see that 
> locally I have a commit which for some reason I didn’t pushed. If we are 
> still interested, I can revive this.
> 

I’m very much interested in having the docs moved to asciidoc. I use it in 
almost every other project I deal with and it’s a big motivation to continue to 
write documentation and is definitely a big improvement on what we currently 
have. It doesn’t have to be something that we push/force in this release, but 
if we can transition to this documentation system, it’s going to be great.

-Jaikiran

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

Ivy website - fixing a Quickstart documentation live

2017-05-24 Thread J Pai

What would be the process of having the live docs of Ivy project updated to 
fix/update an issue in the documentation[1]? 

The quickstart documentation refers to certain log files that get 
auto-generated during the doc build process. It looks like those log files 
weren’t uploaded and are resulting in a blank text area showing up. I can run 
the doc generation target locally (on 2.4.0 tag) and have someone upload those 
files and see if shows up fine.

[1] https://issues.apache.org/jira/browse/IVY-1542

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

Re: Buildjob: IvyDE

2017-05-23 Thread J Pai

For some reason, this PR https://github.com/apache/ant-ivyde/pull/2 hasn’t yet 
triggered that IvyDE-Github job 

-Jaikiran
On 23-May-2017, at 12:54 AM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

I changed the buildjobs for IvyDE + IvyDE-Github to use Java7(latest).
But I prefer to use the lowest Java version we have defined as minimum. ;)

Jan

> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 22. Mai 2017 15:09
> An: Ant Developers List
> Betreff: Re: Buildjob: IvyDE
> 
> Is there a chance you could trigger this build to run using Java 7? I
> read up a few JIRA posts for the INFRA project in issues.apache.org and
> they seem to indicate that this probably will work fine with builds
> that use Java 7. I’m not 100% sure though.
> 
> -Jaikiran
> On 22-May-2017, at 6:30 PM, J Pai <jai.forums2...@gmail.com> wrote:
> 
> That specific line in the build.xml[1] of the IvyDE project is trying
> to “get” the ivy.jar from a URL. In this case, it’s trying to fetch it
> from:
> 
>> [get] Getting:
>> 
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/a
>> rtifact/jars/ivy.jar
> 
> Since it’s https backed, there’s a SSL handshake going on via this
> build process which is running on JRE 6 (upgrading to JRE 7 won’t solve
> the issue) and the builds.apache.org system while retrieving the file.
> It looks like as noted here [2] that builds.apache.org is presenting a
> certificate which JRE versions before JRE 8 don’t allow. The workaround
> presented in that FAQ is to switch the settings on the “server” which
> in this case would be builds.apache.org to use a different cipher list.
> 
> I’m not sure, if we will be allowed to do that and I’m curious how
> other builds (not necessary Ivy project builds) that need to fetch
> something from builds.apache.org via https and JRE <=7 get past this
> currently. Either way, I think this is something that we will have to
> ask the Apache infra team for their inputs.
> 
> 
> [1] https://github.com/apache/ant-ivyde/blob/master/build.xml#L277
> [2] http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
> 
> 
> -Jaikiran
> On 22-May-2017, at 2:04 PM, Jan Matèrne <j...@materne.de> wrote:
> 
> I copied the IvyDE buildjob to have github support here.
> 
> https://builds.apache.org/view/A/view/Ant/job/IvyDE-GithubPR/
> 
> 
> 
> I changed IvyDE and IvyDE to not use "Ant latest" instead "Ant 1.9.9",
> so it will work on Java<8.
> 
> 
> 
> I started IvyDE and it gives me an error I could not interpret:
> 
> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console
> 
> 
> 
> compute-ivy-bundle-version:
>  [mkdir] Created dir:
> /home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/jar
>[get] Getting:
> <https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/a
> rtifa
> ct/jars/ivy.jar>
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/ar
> tifac
> t/jars/ivy.jar
>[get] To: /home/jenkins/jenkins-
> slave/workspace/IvyDE/work/ivy/ivy.jar
>[get] Error getting
> <https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/a
> rtifa
> ct/jars/ivy.jar>
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/ar
> tifac
> t/jars/ivy.jar to
> /home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/ivy.jar
> 
> 
> 
> BUILD FAILED
> /home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:561: The
> following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:277:
> javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
> generate DH keypair
>  at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:174
> 7)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:170
> 8)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImp
> l.jav
> a:1691)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl
> .java
> :1222)
>  at
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl
> .java
> :1199)
>  at
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:43
> 4)
>  at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(A
> bstra
> ctDelegateHttpsURLConnection.java:166)
>  at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConne
> ction
> Impl.java:133)
>  at
> org.apache.tools.ant.taskde

Re: Buildjob: IvyDE

2017-05-22 Thread J Pai

Is there a chance you could trigger this build to run using Java 7? I read up a 
few JIRA posts for the INFRA project in issues.apache.org and they seem to 
indicate that this probably will work fine with builds that use Java 7. I’m not 
100% sure though.

-Jaikiran
On 22-May-2017, at 6:30 PM, J Pai <jai.forums2...@gmail.com> wrote:

That specific line in the build.xml[1] of the IvyDE project is trying to “get” 
the ivy.jar from a URL. In this case, it’s trying to fetch it from:

> [get] Getting: 
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifact/jars/ivy.jar

Since it’s https backed, there’s a SSL handshake going on via this build 
process which is running on JRE 6 (upgrading to JRE 7 won’t solve the issue) 
and the builds.apache.org system while retrieving the file. It looks like as 
noted here [2] that builds.apache.org is presenting a certificate which JRE 
versions before JRE 8 don’t allow. The workaround presented in that FAQ is to 
switch the settings on the “server” which in this case would be 
builds.apache.org to use a different cipher list.

I’m not sure, if we will be allowed to do that and I’m curious how other builds 
(not necessary Ivy project builds) that need to fetch something from 
builds.apache.org via https and JRE <=7 get past this currently. Either way, I 
think this is something that we will have to ask the Apache infra team for 
their inputs.

[1] https://github.com/apache/ant-ivyde/blob/master/build.xml#L277
[2] http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

-Jaikiran
On 22-May-2017, at 2:04 PM, Jan Matèrne <j...@materne.de> wrote:

I copied the IvyDE buildjob to have github support here.

https://builds.apache.org/view/A/view/Ant/job/IvyDE-GithubPR/

I changed IvyDE and IvyDE to not use "Ant latest" instead "Ant 1.9.9", so it
will work on Java<8.

I started IvyDE and it gives me an error I could not interpret:

https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console

compute-ivy-bundle-version:
  [mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/jar
[get] Getting:
<https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifa
ct/jars/ivy.jar>
https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifac
t/jars/ivy.jar
[get] To: /home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/ivy.jar
[get] Error getting
<https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifa
ct/jars/ivy.jar>
https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifac
t/jars/ivy.jar to
/home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/ivy.jar

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:561: The following
error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:277:
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate
DH keypair
  at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.jav
a:1691)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1222)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1199)
  at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
  at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Abstra
ctDelegateHttpsURLConnection.java:166)
  at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnection
Impl.java:133)
  at
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:737)
  at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:650)
  at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:640)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
  at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:114)
  at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandsh
aker.java:559)
  at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshake
r.java:186)
  at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
  at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943
)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocket
Impl.java:1188)
  at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1215)
  ... 7 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must
be multiple of 64, and can only range from 512 to 1024 (inclusive)

Re: Buildjob: IvyDE

2017-05-22 Thread J Pai

That specific line in the build.xml[1] of the IvyDE project is trying to “get” 
the ivy.jar from a URL. In this case, it’s trying to fetch it from:

> [get] Getting: 
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifact/jars/ivy.jar

Since it’s https backed, there’s a SSL handshake going on via this build 
process which is running on JRE 6 (upgrading to JRE 7 won’t solve the issue) 
and the builds.apache.org system while retrieving the file. It looks like as 
noted here [2] that builds.apache.org is presenting a certificate which JRE 
versions before JRE 8 don’t allow. The workaround presented in that FAQ is to 
switch the settings on the “server” which in this case would be 
builds.apache.org to use a different cipher list.

I’m not sure, if we will be allowed to do that and I’m curious how other builds 
(not necessary Ivy project builds) that need to fetch something from 
builds.apache.org via https and JRE <=7 get past this currently. Either way, I 
think this is something that we will have to ask the Apache infra team for 
their inputs.

[1] https://github.com/apache/ant-ivyde/blob/master/build.xml#L277
[2] http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh

-Jaikiran
On 22-May-2017, at 2:04 PM, Jan Matèrne  wrote:

I copied the IvyDE buildjob to have github support here.

https://builds.apache.org/view/A/view/Ant/job/IvyDE-GithubPR/

I changed IvyDE and IvyDE to not use "Ant latest" instead "Ant 1.9.9", so it
will work on Java<8.

I started IvyDE and it gives me an error I could not interpret:

https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/console

compute-ivy-bundle-version:
   [mkdir] Created dir:
/home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/jar
 [get] Getting:

https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifac
t/jars/ivy.jar
 [get] To: /home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/ivy.jar
 [get] Error getting

https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifac
t/jars/ivy.jar to
/home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/ivy.jar

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:561: The following
error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/IvyDE/build.xml:277:
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate
DH keypair
   at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.jav
a:1691)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1222)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1199)
   at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
   at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Abstra
ctDelegateHttpsURLConnection.java:166)
   at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnection
Impl.java:133)
   at
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:737)
   at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:650)
   at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:640)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
   at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:114)
   at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandsh
aker.java:559)
   at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshake
r.java:186)
   at
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
   at
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943
)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocket
Impl.java:1188)
   at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java
:1215)
   ... 7 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must
be multiple of 64, and can only range from 512 to 1024 (inclusive)
   at
com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
   at
java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627
)
   at com.sun.net.ssl.internal.ssl.DHCrypt.(DHCrypt.java:107)
   ... 14 more

Jan

-
To unsubscribe, e-mail:

Re: Ivy - Buildjobs/PreCommit

2017-05-22 Thread J Pai

It looks like there might be some issue with the matrix job(s) 
https://builds.apache.org/job/Ivy-GithubPR-Matrix/2/console

From what I understand of that log, it seems like the parent matrix job (the 
one above) is correctly checking out the commit from the submitted PR:

 > Checking out Revision c1765c71ba4394597409de790bf4529ff97e866e (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c1765c71ba4394597409de790bf4529ff97e866e
 > git rev-parse origin/master^{commit} # timeout=10
 > git rev-list 239bc0b04a95d6c0f82e59c513de36d68c033c6a # timeout=10

However, it then hands off the job execution to individual Windows/Linux jobs 
and those jobs 
https://builds.apache.org/job/Ivy-GithubPR-Matrix/jdk=JDK%201.7%20(latest),os=ubuntu/2/console
 don’t seem to be able to checkout the commit(s) from the PR and fail with 
error like:

> Fetching upstream changes from https://github.com/apache/ant-ivy/

 > git --version # timeout=10
 > git fetch --tags --progress 
https://github.com/apache/ant-ivy/
 +refs/heads/*:refs/remotes/origin/*
Checking out Revision c1765c71ba4394597409de790bf4529ff97e866e (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c1765c71ba4394597409de790bf4529ff97e866e
FATAL: Could not checkout c1765c71ba4394597409de790bf4529ff97e866e

hudson.plugins.git.GitException
: Command "git checkout -f c1765c71ba4394597409de790bf4529ff97e866e" returned 
status code 128:
stdout: 
stderr: fatal: reference is not a tree: c1765c71ba4394597409de790bf4529ff97e866e

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1866)


-Jaikiran

On 22-May-2017, at 12:25 PM, Jan Matèrne (jhm)  wrote:

>> On a related note, while we are at this - does Apache infra allow the
> jobs to be run against Windows OS Jenkins agents as well? There are a
> few issues specifically reported against Windows OS and having the job
> run against linux and Windows OS should give a decent coverage for the
> upstream code.
> 
> In Jenkins there is the concept of « Matrix » job.
> Here is the ones for Ant:
> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
> Windows/  Matrix-1.9.x-Windows/>
> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
> Linux/  1.9.x-Linux/>
> AFAIR, it used to be able to do on several different OS. I don’t know
> why they are split.
> 
> And I don’t know if it is possible to do it while pulling a PR from
> github.


New buildjob "Ivy-GithubPR-Matrix". I deactivated the old (so we could easily 
switch back).
https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR-Matrix/
Basically a copy of the old job:
* discard old build jobs (keep 10)
* git merge support: fail the build if push fails
* github project: git://github.com/apache/ant-ivy.git
* git
 -- repository: git://github.com/apache/ant-ivy.git
 -- branches: */master (= default)
 -- clean before checkout
 -- recursively update submodules
 -- build commits submitted for validated merge (= PR support)
* start build: build pull request to the repository (= PR support)
* configuration matrix
 -- JDK: JDK 1.7 (latest), JDK 1.8 (latest), JDK 9 b156 with jigsaw
 -- os: label expression = ["ubuntu", "Windows"]
* abort the build if it's stuck: absolute 20 minutes
* Lock: Ant
* build
 -- ant(standard): clean coverage-report
* publish junit: build/test-report/**


Jan


-
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 - Goals for the upcoming release?

2017-05-21 Thread J Pai

One other thing about this issue - this is reproducible (as shown in the test 
case) with static revisions too and isn’t specific to any dynamic revision 
resolution.

-Jaikiran
On 22-May-2017, at 11:02 AM, J Pai <jai.forums2...@gmail.com> wrote:

I have had a look at that issue, this last week and I have been able to 
reproduce it in a simple test case[1]. I kind of understand what the issue is 
in there, but given my lack of knowledge of the Ivy codebase, I haven’t been 
able to figure how to fix this correctly. In fact, this issue is what prompted 
me to ask this question [2] in the dev list a day or so back, since basically 
comes down to those files. Here’s my understanding of the problem (backed by 
that test case[1] which reproduces it).

Imagine you have a module org:hello-world and imagine it has 2 configurations 
conf1 and conf2. Now consider the case where this hello-world module depends on 
org:module1:1.0 in conf1 (a direct dependency) and on org:module2:1.0 in conf2 
(a direct dependency). That translates to a module descriptor like:

Now take this one step further and consider that org:module2:1.0 (that 
hello-world depends on, in conf2) has a dependency of its own on 
org:module1:2.0. So module2’s module descriptor looks like:

So ultimately, when you resolve the hello-world module, you expect it to have 
org:module1:1.0 as an dependency in conf1 and org:module1:2.0 as an dependency 
in conf2 (transitively via org:module2:1.0).

Does the resolve work as expected for this use case? Yes it does and the 
resolution pulls in the right set of dependencies in the right configurations. 
Internally it creates resolution report (as an xml) plus a resolution 
properties file for this resolution. No (obvious/apparent) issues at this 
point. 

Now, let’s say a “deliver” is triggered against this resolution, for conf1. 
What I would expect is, that it would deliver a file for hello-world which then 
has a dependency on org:module1:1.0 in conf1 (because that’s what it was 
correctly resolved to previously). However, the delivered file instead has a 
dependency on org:module1:2.0 in conf1 and I believe that’s the issue being 
reported in that JIRA.

So is this a bug in the deliver task itself? I don’t think so. So far what I 
have narrowed it down to is that the resolve task that happened previously 
creates more than one representation of that resolution (one a resolution 
report xml and one a resolution properties file). The resolution report XML has 
all the necessary and correct information about which dependency (either direct 
or transitive) belongs to which configuration. However, the resolution 
properties file contains the “wrong” dependency for module1 - it stores the 
dependency as org:module1:2.0. I am not even sure if the properties file is 
capable enough of supporting/understanding dependencies per configuration. The 
deliver task then uses this properties file (instead of the resolution report 
XML) to decide what dependencies to write out. I’m guessing some other 
(post-resolve) tasks too use this properties file for their decision making, so 
this really boils down to a potential bug in what gets written out to this 
resolution properties file, during resolve.

Unfortunately, my reading of the code so far hasn’t given me answers on what 
role this file plays and why can’t it be just skipped and the resolution report 
XML instead be considered the single source of truth. Hence that question [2] 
in the dev list. I can’t really think of a solution/fix for this issue, without 
reading more of the current Ivy code to understand what role these files play.

[1] 
https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
[2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html

-Jaikiran

On 21-May-2017, at 10:49 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

One thing though.

This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485 
<https://issues.apache.org/jira/browse/IVY-1485>
It would be a shame if it is not fixed within the next release.

The issue and the fix are not easy to understand. Any review will be welcomed.

Nicolas

> Le 21 mai 2017 à 18:46, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit :
> 
> 
>> Le 21 mai 2017 à 16:28, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
>> them and merging those that were good enough. 
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
>>

Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai

I have had a look at that issue, this last week and I have been able to 
reproduce it in a simple test case[1]. I kind of understand what the issue is 
in there, but given my lack of knowledge of the Ivy codebase, I haven’t been 
able to figure how to fix this correctly. In fact, this issue is what prompted 
me to ask this question [2] in the dev list a day or so back, since basically 
comes down to those files. Here’s my understanding of the problem (backed by 
that test case[1] which reproduces it).

Imagine you have a module org:hello-world and imagine it has 2 configurations 
conf1 and conf2. Now consider the case where this hello-world module depends on 
org:module1:1.0 in conf1 (a direct dependency) and on org:module2:1.0 in conf2 
(a direct dependency). That translates to a module descriptor like:

Now take this one step further and consider that org:module2:1.0 (that 
hello-world depends on, in conf2) has a dependency of its own on 
org:module1:2.0. So module2’s module descriptor looks like:

So ultimately, when you resolve the hello-world module, you expect it to have 
org:module1:1.0 as an dependency in conf1 and org:module1:2.0 as an dependency 
in conf2 (transitively via org:module2:1.0).

Does the resolve work as expected for this use case? Yes it does and the 
resolution pulls in the right set of dependencies in the right configurations. 
Internally it creates resolution report (as an xml) plus a resolution 
properties file for this resolution. No (obvious/apparent) issues at this 
point. 

Now, let’s say a “deliver” is triggered against this resolution, for conf1. 
What I would expect is, that it would deliver a file for hello-world which then 
has a dependency on org:module1:1.0 in conf1 (because that’s what it was 
correctly resolved to previously). However, the delivered file instead has a 
dependency on org:module1:2.0 in conf1 and I believe that’s the issue being 
reported in that JIRA.

So is this a bug in the deliver task itself? I don’t think so. So far what I 
have narrowed it down to is that the resolve task that happened previously 
creates more than one representation of that resolution (one a resolution 
report xml and one a resolution properties file). The resolution report XML has 
all the necessary and correct information about which dependency (either direct 
or transitive) belongs to which configuration. However, the resolution 
properties file contains the “wrong” dependency for module1 - it stores the 
dependency as org:module1:2.0. I am not even sure if the properties file is 
capable enough of supporting/understanding dependencies per configuration. The 
deliver task then uses this properties file (instead of the resolution report 
XML) to decide what dependencies to write out. I’m guessing some other 
(post-resolve) tasks too use this properties file for their decision making, so 
this really boils down to a potential bug in what gets written out to this 
resolution properties file, during resolve.

Unfortunately, my reading of the code so far hasn’t given me answers on what 
role this file plays and why can’t it be just skipped and the resolution report 
XML instead be considered the single source of truth. Hence that question [2] 
in the dev list. I can’t really think of a solution/fix for this issue, without 
reading more of the current Ivy code to understand what role these files play.

[1] 
https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
[2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html

-Jaikiran

On 21-May-2017, at 10:49 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

One thing though.

This revival of the community has been triggered by the comments on this issue:
https://issues.apache.org/jira/browse/IVY-1485 
<https://issues.apache.org/jira/browse/IVY-1485>
It would be a shame if it is not fixed within the next release.

The issue and the fix are not easy to understand. Any review will be welcomed.

Nicolas

> Le 21 mai 2017 à 18:46, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit :
> 
> 
>> Le 21 mai 2017 à 16:28, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> The past few days I’ve sent some PRs for bug fixes and some enhancements in 
>> preparation for the proposed release of Ivy. Thanks Nicolas for reviewing 
>> them and merging those that were good enough. 
>> 
>> I’ve been using this JIRA filter [1] to narrow down on the issues to look 
>> into. That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 
>> 2.3.0 or 2.4.0 and have been updated/created since Jan 1st 2014”. So it 
>> should cover most of the issues that we probably should look into (doesn’t 
>> necessarily mean fix all of them, but just to check if any of them are big 
&

Re: Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai

One thing I forgot to note is that we need to do a similar thing for IvyDE. I
haven’t looked at the JIRA issues for that project [1] and am not familiar with
Eclipse in general. So someone more familiar with it would have to look into
those. Having said that, Gintas has helped with getting the IvyDE project
itself come to life recently, so I guess we can target to do something similar
in terms of release goals, for that project too.

-Jaikiran

[1] https://issues.apache.org/jira/browse/IVYDE
On 21-May-2017, at 7:58 PM, J Pai <jai.forums2...@gmail.com> wrote:

The past few days I’ve sent some PRs for bug fixes and some enhancements in
preparation for the proposed release of Ivy. Thanks Nicolas for reviewing them
and merging those that were good enough.

I’ve been using this JIRA filter [1] to narrow down on the issues to look into.
That filter essentially is of “open issues that affect 2.1.0, 2.2.0, 2.3.0 or
2.4.0 and have been updated/created since Jan 1st 2014”. So it should cover
most of the issues that we probably should look into (doesn’t necessarily mean
fix all of them, but just to check if any of them are big enough to focus on).

I’ve also sent one PR for upgrading our internal library dependencies and plan
to send a couple more for similar upgrades. My intention is to use the latest
released versions of these dependencies instead of sticking with dependencies
that are years old. My intention _isn’t_ to upgrade to a version that isn’t API
backward compatible, so these upgrades are mostly bug fixes and should be
“drop-in upgrades”.

I would be really glad to hear any thoughts about these changes or any
other/different plans, that can get us to a releasable state in the near
future, especially from members/users who have been involved with Ant/Ivy
project in the past or present. Ultimately, I think if we can agree on a goal
for the upcoming release, it will help release something that will set the
right expectation with the end users when it comes to using it. My opinion is
that we consider this release to push out some bug fixes and internal upgrades
and _not_ introduce any major features unless those are reasonably quick to
implement. Once this release is done and (hopefully some of the) community gets
back behind the Ivy project, we can always introduce major features in
subsequent releases.

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC

-Jaikiran

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

Ivy - Goals for the upcoming release?

2017-05-21 Thread J Pai

The past few days I’ve sent some PRs for bug fixes and some enhancements in
preparation for the proposed release of Ivy. Thanks Nicolas for reviewing them
and merging those that were good enough.

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

Re: Ivy - BasicURLHandler ignoring timeout during connection?

2017-05-21 Thread J Pai


>>I was merely speculating as to why HttpClient is there and what challenges
>> lay ahead should that part of code be refreshed.

Understood :)

>> Sorry for digressing, adding setConnectTimeout is fine

I sent a PR with minimal changes for now 
https://github.com/apache/ant-ivy/pull/23

>> (even though setTimeout from HttpClient corresponds to setReadTimeout in 
>> URLConnection
>> -- perhaps that should be changed in HttpClientHandler for consistency?).

I like what Nicolas suggested in one of his replies, that we make this (and 
other necessary timeout configs) a well specified contract and have them 
defined all the way from the settings. I think we can handle this change as 
part of that work. I can file a enhancement JIRA to track this work and have it 
available in either the upcoming release or some release after that (depending 
on how big this change turns out to be).

My main motivation behind BasicURLHandler at this point is the fact that one of 
the test which uses this class takes unnecessarily long because of the missing 
timeout support. The minor change that I included in that PR should let us move 
forward, on that front. 

-Jaikiran

2017-05-21 7:00 GMT+02:00 J Pai <jai.forums2...@gmail.com>:

> Having been involved in a HttpClient 3 to 4 migration in an unrelated
> project, I think at this point, it’s too big a change to consider. A few
> stable Ivy releases down the line, maybe we can re-evaluate this and
> consider the HttpClient libraries and their state at that time.
> 
> -Jaikiran
> On 20-May-2017, at 6:33 PM, Gintautas Grigelionis <g.grigelio...@gmail.com>
> wrote:
> 
> Looks like HttpClientHandler was added as an alternative to handle proxies
> with authentication by wrapping HttpClient from Commons.
> 
> There is a maintenance problem because HttpClient has a major API change
> between version 3 (that Ivy uses currently) and 4. Perhaps it makes sense
> to look at AsyncHttpClient/Netty or should we wait for HttpClient version 5
> (which is progressing through alpha releases currently)? Either way, we'll
> be moving towards Java 8.
> 
> Meanwhile, it makes sense to improve BasicURLHandler and add such
> capabilities as JRE permits.
> 
> Gintas
> 
> 2017-05-20 11:46 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:
> 
>> I don’t know the history of that code, it probably is older that its
>> incubation into Apache.
>> But from what I can read, I think that timeout was introduced but just
>> supported by one implementation of URLHandler: the HttpClient one,
>> HttpClientHandler.
>> 
>> Proper support in the BasicURLHandler will probably be welcomed.
>> 
>> Note though that a quick search in the call hierarchy shows that is is
> not
>> used anywhere other than in IBiblioHelper.
>> 
>> So a proper support for timeout will probably require to propagate a
>> timeout value up to the ivy settings, while declaring resolvers. And as
> you
>> pointed, better semantic would need to be defined. Probably two kind of
>> timeout should be defined.
>> 
>> Nicolas
>> 
>>> Le 19 mai 2017 à 16:10, J Pai <jai.forums2...@gmail.com> a écrit :
>>> 
>>> I was looking at some timing issues in test cases and noticed that the
>> BasicURLHandler.getURLInfo with a timeout[1] seems to be ignoring that
>> timeout completely. Am I missing something or is it just a oversight/bug?
>> Furthermore, the javadoc of URLHandler.getURLInfo doesn’t tell much about
>> what the timeout is about. I’m guessing it’s a connect timeout? Is the
>> intention to use to same for (socket) read timeout too?
>>> 
>>> It’s another matter that the test case that I was looking into doesn’t
>> pass a timeout.
>>> 
>>> [1] https://github.com/apache/ant-ivy/blob/master/src/java/org/
>> apache/ivy/util/url/BasicURLHandler.java#L57
>>> [2] https://github.com/apache/ant-ivy/blob/master/src/java/org/
>> apache/ivy/util/url/URLHandler.java#L164
>>> 
>>> -Jaikiran
>>> -
>>> 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
>> 
>> 
> 
> 
> -
> 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

Ivy - What roles do some of these (internal) resolution files play?

2017-05-20 Thread J Pai

I’ve been going through some of the Ivy code recently and have a few related 
questions. Some of my basic testing shows that a “resolve” of a module produces 
the following (internal) files:

1. A resolution report, in the form of XML, per configuration of the module, in 
the form of --.xml (ex: foo-bar-conf1.xml) and consists a 
comprehensive detail about the (dependency) resolution of that module including 
where the artifacts reside etc…

2. A XML file called resolved---.xml (ex: 
resolved-foo-bar-1.0.xml) which essentially is a ivy.xml of the module. This is 
similar to the file that resides in the Ivy cache for that module.

3. A properties file of the form resolved---.properties 
(ex: resolved-foo-bar-1.0.properties). 

I see that the properties file does get used in some places, but haven’t fully 
grasped the details about it. When is it really used and what exact role does 
it play? Same question with the XML file in #2.

From what I see the resolution report per configuration of the module (the #1) 
has all the necessary information about the resolution. Would it not be enough 
for any kind of post-resolution activities? In other words, internally, can it 
be used exclusively (as a single source of truth) without the need of the files 
in #2 and #3?

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

Re: Ivy - BasicURLHandler ignoring timeout during connection?

2017-05-20 Thread J Pai

Having been involved in a HttpClient 3 to 4 migration in an unrelated project, 
I think at this point, it’s too big a change to consider. A few stable Ivy 
releases down the line, maybe we can re-evaluate this and consider the 
HttpClient libraries and their state at that time.

-Jaikiran
On 20-May-2017, at 6:33 PM, Gintautas Grigelionis <g.grigelio...@gmail.com> 
wrote:

Looks like HttpClientHandler was added as an alternative to handle proxies
with authentication by wrapping HttpClient from Commons.

There is a maintenance problem because HttpClient has a major API change
between version 3 (that Ivy uses currently) and 4. Perhaps it makes sense
to look at AsyncHttpClient/Netty or should we wait for HttpClient version 5
(which is progressing through alpha releases currently)? Either way, we'll
be moving towards Java 8.

Meanwhile, it makes sense to improve BasicURLHandler and add such
capabilities as JRE permits.

Gintas

2017-05-20 11:46 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:

> I don’t know the history of that code, it probably is older that its
> incubation into Apache.
> But from what I can read, I think that timeout was introduced but just
> supported by one implementation of URLHandler: the HttpClient one,
> HttpClientHandler.
> 
> Proper support in the BasicURLHandler will probably be welcomed.
> 
> Note though that a quick search in the call hierarchy shows that is is not
> used anywhere other than in IBiblioHelper.
> 
> So a proper support for timeout will probably require to propagate a
> timeout value up to the ivy settings, while declaring resolvers. And as you
> pointed, better semantic would need to be defined. Probably two kind of
> timeout should be defined.
> 
> Nicolas
> 
>> Le 19 mai 2017 à 16:10, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> I was looking at some timing issues in test cases and noticed that the
> BasicURLHandler.getURLInfo with a timeout[1] seems to be ignoring that
> timeout completely. Am I missing something or is it just a oversight/bug?
> Furthermore, the javadoc of URLHandler.getURLInfo doesn’t tell much about
> what the timeout is about. I’m guessing it’s a connect timeout? Is the
> intention to use to same for (socket) read timeout too?
>> 
>> It’s another matter that the test case that I was looking into doesn’t
> pass a timeout.
>> 
>> [1] https://github.com/apache/ant-ivy/blob/master/src/java/org/
> apache/ivy/util/url/BasicURLHandler.java#L57
>> [2] https://github.com/apache/ant-ivy/blob/master/src/java/org/
> apache/ivy/util/url/URLHandler.java#L164
>> 
>> -Jaikiran
>> -
>> 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
> 
> 


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

Re: [VOTE] Increase minimum Java version for Ivy to Java7

2017-05-19 Thread J Pai

Not fully familiar with the voting process and don’t know if IvyDE will require 
a voting thread of its own, but either way +1 for Java 7 for IvyDE too.

-Jaikiran
On 19-May-2017, at 12:50 PM, Gintautas Grigelionis  
wrote:

Java 7 implements TLS 1.2; Ivy depends a lot more on network communications
than Ant does.
+1, but please extend the vote to the baseline of IvyDE as well.

2017-05-19 9:03 GMT+02:00 Maarten Coene :

> I think we should stick to Java5 as long as Ant 1.9.x is actively
> maintained.This keeps Ivy usable for both Ant 1.9.x and Ant 1.10.x
> Or are there good reasons to increase the minimum Java version, like
> features that cannot be implemented with Java 5?
> But since I don't have the time at the moment to be more active for the
> community, I will not block any decission made.
> So my vote is -0.
> Maarten
> 
> 
>  Van: Jan Matèrne 
> Aan: 'Ant Developers List' 
> Verzonden: vrijdag 19 mei 7:25 2017
> Onderwerp: [VOTE] Increase minimum Java version for Ivy to Java7
> 
> As discussed on this mailing list [1] we should increase the minimum Java
> version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
> Decisions whether to increase to Java8 after that release should be make
> after that release.
> According to the bylaws [3] this vote is open for one week (until
> 26.05.2017).
> 
> Here is my +1
> Jan
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/ant-dev/201705.
> mbox/ajax/%3C87415C1
> F-5EFF-4C81-8078-0276CC21A8ED%40gmail.com%3E
> [2] http://ant.apache.org/ivy/history/latest-milestone/compatibility.html
> [3] http://ant.apache.org/bylaws.html
> 
> 
> -
> 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 - Buildjobs/PreCommit

2017-05-19 Thread J Pai

This pre-commit job is now almost functional. It gets triggered whenever 
there’s a PR and runs the build and tests and reports back if there are any 
failures.

However, the only thing that’s pending or seems to be an issue is it sometimes 
doesn’t report back with the status. In these 2 PRs 
https://github.com/apache/ant-ivy/pull/19 
https://github.com/apache/ant-ivy/pull/20 the status was never reported back to 
github (one of the jobs succeeded and the other failed, so there isn’t a clear 
hint of when this happens).

Other than that, this entire pre-commit support that was added quickly has 
helped a lot. Thanks very much for doing that.

On a related note, while we are at this - does Apache infra allow the jobs to 
be run against Windows OS Jenkins agents as well? There are a few issues 
specifically reported against Windows OS and having the job run against linux 
and Windows OS should give a decent coverage for the upstream code.

-Jaikiran

On 18-May-2017, at 4:03 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

I have changed the config of the build so it does a build, then checkstyle, 
then findbugs, and then the unit tests.

Nicolas

> Le 18 mai 2017 à 08:21, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> Now that the findbugs URL issue has been resolved with this PR[1] being 
> merged, maybe we should change the targets that get run via this pre commit 
> job to be just:
> 
> ant clean test
> 
> and as a start, see how it goes with the PR integration process?
> 
> [1] https://github.com/apache/ant-ivy/pull/16 
> <https://github.com/apache/ant-ivy/pull/16>
> 
> -Jaikiran
> 
> On 17-May-2017, at 6:59 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>> wrote:
> 
> Seems to be a classpath issue where two ivy.jar are loaded. Considering the 
> full console log, probably due to init-ivy called twice, a consequence of Ant 
> not computing one unified tree of tasks to call, but a list of trees of the 
> tasks on the command line.
> 
> The build dedicated to check the style of Ivy is just calling: ant findbugs 
> checkstyle-internal
> https://builds.apache.org/view/A/view/Ant/job/Ivy-check 
> <https://builds.apache.org/view/A/view/Ant/job/Ivy-check> 
> <https://builds.apache.org/view/A/view/Ant/job/Ivy-check 
> <https://builds.apache.org/view/A/view/Ant/job/Ivy-check>>
> But it seems broken too due to some broken download link. The init-findbug 
> task needs to be fixed.
> 
> Nicolas
> 
>> Le 17 mai 2017 à 14:11, Jan Matèrne (jhm) <apa...@materne.de> a écrit :
>> 
>> My last test result:
>> The Jenkins job could not load Findbugs. So I have deactivated that for the 
>> moment.
>> 
>> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/6/console
>> ant-1.9.9> ant clean jar sources checkstyle-internal coverage-report 
>> resolve:
>> BUILD FAILED
>> /.../build.xml:184: java.lang.ClassCastException: 
>> org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor cannot be cast 
>> to org.apache.ivy.core.module.descriptor.ModuleDescriptor
>>  at 
>> org.apache.ivy.ant.IvyPostResolveTask.getConfsToResolve(IvyPostResolveTask.java:233)
>>  at 
>> org.apache.ivy.ant.IvyPostResolveTask.ensureResolved(IvyPostResolveTask.java:219)
>>  at 
>> org.apache.ivy.ant.IvyPostResolveTask.prepareAndCheck(IvyPostResolveTask.java:179)
>>  at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:88)
>>  at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:272)
>> 
>> ant-1.9.9> ant -f build-release.xml -Drat.failOnError=false rat
>> not run due to prior problems
>> 
>> 
>> Some ideas?
>> 
>> 
>> Jan
>> 
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>>> Gesendet: Mittwoch, 17. Mai 2017 13:18
>>> An: Ant Developers List
>>> Betreff: Re: Ivy - Buildjobs/PreCommit
>>> 
>>> Updated the same PR and that triggered this job
>>> https://builds.apache.org/job/Ivy-GithubPR/3/. It failed to build due
>>> to a host not being resolvable. This job ran on node called H15
>>> https://builds.apache.org/computer/H15/ whereas the first job which had
>>> succeeded had run on https://builds.apache.org/computer/qnode3/. Maybe
>>> all nodes are not equal and perhaps this job needs to be
>>> assigned/categorized to certain node groups?
>>> 
>>> -Jaikiran
>>> On 17-May-2017, at 4:03 PM, Jan Matèrne (jhm) <apa...@materne.de>
>>> wrote:
>>> 
>>> Thanks, I changed the job to run:
>>> 
>>>

Ivy - BasicURLHandler ignoring timeout during connection?

2017-05-19 Thread J Pai

I was looking at some timing issues in test cases and noticed that the 
BasicURLHandler.getURLInfo with a timeout[1] seems to be ignoring that timeout 
completely. Am I missing something or is it just a oversight/bug? Furthermore, 
the javadoc of URLHandler.getURLInfo doesn’t tell much about what the timeout 
is about. I’m guessing it’s a connect timeout? Is the intention to use to same 
for (socket) read timeout too?

It’s another matter that the test case that I was looking into doesn’t pass a 
timeout.

[1] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/util/url/BasicURLHandler.java#L57
[2] 
https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/util/url/URLHandler.java#L164

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

Re: [VOTE] Increase minimum Java version for Ivy to Java7

2017-05-19 Thread J Pai

One of the reasons, other than the fact that I haven’t personally seen anyone 
using Java 5 in development projects or production for many years now, has to 
do with the development and testing of the project itself. 

It’s hard to find a Java 5 runtime to actually test the product against (almost 
the same with Java 6). Plus the fact that, for enhancements like this one [1] 
we will end up adding a bit more complexity to the project which can be avoided 
if we move to a higher version. Add to that the various language level features 
that we can’t currently use (try with resources, switch statements from string 
etc…) in the code.

As for using Ivy with Ant 1.9.x, I think the strategy we can follow is to 
recommend users to use Ivy 2.5.x with Ant 1.10.x (which by the way is Java 8 
runtime backed). If however they do want to use Ant 1.9.x version, then ask 
them to use Ivy 2.4.0.

[1] https://github.com/apache/ant-ivy/pull/19

-Jaikiran

On 19-May-2017, at 12:33 PM, Maarten Coene  
wrote:

I think we should stick to Java5 as long as Ant 1.9.x is actively 
maintained.This keeps Ivy usable for both Ant 1.9.x and Ant 1.10.x
Or are there good reasons to increase the minimum Java version, like features 
that cannot be implemented with Java 5?
But since I don't have the time at the moment to be more active for the 
community, I will not block any decission made.
So my vote is -0.
Maarten


 Van: Jan Matèrne 
Aan: 'Ant Developers List'  
Verzonden: vrijdag 19 mei 7:25 2017
Onderwerp: [VOTE] Increase minimum Java version for Ivy to Java7

As discussed on this mailing list [1] we should increase the minimum Java
version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
Decisions whether to increase to Java8 after that release should be make
after that release.
According to the bylaws [3] this vote is open for one week (until
26.05.2017).

Here is my +1
Jan

[1]
http://mail-archives.apache.org/mod_mbox/ant-dev/201705.mbox/ajax/%3C87415C1
F-5EFF-4C81-8078-0276CC21A8ED%40gmail.com%3E
[2] http://ant.apache.org/ivy/history/latest-milestone/compatibility.html
[3] http://ant.apache.org/bylaws.html


-
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] Increase minimum Java version for Ivy to Java7

2017-05-18 Thread J Pai

+1

-Jaikiran
On 19-May-2017, at 10:55 AM, Jan Matèrne  wrote:

As discussed on this mailing list [1] we should increase the minimum Java
version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
Decisions whether to increase to Java8 after that release should be make
after that release.
According to the bylaws [3] this vote is open for one week (until
26.05.2017).

Here is my +1
Jan

[1]
http://mail-archives.apache.org/mod_mbox/ant-dev/201705.mbox/ajax/%3C87415C1
F-5EFF-4C81-8078-0276CC21A8ED%40gmail.com%3E
[2] http://ant.apache.org/ivy/history/latest-milestone/compatibility.html
[3] http://ant.apache.org/bylaws.html


-
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: Minimum Java runtime version for proposed upcoming Ivy release

2017-05-18 Thread J Pai

So far the majority seems to be to require a minimum of Java 7. If there are no 
concerns or objections to this by the end of this week, then on Monday, I’ll 
raise a PR to mandate Java 7 for Ivy.

-Jaikiran


On 18-May-2017, at 11:48 PM, Gintautas Grigelionis <g.grigelio...@gmail.com> 
wrote:

That's fine, IvyDE is already at Java 7/Eclipse 3.7.1; then IvyDE baseline
should be bumped to Java 8/Eclipse 4.4 with the next Ivy release. Hopefully
updatesite resolver could be used then.

2017-05-18 17:12 GMT+02:00 Matt Sicker <boa...@gmail.com>:

> Using 1.7 for the next release and then 1.8 for the following release makes
> sense to me.
> 
> On 18 May 2017 at 05:58, J Pai <jai.forums2...@gmail.com> wrote:
> 
>> +1
>> 
>> -Jaikiran
>> On 18-May-2017, at 4:26 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:
>> 
>> I would favour 1.7 as it's the newest before the major update to Java8.
>> Having a 1.7 in the target environment should not been so restrictive ...
>> 
>> Jan
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Paul King [mailto:pa...@asert.com.au]
>>> Gesendet: Donnerstag, 18. Mai 2017 11:27
>>> An: Ant Developers List
>>> Betreff: Re: Minimum Java runtime version for proposed upcoming Ivy
>>> release
>>> 
>>> The current version of Groovy has 1.6 as the minimum but is our
>>> maintenance stream.
>>> The upcoming next version will require 1.7 and versions with 1.8 as the
>>> minimum are not too far away.
>>> 
>>> Ant 1.9.x is still on Java5 but Ant 1.10.x requires Java 8.
>>> 
>>> I don't think Gradle uses any Ivy classes any more.
>>> 
>>> I'd recommend 1.7 since most active projects will be releasing on
>>> 1.7/1.8 and then after a release, if all goes well activity-wise, I'd
>>> then bump the Ivy version and target 8.
>>> 
>>> Cheers, Paul.
>>> 
>>> 
>>> On Thu, May 18, 2017 at 7:14 PM, Nicolas Lalevée
>>> <nicolas.lale...@hibnet.org
>>>> wrote:
>>> 
>>>> I think that upgrading the requirement on the JDK is a good idea,
>>>> because at least us, the maintainers, need at some point to be able
>>> to
>>>> test it if there is an issue with that minimum JDK.
>>>> 
>>>> One thing to consider is which JDK is being required in the
>>>> environment Ivy is being used: Ant, Gradle, SBT, Eclipse, Intellij…
>>> We
>>>> shouldn’t require too high.
>>>> 
>>>> Nicolas
>>>> 
>>>>> Le 18 mai 2017 à 10:58, J Pai <jai.forums2...@gmail.com> a écrit :
>>>>> 
>>>>> Now that the plan seems to be to release 2.5.x of Ivy, would it be
>>>>> fine
>>>> if we mandate the _minimum_ Java runtime version to be something
>>>> higher than Java 5 that’s currently supported for 2.4.x
>>>> http://ant.apache.org/ivy/history/latest-
>>> milestone/compatibility.html.
>>>>> 
>>>>> Given that Java 6 itself has long been EOLed, I’m not sure whether
>>>>> we
>>>> should consider that as minimum supported version or something
>>> higher.
>>>> Any thoughts?
>>>>> 
>>>>> Things will be a bit more easy to develop and test once we finalize
>>>>> on
>>>> the Java version.
>>>>> 
>>>>> -Jaikiran
>>>>> ---
>>> -
>>>>> - 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
>>>> 
>>>> 
>> 
>> 
>> -
>> 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
>> 
>> 
> 
> 
> --
> Matt Sicker <boa...@gmail.com>
> 


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

Re: Minimum Java runtime version for proposed upcoming Ivy release

2017-05-18 Thread J Pai

+1

-Jaikiran
On 18-May-2017, at 4:26 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

I would favour 1.7 as it's the newest before the major update to Java8.
Having a 1.7 in the target environment should not been so restrictive ...

Jan

> -Ursprüngliche Nachricht-
> Von: Paul King [mailto:pa...@asert.com.au]
> Gesendet: Donnerstag, 18. Mai 2017 11:27
> An: Ant Developers List
> Betreff: Re: Minimum Java runtime version for proposed upcoming Ivy
> release
> 
> The current version of Groovy has 1.6 as the minimum but is our
> maintenance stream.
> The upcoming next version will require 1.7 and versions with 1.8 as the
> minimum are not too far away.
> 
> Ant 1.9.x is still on Java5 but Ant 1.10.x requires Java 8.
> 
> I don't think Gradle uses any Ivy classes any more.
> 
> I'd recommend 1.7 since most active projects will be releasing on
> 1.7/1.8 and then after a release, if all goes well activity-wise, I'd
> then bump the Ivy version and target 8.
> 
> Cheers, Paul.
> 
> 
> On Thu, May 18, 2017 at 7:14 PM, Nicolas Lalevée
> <nicolas.lale...@hibnet.org
>> wrote:
> 
>> I think that upgrading the requirement on the JDK is a good idea,
>> because at least us, the maintainers, need at some point to be able
> to
>> test it if there is an issue with that minimum JDK.
>> 
>> One thing to consider is which JDK is being required in the
>> environment Ivy is being used: Ant, Gradle, SBT, Eclipse, Intellij…
> We
>> shouldn’t require too high.
>> 
>> Nicolas
>> 
>>> Le 18 mai 2017 à 10:58, J Pai <jai.forums2...@gmail.com> a écrit :
>>> 
>>> Now that the plan seems to be to release 2.5.x of Ivy, would it be
>>> fine
>> if we mandate the _minimum_ Java runtime version to be something
>> higher than Java 5 that’s currently supported for 2.4.x
>> http://ant.apache.org/ivy/history/latest-
> milestone/compatibility.html.
>>> 
>>> Given that Java 6 itself has long been EOLed, I’m not sure whether
>>> we
>> should consider that as minimum supported version or something
> higher.
>> Any thoughts?
>>> 
>>> Things will be a bit more easy to develop and test once we finalize
>>> on
>> the Java version.
>>> 
>>> -Jaikiran
>>> ---
> -
>>> - 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
>> 
>> 


-
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

Minimum Java runtime version for proposed upcoming Ivy release

2017-05-18 Thread J Pai

Now that the plan seems to be to release 2.5.x of Ivy, would it be fine if we 
mandate the _minimum_ Java runtime version to be something higher than Java 5 
that’s currently supported for 2.4.x 
http://ant.apache.org/ivy/history/latest-milestone/compatibility.html.

Given that Java 6 itself has long been EOLed, I’m not sure whether we should 
consider that as minimum supported version or something higher. Any thoughts?

Things will be a bit more easy to develop and test once we finalize on the Java 
version.

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

Re: Ivy - Buildjobs/PreCommit

2017-05-18 Thread J Pai

Now that the findbugs URL issue has been resolved with this PR[1] being merged, 
maybe we should change the targets that get run via this pre commit job to be 
just:

ant clean test

and as a start, see how it goes with the PR integration process?

[1] https://github.com/apache/ant-ivy/pull/16

-Jaikiran

On 17-May-2017, at 6:59 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:

Seems to be a classpath issue where two ivy.jar are loaded. Considering the 
full console log, probably due to init-ivy called twice, a consequence of Ant 
not computing one unified tree of tasks to call, but a list of trees of the 
tasks on the command line.

The build dedicated to check the style of Ivy is just calling: ant findbugs 
checkstyle-internal
https://builds.apache.org/view/A/view/Ant/job/Ivy-check 
<https://builds.apache.org/view/A/view/Ant/job/Ivy-check>
But it seems broken too due to some broken download link. The init-findbug task 
needs to be fixed.

Nicolas

> Le 17 mai 2017 à 14:11, Jan Matèrne (jhm) <apa...@materne.de> a écrit :
> 
> My last test result:
> The Jenkins job could not load Findbugs. So I have deactivated that for the 
> moment.
> 
> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/6/console
> ant-1.9.9> ant clean jar sources checkstyle-internal coverage-report 
> resolve:
> BUILD FAILED
> /.../build.xml:184: java.lang.ClassCastException: 
> org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor cannot be cast 
> to org.apache.ivy.core.module.descriptor.ModuleDescriptor
>   at 
> org.apache.ivy.ant.IvyPostResolveTask.getConfsToResolve(IvyPostResolveTask.java:233)
>   at 
> org.apache.ivy.ant.IvyPostResolveTask.ensureResolved(IvyPostResolveTask.java:219)
>   at 
> org.apache.ivy.ant.IvyPostResolveTask.prepareAndCheck(IvyPostResolveTask.java:179)
>   at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:88)
>   at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:272)
> 
> ant-1.9.9> ant -f build-release.xml -Drat.failOnError=false rat
> not run due to prior problems
> 
> 
> Some ideas?
> 
> 
> Jan
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>> Gesendet: Mittwoch, 17. Mai 2017 13:18
>> An: Ant Developers List
>> Betreff: Re: Ivy - Buildjobs/PreCommit
>> 
>> Updated the same PR and that triggered this job
>> https://builds.apache.org/job/Ivy-GithubPR/3/. It failed to build due
>> to a host not being resolvable. This job ran on node called H15
>> https://builds.apache.org/computer/H15/ whereas the first job which had
>> succeeded had run on https://builds.apache.org/computer/qnode3/. Maybe
>> all nodes are not equal and perhaps this job needs to be
>> assigned/categorized to certain node groups?
>> 
>> -Jaikiran
>> On 17-May-2017, at 4:03 PM, Jan Matèrne (jhm) <apa...@materne.de>
>> wrote:
>> 
>> Thanks, I changed the job to run:
>> 
>> ant clean jar sources findbugs checkstyle-internal coverage-report ant
>> -f build-release.xml -Drat.failOnError=false rat
>> 
>> Please try again ;)
>> 
>> 
>> Jan
>> 
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>>> Gesendet: Mittwoch, 17. Mai 2017 10:53
>>> An: Ant Developers List
>>> Betreff: Re: Ivy - Buildjobs/PreCommit
>>> 
>>> It turns out the PR you submitted was to your personal repo instead
>> of
>>> the apache repo. I just submitted a dummy PR to apache repo
>>> https://github.com/apache/ant-ivy/pull/13 and that did indeed trigger
>>> the Jenkins job https://builds.apache.org/view/A/view/Ant/job/Ivy-
>>> GithubPR/1/ automagically :) I’m guessing this job isn’t running any
>>> tests right now (given how quickly it finished)?
>>> 
>>> This is good start to getting this working. Thanks for getting this
>>> setup :)
>>> 
>>> -Jaikiran
>>> 
>>> 
>>> On 17-May-2017, at 2:07 PM, J Pai <jai.forums2...@gmail.com> wrote:
>>> 
>>> Doesn’t look like it got triggered in Jenkins.
>>> 
>>> -Jaikiran
>>> On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm) <apa...@materne.de>
>>> wrote:
>>> 
>>>> I read the wiki page
>> https://wiki.apache.org/general/PreCommitBuilds,
>>>> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
>>>> had a look at some other PreCommit-jobs.
>>>> For me this works like that:
>>>> 1. The PreCommit-Admin job checks regularly on for new patches in
>>> Jira.
>>>> 2

Re: Ivy - Buildjobs/PreCommit

2017-05-17 Thread J Pai

I just submitted a PR https://github.com/apache/ant-ivy/pull/16 which I think 
should fix the init-findbug task.

-Jaikiran

On 17-May-2017, at 6:59 PM, Nicolas Lalevée  wrote:

The build dedicated to check the style of Ivy is just calling: ant findbugs 
checkstyle-internal
https://builds.apache.org/view/A/view/Ant/job/Ivy-check 

But it seems broken too due to some broken download link. The init-findbug task 
needs to be fixed.


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

Re: Ivy - Buildjobs/PreCommit

2017-05-17 Thread J Pai

Updated the same PR and that triggered this job 
https://builds.apache.org/job/Ivy-GithubPR/3/. It failed to build due to a host 
not being resolvable. This job ran on node called H15 
https://builds.apache.org/computer/H15/ whereas the first job which had 
succeeded had run on https://builds.apache.org/computer/qnode3/. Maybe all 
nodes are not equal and perhaps this job needs to be assigned/categorized to 
certain node groups?

-Jaikiran
On 17-May-2017, at 4:03 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

Thanks, I changed the job to run:

ant clean jar sources findbugs checkstyle-internal coverage-report
ant -f build-release.xml -Drat.failOnError=false rat

Please try again ;)


Jan


> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Mittwoch, 17. Mai 2017 10:53
> An: Ant Developers List
> Betreff: Re: Ivy - Buildjobs/PreCommit
> 
> It turns out the PR you submitted was to your personal repo instead of
> the apache repo. I just submitted a dummy PR to apache repo
> https://github.com/apache/ant-ivy/pull/13 and that did indeed trigger
> the Jenkins job https://builds.apache.org/view/A/view/Ant/job/Ivy-
> GithubPR/1/ automagically :) I’m guessing this job isn’t running any
> tests right now (given how quickly it finished)?
> 
> This is good start to getting this working. Thanks for getting this
> setup :)
> 
> -Jaikiran
> 
> 
> On 17-May-2017, at 2:07 PM, J Pai <jai.forums2...@gmail.com> wrote:
> 
> Doesn’t look like it got triggered in Jenkins.
> 
> -Jaikiran
> On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm) <apa...@materne.de>
> wrote:
> 
>> I read the wiki page https://wiki.apache.org/general/PreCommitBuilds,
>> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
>> had a look at some other PreCommit-jobs.
>> For me this works like that:
>> 1. The PreCommit-Admin job checks regularly on for new patches in
> Jira.
>> 2. It invokes the "PreCommit-{JiraProject}" job mit Jira-ID and
>> file-ID as argument.
>> 3. The job does the rest.
>> 
>> That means the job itself has to apply the patchfile - and of course
>> run the build.
>> 
>> On the other hand I found a blog post from infra
>> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>> and set up an according job
>> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/
>> This job uses the Github integration by Cloudbees Enterprise plugin.
>> So next step for test would be a new/updated PR ...
> 
> I've created a small PR https://github.com/janmaterne/ant-ivy/pull/1.
> Now ... wait ;)
> 
> Jan
> 
> 
> -
> 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



-
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 - Buildjobs/PreCommit

2017-05-17 Thread J Pai

It turns out the PR you submitted was to your personal repo instead of the 
apache repo. I just submitted a dummy PR to apache repo 
https://github.com/apache/ant-ivy/pull/13 and that did indeed trigger the 
Jenkins job https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/1/ 
automagically :) I’m guessing this job isn’t running any tests right now (given 
how quickly it finished)?

This is good start to getting this working. Thanks for getting this setup :)

-Jaikiran

On 17-May-2017, at 2:07 PM, J Pai <jai.forums2...@gmail.com> wrote:

Doesn’t look like it got triggered in Jenkins.

-Jaikiran
On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

> I read the wiki page https://wiki.apache.org/general/PreCommitBuilds,
> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
> had a look at some other PreCommit-jobs.
> For me this works like that:
> 1. The PreCommit-Admin job checks regularly on for new patches in Jira.
> 2. It invokes the "PreCommit-{JiraProject}" job mit Jira-ID and file-ID
> as argument.
> 3. The job does the rest.
> 
> That means the job itself has to apply the patchfile - and of course
> run the build.
> 
> On the other hand I found a blog post from infra
> https://blogs.apache.org/infra/entry/github_pull_request_builds_now and
> set up an according job
> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/
> This job uses the Github integration by Cloudbees Enterprise plugin.
> So next step for test would be a new/updated PR ...

I've created a small PR https://github.com/janmaterne/ant-ivy/pull/1.
Now ... wait ;)

Jan

-
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 - Buildjobs/PreCommit

2017-05-17 Thread J Pai

Doesn’t look like it got triggered in Jenkins.

-Jaikiran
On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm)  wrote:

> I read the wiki page https://wiki.apache.org/general/PreCommitBuilds,
> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
> had a look at some other PreCommit-jobs.
> For me this works like that:
> 1. The PreCommit-Admin job checks regularly on for new patches in Jira.
> 2. It invokes the "PreCommit-{JiraProject}" job mit Jira-ID and file-ID
> as argument.
> 3. The job does the rest.
> 
> That means the job itself has to apply the patchfile - and of course
> run the build.
> 
> On the other hand I found a blog post from infra
> https://blogs.apache.org/infra/entry/github_pull_request_builds_now and
> set up an according job
> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/
> This job uses the Github integration by Cloudbees Enterprise plugin.
> So next step for test would be a new/updated PR ...

I've created a small PR https://github.com/janmaterne/ant-ivy/pull/1.
Now ... wait ;)

Jan


-
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+IvyDE: help wanted

2017-05-16 Thread J Pai

Thank you very much Nicolas. Having you around for code reviews and even just 
watching is definitely going to help a lot.

Thanks for merging that patch too. 

-Jaikiran
On 17-May-2017, at 2:09 AM, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:


> Le 16 mai 2017 à 13:11, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> Thanks Jan for initiating this.
> 
> On the ICLA front -  I already have contributed and continue to contribute to 
> some other Apache projects (these days mostly via github). Do I still have to 
> sign the ICLA? Is there a way to check if I have already signed this ICLA 
> previously? I don’t remember if I was asked to do that for the other Apache 
> projects.
> 
> As for patches, I had submitted one a while back and need someone to review 
> it https://github.com/apache/ant-ivy/pull/10/files.
> 
> Few other things:
> 
> - As I have noted in the past, in some mails[1] to the dev list, I am willing 
> to help out in whatever way I can to move the project forward. As noted in 
> some of those mails, I in no way have the complete understanding of the 
> current codebase, but am willing to invest time as I go along to help fixing 
> issues and adding enhancements wherever I can. One of the recent things I had 
> attempted was to triage some issues in the Ivy JIRA and see if we can come to 
> a decision on pushing out a new release with at least a few of them fixed. 
> That discussion did get some community discussion but couldn’t achieve much 
> given that there wasn’t any actionable involvement from those who could 
> really do a release. In short, I would like to give this another try and see 
> how it goes.

Thank you Jaikiran. I hope this time this will work out.

I wanted to make things happen at the beginning of the year, but for some 
reason I lost motivation to do so. This time I’ll try better. I may not drive 
things, but I’ll get time to do some code review and merge things. Let’s go 
forward releases. If there are list of things people want to us to merge, it is 
the time to do so.

And so I have reviewed the PR #10. It's very good. Thank you. I merged it. It 
was just missing an update in the release notes, which I took care of.

Nicolas

> 
> - From a development point of view, given that there aren’t many who are 
> familiar with the codebase, it would really help build some kind of 
> confidence level in submitted patches, if the github repo was backed by the 
> usual PR processing mechanism that’s associated with many other Apache 
> projects out there. What I mean is, submission of each PR triggering the 
> builds, testcases through a build automation tool (like Jenkins) and 
> reporting back with any issues with existing test cases. 
> 
> - Finally, IMO, given how long this project has gone without any development 
> or a release, I think it would be good to really aim for a release in the 
> next few months. It doesn’t have to contain too many fixes or enhancements, 
> but something to get the release train going and making contributors feel 
> it’s worth their time.
> 
> On the IvyDE front, I think in the past few months there was a community 
> member who did do a good job, IMO, to make sure the builds are back to 
> working, so I think that project too has seen someone who’s willing to help.
> 
> [1] https://www.mail-archive.com/dev@ant.apache.org/msg45129.html
> 
> -Jaikiran
> 
> On 16-May-2017, at 3:19 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:
> 
> Hello community
> 
> the Ant PMC hasn't been able to keep up with bugs reported for Ivy and IvyDE
> for a while now. The number of active committers with the required knowledge
> of the code base is getting smaller and we are having a hard time evaluating
> patches.
> 
> We'd like to revive Ivy and IvyDE, but we need your help.
> 
> If you are interested in developing Ivy, please step up and let us know. For
> starters
> 
> - Sign an ICLA (formal requirement) http://www.apache.org/licenses/#clas
> 
> - Start providing a patch, either as pull request on the Github mirror or
> as a patch attached to a JIRA issue. We also need people reviewing
> patches already present for existing issues.
> 
> - we'll discuss the patches and ask you to join us on the dev
> list.
> 
> - Please nag us if we seem to be ignoring patches for too long -
> this probably is already the case for existing issues.
> 
> 
> Jan Matèrne, on behalf of the Apache Ant community
> 
> 
> 
> 
> -
> 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



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

Re: Ivy+IvyDE: help wanted

2017-05-16 Thread J Pai

Here’s the instructions https://wiki.apache.org/general/PreCommitBuilds which 
Kafka team apparently followed. They tracked this activity in this JIRA 
https://issues.apache.org/jira/browse/KAFKA-1856

-Jaikiran

On 16-May-2017, at 6:20 PM, J Pai <jai.forums2...@gmail.com> wrote:

On 16-May-2017, at 6:09 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote:

> - From a development point of view, given that there aren’t many who
> are familiar with the codebase, it would really help build some kind of
> confidence level in submitted patches, if the github repo was backed by
> the usual PR processing mechanism that’s associated with many other
> Apache projects out there. What I mean is, submission of each PR
> triggering the builds, testcases through a build automation tool (like
> Jenkins) and reporting back with any issues with existing test cases.

+1
I don't know any automatisation of this kind. Someone else? 
Something where we could copy that?

Apache Kafka are doing this for their github mirror 
https://github.com/apache/kafka/pulls. They had a discussion about this in 
their mailing list on how to setup. I’ll try and find if there’s some detailed 
instructions for Apache projects to follow this model.

-Jaikiran

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

Re: Ivy+IvyDE: help wanted

2017-05-16 Thread J Pai

On 16-May-2017, at 6:09 PM, Jan Matèrne (jhm)  wrote:

> - From a development point of view, given that there aren’t many who
> are familiar with the codebase, it would really help build some kind of
> confidence level in submitted patches, if the github repo was backed by
> the usual PR processing mechanism that’s associated with many other
> Apache projects out there. What I mean is, submission of each PR
> triggering the builds, testcases through a build automation tool (like
> Jenkins) and reporting back with any issues with existing test cases.

+1
I don't know any automatisation of this kind. Someone else? 
Something where we could copy that?

Apache Kafka are doing this for their github mirror 
https://github.com/apache/kafka/pulls. They had a discussion about this in 
their mailing list on how to setup. I’ll try and find if there’s some detailed 
instructions for Apache projects to follow this model.

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

Re: Ivy+IvyDE: help wanted

2017-05-16 Thread J Pai

Thanks Jan for initiating this.

On the ICLA front -  I already have contributed and continue to contribute to 
some other Apache projects (these days mostly via github). Do I still have to 
sign the ICLA? Is there a way to check if I have already signed this ICLA 
previously? I don’t remember if I was asked to do that for the other Apache 
projects.

As for patches, I had submitted one a while back and need someone to review it 
https://github.com/apache/ant-ivy/pull/10/files.

Few other things:

- As I have noted in the past, in some mails[1] to the dev list, I am willing 
to help out in whatever way I can to move the project forward. As noted in some 
of those mails, I in no way have the complete understanding of the current 
codebase, but am willing to invest time as I go along to help fixing issues and 
adding enhancements wherever I can. One of the recent things I had attempted 
was to triage some issues in the Ivy JIRA and see if we can come to a decision 
on pushing out a new release with at least a few of them fixed. That discussion 
did get some community discussion but couldn’t achieve much given that there 
wasn’t any actionable involvement from those who could really do a release. In 
short, I would like to give this another try and see how it goes.

- From a development point of view, given that there aren’t many who are 
familiar with the codebase, it would really help build some kind of confidence 
level in submitted patches, if the github repo was backed by the usual PR 
processing mechanism that’s associated with many other Apache projects out 
there. What I mean is, submission of each PR triggering the builds, testcases 
through a build automation tool (like Jenkins) and reporting back with any 
issues with existing test cases. 

- Finally, IMO, given how long this project has gone without any development or 
a release, I think it would be good to really aim for a release in the next few 
months. It doesn’t have to contain too many fixes or enhancements, but 
something to get the release train going and making contributors feel it’s 
worth their time.

On the IvyDE front, I think in the past few months there was a community member 
who did do a good job, IMO, to make sure the builds are back to working, so I 
think that project too has seen someone who’s willing to help.

[1] https://www.mail-archive.com/dev@ant.apache.org/msg45129.html

-Jaikiran
 
On 16-May-2017, at 3:19 PM, Jan Matèrne (jhm)  wrote:

Hello community

the Ant PMC hasn't been able to keep up with bugs reported for Ivy and IvyDE
for a while now. The number of active committers with the required knowledge
of the code base is getting smaller and we are having a hard time evaluating
patches.

We'd like to revive Ivy and IvyDE, but we need your help.

If you are interested in developing Ivy, please step up and let us know. For
starters

- Sign an ICLA (formal requirement) http://www.apache.org/licenses/#clas

- Start providing a patch, either as pull request on the Github mirror or
 as a patch attached to a JIRA issue. We also need people reviewing
 patches already present for existing issues.

- we'll discuss the patches and ask you to join us on the dev
 list.

- Please nag us if we seem to be ignoring patches for too long -
 this probably is already the case for existing issues.


Jan Matèrne, on behalf of the Apache Ant community




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

Re: Ivy - Proposal for reviving the project and moving towards a release

2016-12-13 Thread J Pai

Maarten, thanks for volunteering to review the PRs. One of them has a test
case. I will add a test for the other one.

It looks like you have been involved with Ivy development and releases
before, so I think you would be in a better position to decide if it should
be 2.5.0 or 2.4.1. I personally prefer 2.4.1 because we are focussing on
fixing some reported issues rather than introducing some new features.

As for the release timeline, the reason I asked for a March 2017 date is to
make sure we have a realistic goal in mind of releasing it instead of a
open ended one which drags can potentially drag on for a while given the
current state of the project. Having said that, you and others in ant-dev
team who have been involved in previous releases can decide what makes
sense in terms of release commitments. My whole goal is to try and get a
usable bug fix release out soon, since the last one was 2 years back.

-Jaikiran

On Monday, December 12, 2016, Maarten Coene 
wrote:
> Thanks Jaikran,
> I will look at your patches, I'll try to do it this week.If possible,
please attach a junit test as well to reproduce the problem.
>
> About the release, the master branch already contains some fixes since
the 2.4.0 release. They are listed in the release-notes.html in the 'doc'
directory. If we want to create a 2.4.1 release, we should merge all these
changes (and all upcomming patches) into the 2.4.x branch as well. If we
decide to create a 2.5.0 release, this merging isn't necessary. I wouldn't
pin on an exact timing, we can create a release any time when we think the
codebase is ready for it.
>
> We also have to find a release manager. I did it in the past when we were
on SVN, but I don't have enough GIT knowledge (and I don't have the time to
look into it) to do a new release.
>
> Maarten
>
>   Van: Jaikiran Pai 
>  Aan: dev@ant.apache.org
>  Verzonden: zondag 11 december 15:22 2016
>  Onderwerp: Ivy - Proposal for reviving the project and moving towards a
release
>
> First off, I'm not an Ivy or Ant committer. The proposal that I make
> below for an Ivy release is based on what was discussed in a recent mail
> thread about the future of Ivy
> https://www.mail-archive.com/dev@ant.apache.org/msg45078.html. There was
> a suggestion that someone from community volunteer to try and bring in
> some activity into the project and see if we can create a release after
> triaging the JIRA issues.
>
>
> I have had a look at the open issues in JIRA today and decided to filter
> out issues that are open, updated since Jan 2014 and affects versions
> 2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to
> just select a few that I thought can be considered "active". This [1]
> returns 57 issues. I went ahead and looked at those issues today and
> have asked for more information in the JIRAs wherever relevant and have
> sent a couple of pull requests [2] [3] to fix some straightforward ones.
> I also have another PR that I opened this week to fix one other issue.
> Out of those 57 issues, many are no longer relevant or don't have enough
> details. I don't have JIRA privileges to label them, share filters or
> even assign some to myself to track them better. So I think for now, we
> can rely on that JIRA search query [1].
>
> At this point, I think, if we can target March 2017 for releasing a
> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> good start. Some of the issues noted in that JIRA are indeed important
> ones and would need some review/help in fixing them correctly, which
> essentially means, we need at least one person who has had experience
> with the Ivy code and its design details and also has the committer
rights.
>
>
> Does any of this look feasible? Let me know if this isn't enough to move
> things forward - I don't want to end up sending PRs and spending time on
> this if there's no way we can get to a proper release in the next few
> months.
>
>
> [1]
>
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>
> [2] https://github.com/apache/ant-ivy/pull/11
>
> [3] https://github.com/apache/ant-ivy/pull/12
>
> -Jaikiran
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
>
>

Re: Ivy - Proposal for reviving the project and moving towards a release

2016-12-11 Thread J Pai

Sounds fine then.

-Jaikiran

On Monday, December 12, 2016, Matt Sicker <boa...@gmail.com> wrote:
> Issues in the release process? Those would be handled by multiple release
> candidates. People normally only use alphas and betas for new projects or
> new major versions of projects at Apache.
>
> On 11 December 2016 at 19:53, J Pai <jai.forums2...@gmail.com> wrote:
>
>> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is
to
>> iron out any issues involved in the process itself which, from what I
read
>> in the other thread, might involve certain challenges for the first time.
>>
>> -Jaikiran
>>
>> On Sunday, December 11, 2016, Matt Sicker <boa...@gmail.com> wrote:
>> > Do we really need a beta release? If you're working on bugfixes first,
>> then
>> > a regular 2.4.1 release would be great. It would go through the normal
>> > Apache release candidate process, and perhaps we could get some Gradle
>> > developers to test it out as well since they still seem to be big users
>> of
>> > Ivy.
>> >
>> > Any committer to the Ant project could prepare the release and be a
>> release
>> > manager. The only requirements involving PMCs is to vote on approving
the
>> > release; adding your GPG key to the KEYS file (only PMCs can commit to
>> that
>> > repository involved); and committing the artifacts to the release svn
>> > repository (again, PMCs). I'm also not a committer, but if you're
>> > interested enough in maintaining Ivy, I'd guess that the PMCs may wish
to
>> > bring you on board to do so.
>> >
>> >
>> > On 11 December 2016 at 08:22, Jaikiran Pai <jai.forums2...@gmail.com>
>> wrote:
>> >
>> >> First off, I'm not an Ivy or Ant committer. The proposal that I make
>> below
>> >> for an Ivy release is based on what was discussed in a recent mail
>> thread
>> >> about the future of Ivy https://www.mail-archive.com/d
>> >> e...@ant.apache.org/msg45078.html. There was a suggestion that someone
>> from
>> >> community volunteer to try and bring in some activity into the project
>> and
>> >> see if we can create a release after triaging the JIRA issues.
>> >>
>> >>
>> >> I have had a look at the open issues in JIRA today and decided to
filter
>> >> out issues that are open, updated since Jan 2014 and affects versions
>> 2.1,
>> >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
>> select
>> >> a few that I thought can be considered "active". This [1] returns 57
>> >> issues. I went ahead and looked at those issues today and have asked
for
>> >> more information in the JIRAs wherever relevant and have sent a couple
>> of
>> >> pull requests [2] [3] to fix some straightforward ones. I also have
>> another
>> >> PR that I opened this week to fix one other issue. Out of those 57
>> issues,
>> >> many are no longer relevant or don't have enough details. I don't have
>> JIRA
>> >> privileges to label them, share filters or even assign some to myself
to
>> >> track them better. So I think for now, we can rely on that JIRA search
>> >> query [1].
>> >>
>> >> At this point, I think, if we can target March 2017 for releasing a
>> >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
>> good
>> >> start. Some of the issues noted in that JIRA are indeed important ones
>> and
>> >> would need some review/help in fixing them correctly, which
essentially
>> >> means, we need at least one person who has had experience with the Ivy
>> code
>> >> and its design details and also has the committer rights.
>> >>
>> >>
>> >> Does any of this look feasible? Let me know if this isn't enough to
move
>> >> things forward - I don't want to end up sending PRs and spending time
on
>> >> this if there's no way we can get to a proper release in the next few
>> >> months.
>> >>
>> >>
>> >> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>> >>
>> >> [2] https://github.com/apache/ant-ivy/pull/11
>> >>
>> >> [3] https://github.com/apache/ant-ivy/pull/12
>> >>
>> >> -Jaikiran
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> >> For additional commands, e-mail: dev-h...@ant.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Sicker <boa...@gmail.com>
>> >
>>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Re: Ivy - Proposal for reviving the project and moving towards a release

2016-12-11 Thread J Pai

I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
iron out any issues involved in the process itself which, from what I read
in the other thread, might involve certain challenges for the first time.

-Jaikiran

On Sunday, December 11, 2016, Matt Sicker  wrote:
> Do we really need a beta release? If you're working on bugfixes first,
then
> a regular 2.4.1 release would be great. It would go through the normal
> Apache release candidate process, and perhaps we could get some Gradle
> developers to test it out as well since they still seem to be big users of
> Ivy.
>
> Any committer to the Ant project could prepare the release and be a
release
> manager. The only requirements involving PMCs is to vote on approving the
> release; adding your GPG key to the KEYS file (only PMCs can commit to
that
> repository involved); and committing the artifacts to the release svn
> repository (again, PMCs). I'm also not a committer, but if you're
> interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
> bring you on board to do so.
>
>
> On 11 December 2016 at 08:22, Jaikiran Pai 
wrote:
>
>> First off, I'm not an Ivy or Ant committer. The proposal that I make
below
>> for an Ivy release is based on what was discussed in a recent mail thread
>> about the future of Ivy https://www.mail-archive.com/d
>> e...@ant.apache.org/msg45078.html. There was a suggestion that someone from
>> community volunteer to try and bring in some activity into the project
and
>> see if we can create a release after triaging the JIRA issues.
>>
>>
>> I have had a look at the open issues in JIRA today and decided to filter
>> out issues that are open, updated since Jan 2014 and affects versions
2.1,
>> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
select
>> a few that I thought can be considered "active". This [1] returns 57
>> issues. I went ahead and looked at those issues today and have asked for
>> more information in the JIRAs wherever relevant and have sent a couple of
>> pull requests [2] [3] to fix some straightforward ones. I also have
another
>> PR that I opened this week to fix one other issue. Out of those 57
issues,
>> many are no longer relevant or don't have enough details. I don't have
JIRA
>> privileges to label them, share filters or even assign some to myself to
>> track them better. So I think for now, we can rely on that JIRA search
>> query [1].
>>
>> At this point, I think, if we can target March 2017 for releasing a
>> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
good
>> start. Some of the issues noted in that JIRA are indeed important ones
and
>> would need some review/help in fixing them correctly, which essentially
>> means, we need at least one person who has had experience with the Ivy
code
>> and its design details and also has the committer rights.
>>
>>
>> Does any of this look feasible? Let me know if this isn't enough to move
>> things forward - I don't want to end up sending PRs and spending time on
>> this if there's no way we can get to a proper release in the next few
>> months.
>>
>>
>> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>>
>> [2] https://github.com/apache/ant-ivy/pull/11
>>
>> [3] https://github.com/apache/ant-ivy/pull/12
>>
>> -Jaikiran
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
>
> --
> Matt Sicker 
>

59 matches

Mail list logo