Re: Ivy - Goals for the upcoming release?

[Nicolas Lalevée]

> Le 21 mai 2017 à 18:34, Gintautas Grigelionis  a 
> écrit :
> 
> Now that Ant is upgraded, I suggest converting tests to JUnit 4 (which
> requires at least Ant 1.9.5, if I'm not mistaken). I can submit a patch
> pretty soon.
> 
> Introducing generics throughout (hey, that's a Java 5 feature!) would make
> the code easier to read (I've seen incorrect comments of what goes into a
> Map somewhere in the code). Unfortunately, in Ivy's case that requires even
> some changes in the API (can't have arrays of generics) and a few other
> design problems.

I don’t want to break your enthusiasm, but we should try to keep the API as 
stable as possible. I know the API is very wide, a lot is exposed, but we 
should be really careful at not breaking downside projects.

Also, PR are starting to pill up thanks to the good work of Jaikiran, so if 
there is big code change like adding a lot of generic in the code, it would be 
nice to wait a little bit so that merges will be easier.

> As for IvyDE, I was looking into getting rid of any deprecations and fixing
> the build.xml so that the dependencies can be retrieved by Ivy from Eclipse
> update sites. However, the honour of getting the current builds to work
> goes to Nicolas.

Any contribution to upgrade the dependencies of IvyDE is welcomed. For 
instance, I don’t even know if a PDE build can still be done with Eclipse 4.

Also, if some dependencies are too hard to get, like the GEF and Zest, we could 
get rid of them by stopping to support the « resolve visualizer ». And it could 
be decided that it is not abandoned but just temporarily disabled until someone 
find a way to correctly build it.

Nicolas

> 
> Gintas
> 
> 2017-05-21 16:41 GMT+02:00 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  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
>> 
>> 


-
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?

[Nicolas Lalevée]

> Le 21 mai 2017 à 16:28, J Pai  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 
> 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.

Sounds like a good plan.

Nicolas


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

Re: Ivy - Buildjobs/PreCommit

[Nicolas Lalevée]

> Le 20 mai 2017 à 11:18, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit :
> 
> 
>> Le 20 mai 2017 à 04:45, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> 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).
> 
> I have seen that. In the config I didn’t see any obvious option that fix that.

Seems to be working now. At least for that PR:
https://github.com/apache/ant-ivy/pull/26 
<https://github.com/apache/ant-ivy/pull/26>

That’s awesome!

Nicolas

Re: Ivy - BasicURLHandler ignoring timeout during connection?

[Nicolas Lalevée]

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  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

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

[Nicolas Lalevée]

Ant Bylaws is a good read to understand the process
https://ant.apache.org/bylaws.html 

Since the initial question is about Ivy only, another vote will be needed for 
IvyDE.

Nicolas

> Le 20 mai 2017 à 04:47, J Pai  a écrit :
> 
> 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

[Nicolas Lalevée]

> Le 20 mai 2017 à 04:45, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> 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).

I have seen that. In the config I didn’t see any obvious option that fix that.

> 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.

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/ 
<https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-Windows/>
https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-Linux/ 
<https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-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.

Nicolas

> 
> -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 t

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

[Nicolas Lalevée]

+1

Be able to test on an old jvm will be near impossible for me.

Nicolas

> Le 19 mai 2017 à 07:25, Jan Matèrne  a écrit :
> 
> 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

[Nicolas Lalevée]

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:
>>> 
>>> 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)?
>>>&g

Re: Minimum Java runtime version for proposed upcoming Ivy release

[Nicolas Lalevée]

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  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

Re: Jenkins build is back to normal : IvyDE-updatesite #787

[Nicolas Lalevée]

The build was broken because Ant was requiring a JDK 8. So I have setup the 
build to use the latest JDK 8.

> Le 17 mai 2017 à 20:31, Apache Jenkins Server  a 
> écrit :
> 
> See 
> 


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

Re: [jira] [Resolved] (IVY-1520) Have makepom task take description from ivy-module > info > description element

[Nicolas Lalevée]

FYI, the things fixed in the master in git are marked in jira « master » as « 
fix version », so that we can just rename it when the release is done, wether 
we do a 2.5.0 or 2.4.x.
Here we’ll indeed do a 2.5.0, but since others jira are already marked as on « 
master », I changed this one.

Nicolas

> Le 17 mai 2017 à 14:36, Jan Matèrne (JIRA)  a écrit :
> 
> 
> [ 
> https://issues.apache.org/jira/browse/IVY-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Jan Matèrne resolved IVY-1520.
> --
>   Resolution: Fixed
>Fix Version/s: 2.5.0-RC1
> 
>> Have makepom task take description from ivy-module > info > description 
>> element
>> ---
>> 
>>Key: IVY-1520
>>URL: https://issues.apache.org/jira/browse/IVY-1520
>>Project: Ivy
>> Issue Type: Improvement
>> Components: Ant
>>   Affects Versions: 2.4.0
>>   Reporter: Eric Milles
>>   Priority: Minor
>>Fix For: 2.5.0-RC1
>> 
>> 
>> I've been exploring the Ant ivy:makepom task in more detail and found that I 
>> can transfer the module, organisation and homepage from the original Ivy 
>> file but not the description.  The docs for makepom say that I can set 
>> property ivy.pom.description or use a description element.  But using either 
>> of these does not present me with a straightforward means of transferring 
>> the description from the resolved Ivy file.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)


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

Re: Ivy - Buildjobs/PreCommit

[Nicolas Lalevée]

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 

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)  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) 
>> 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  wrote:
>>> 
>>> 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: 

Re: Ivy+IvyDE: help wanted

[Nicolas Lalevée]

> Le 16 mai 2017 à 13:11, J Pai  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)  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

Re: VOTE Retire IvyDE

[Nicolas Lalevée]

Considering the current discussion around IvyDE and the involvement of Gintas, 
maybe we could cancel this vote, at least postpone it ?

Nicolas

> Le 5 déc. 2016 à 08:04, Jan Matèrne (jhm)  a écrit :
> 
> I start a vote for retiring IvyDE.
> 
> The last release was in 11/2013.
> 
> The last 'real' code activity was in 08/2014.
> 
> 
> 
> It seems that we havent the community, committers and PMC to hold this
> subproject. 
> 
> 
> 
> The general procedure is described in http://ant.apache.org/processes.html.
> 
> 
> 
> 
> 
> I start with my +1.
> 
> 
> 
> 
> 
> Jan
> 


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

IvyDE status (Was: VOTE Retire IvyDE)

[Nicolas Lalevée]

I am forking the thread to not pollute the vote.

> Le 7 déc. 2016 à 19:56, Gintautas Grigelionis  a 
> écrit :
> 
> I decided to take a quick look at the build process and it's not broken per
> se, rather it's hardcoded to Eclipse SDK 3.7.1 foe Win32.

You confirm the doc is being correctly build ? If that effectively the case, it 
is good to know, thank you for looking into it.
But one thing is broken for sure: the Ant targets to build IvyDE for the 
release, because they still assert that the sources are being hosted in 
subversion.

> I would like to
> make the process to adapt to the build platform. Any suggestions for a
> reasonable Eclipse baseline? Should we target Java 8, that would be 4.5 (or
> maybe even 4.5.2).

Here is what is currently supported:
http://ant.apache.org/ivy/ivyde/history/trunk/compatibility.html 

It certainly can be reviewed.

As a general rule I would make IvyDE support the same version of the JVM as Ivy 
and Eclipse does. A thing to note is that some IvyDE users are installing it in 
their IBM RAD editor, so it would be nice to continue supporting if it doesn’t 
require much effort.

Nicolas

Re: VOTE Retire IvyDE

[Nicolas Lalevée]

> Le 7 déc. 2016 à 12:34, Gintautas Grigelionis  a 
> écrit :
> 
> I would prefer an agreement on status. IvyDE is dependent on Ivy and
> ideally their release cycles should be synced.
> Since there seem to be some changes brewing in Ivy, IvyDE could be used as
> a test case.

Actually there is no need for synchronization between both project, unless 
there is a new feature in Ivy required for IvyDE. In the Eclipse updatesite 
there are two separate « Eclipse features », and one is dedicated to the 
version of Ivy you want to install.

Nicolas


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

Re: VOTE Retire IvyDE

[Nicolas Lalevée]

+1

Nicolas

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


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

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

[Nicolas Lalevée]

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

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

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

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

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

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

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

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

Nicolas


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

Re: VOTE Retire EasyAnt subproject

[Nicolas Lalevée]

+1

Nicolas

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


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

Re: DISCUSS How to retire a subproject/component

[Nicolas Lalevée]

Hi,

See my comments inline.

> Le 25 nov. 2016 à 08:18, Jan Matèrne (jhm)  a écrit :
> 
> There aren't as many comments as I hoped to get ...
> A main comment was that we also need a process of reactivating a subproject.
> 
> So here are the updated proposals for the two processes/todo-lists.
> 
> Again - please comment.
> 
> 
> Jan
> 
> 
> --
> 
> The retirenment of a subproject/component is started by a formal vote of the
> Ant PMC.
> 
> When retiring a subproject/component, what should and have we to do?
> Basically we have to announce it and make resources read-only. 
> 
> - version control
> 
>  Most of our source code is in git, only "site" and "sandbox" use subversion.
>  I propose to simply place a marker file on the top level.
>  Copying/Moving to another location as Tomcat does on subversion 
>  (svn.a.o/repos/asf/tomcat/archive) doesn't make sense to me as with git we
>  always have a complete repository.
> 
>  The marker file (e.g. "RETIRED_PROJECT") could contain the result of the 
> vote,
>  or further information like who to contact in case of reactivation. 
> 
>  Add a note at the top of a README file as well so it is immediately visible 
>  to people browsing the github mirror.  
> 
>  We should ask infra to make the central repository read-only.
> 
> - issue tracker
> 
>  If the subproject/component has its own issue tracker we have to close that.
>  It is enough to make it read-only, so these information are longer available.
> 
> - mailing list
> 
>  If the subproject/component we have to close this. We should send a final 
>  email.
> 
> - announcement
> 
>  We have to announce the retirement of the subproject at dev@ant, 
>  announce@apache and the Ant main page.
> 
> - build jobs 
> 
>  All build jobs on Jenkins@Apache, TeamCity and Gump have to be deleted.
> 
> - homepage
> 
>  We could create an "attic/archive" page and list all retired subprojects.
> 
>  Here we could also place information about the 
>  * the retirement "process"
>  * where to find the old resources (vcs, mail archive, issue tracker)
>  * who to ask current questions  
>  * how to reactivate 
> 
> - release further resources
> 
>  Maybe a subproject locks further resources (update-site, ...). So we have
>  to release them?   

I don’t understand this. How a retirement of a sub project should trigger the 
release of a related project ?

And about the Eclipse updatesite, it can be viewed as the production of extra 
binary artifacts for the ease of end users, just like there are binary jars 
next to the sources for Ant. The Eclipse update site is not a project per se. 
So we shouldn’t have a specific process for it. It is a responsibility for the 
Ivy and the IvyDE sub projects to integrate it in their release process.

This topic raises another question. What should we do about the artifact 
released in dist ? I guess we should delete them so they get archived ?


> ---
> 
> The Ant PMC start the reactivation of a subproject/component by a formal vote.
> 
> When reactivating a subproject/component, what should and have we to do?
> Basically we have to announce it and make resources read-write again. 
> 
> - version control
> 
>  Delete the marker file (e.g. "RETIRED_PROJECT"). 
> 
>  Delete the note at the top of a README file as well so it is immediately 
>  visible to people browsing the github mirror.  
> 
>  We should ask infra to make the central repository read-write again.
> 
> - issue tracker
> 
>  If the subproject/component has its own issue tracker we have to reopen that.
> 
> - mailing list
> 
>  Because reopeing implies a smaller community we should use the main 
> mailinglist
>  dev@ant. So reactivating a special list is not required and could be 
> postponed
>  to a later PMC decision.
> 
> - announcement
> 
>  We should announce the reactivation of the subproject dev@ant?

The formal vote has no special reason to be private, so I guess everything will 
be discussed and advertised there.

>  Do we have to announce the reactivation of the subproject announce@apache?

I think it will depend on the community involved, if they want more publicity.

> - build jobs 
> 
>  New build jobs on Jenkins@Apache, TeamCity and Gump could be created as
>  required. 
> 
> - homepage
> 
>  If we have an "attic/archive" page remove it from there.
> 
> - reactivate further resources
> 
>  Make existing read-only resources read-write again.
>  Further resources could be gained as required. 


So generally, looks good to me too, +1.

Thank you Jan.

Nicolas


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

Re: [VOTE] Release Ant 1.9.7 based on RC1

[Nicolas Lalevée]

+1

Nicolas

> Le 9 avr. 2016 à 12:03, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> I've created a release candidate for 1.9.7:
> 
> git tag: ANT_197_RC1
> on commit: cecbf5c
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>  revision: 13103
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapacheant-1009/org/apache/ant/
> 
> Vote will be open at least for 72 hours and close no earlier than 2016-04-12
> 10: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: [VOTE] Stephen Haberman as a committer

[Nicolas Lalevée]

+1

Nicolas

> Le 5 oct. 2015 à 11:06, Conor MacNeill  a écrit :
> 
> I would like to nominate Stephen Haberman as a committer. Stephen has
> submitted a number of well tested patches to the Ivy codebase. I
> believe adding Stephen would strengthen the committer-base,
> particularly for the Ivy Sub-project.
> 
> Please vote
> 
> [ ] +1 Add Stephen as a committer
> [ ] -1 Disagree
> [ ] +0 - Don't care.
> 
> I will start proceedings with my +1
> 
> Thanks
> Conor
> 
> -
> 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: Roadmap, goals, future of Ivy?

[Nicolas Lalevée]

Le 23 août 2015 à 20:10, Stephen Haberman stephen.haber...@gmail.com a écrit :
 
 Hi Jaikiran,
 
 FWIW I've made similar complaints about inactivity on Ivy, and suggested
 awhile ago that Ivy needs a new group of committers/contributors who are
 willing/able to put the time into the project.
 
 But nothing has happened.
 
 Which I found somewhat ironic, because I watched Apache Spark go through
 the incubation process, and Spark already had an extremely healthy open
 source community. And yet they were still occasionally lectured about the
 Apache Way of nurturing a healthy community/project.
 
 Which is fine, totally understood the Apache people were just trying to
 help Spark's long-term success; but then when I look at projects like Ivy,
 which is extremely widely used (embedded in Gradle, sbt, pants, used
 standalone via Ant, etc.), but the developer community is basically dead,
 well, it makes me wonder where the Apache Way zealots are and what went
 wrong.

Even if it fails, I still think the Apache way is the best way.
The goal is to have a project with active people maintaining it. In order to 
have people involved in the long run, as careers and interests change, a 
project need a process to make people able to come and go. And there should be 
an cohesion of that active group, so you should not let everybody come in.
But at some point, when the active people has already disappeared before fresh 
blood comes in, there is an issue. There was simply not enough people 
interested in developping. It make me thinks of the project OpenSSL, which kind 
of heavily used but not much maintained. That’s the kind of issue we have here.

But we’ll resolve the issue also the Apache way, just like you did with your 
email and this thread. We’re discussing it. :)

I think the best course here is for some committers to take time to review 
patches, and hopefully very soon to get the contributors to get committers.

So I reviewed some suggested patch. I have committed two. Some others are more 
difficult, not due to the patch but to Ivy’s code. I’ll came back to it later, 
if somebody else doesn’t, like for IVY-1430.

If you have some issues which are important to you than others, you’ll welcome 
to point them so we get them checked in sooner.

Nicolas


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

Re: Looking to contribute

[Nicolas Lalevée]

 Le 16 juil. 2015 à 14:14, Jaikiran Pai jai.forums2...@gmail.com a écrit :
 
 Hi Jean-Louis,
 
 I'm thinking of submitting via pull requests. I had a quick look at the open 
 JIRAs and haven't yet narrowed down on my first choice yet (just to get 
 started familiarizing myself with the code). I found this one 
 https://issues.apache.org/jira/browse/IVY-1526 which I think I can help with 
 after discussing how we want to go about it.
 
 If you have any other issues in mind, which might be a better start, then 
 please do let me know.
 
 By the way, just to be clear, the minimum Java version is meant to mean the 
 *target* Java version against which Ivy should be usable, right?

Yes.
And actually it is now 1.5. See the master branch (for some reason github is 
pointing by default to the 1.4.x, we never took time to investigate why):
https://github.com/apache/ant-ivy/blob/master/build.properties 
https://github.com/apache/ant-ivy/blob/master/build.properties

Here are some documentation explaining it:
http://ant.apache.org/ivy/history/latest-milestone/compatibility.html 
http://ant.apache.org/ivy/history/latest-milestone/compatibility.html

Nicolas

 -Jaikiran
 On Thursday 16 July 2015 05:38 PM, Jean-Louis Boudart wrote:
 The best you can do to help us would be to try to submit patches either via
 JIRA attachemnet or via pull requests.
 
 Let me know if you need some more informations.
 
 2015-07-16 14:06 GMT+02:00 Jean-Louis Boudart jeanlouis.boud...@gmail.com:
 
 Hi,
 
 Current java minimum version is defined in build.properties[1] of the
 project and is currently set to 1.4.
 Considering that Ant upgrade miminal java version to java 1.5 we should
 probably do the same on ivy.
 
 [1] https://github.com/apache/ant-ivy/blob/1.4.x/build.properties
 
 2015-07-16 6:23 GMT+02:00 Jaikiran Pai jai.forums2...@gmail.com:
 
 I'm thinking of contributing to the Ivy project. I had a quick look at
 the JIRAs that are open and also have checked out the latest source code
 from git. Before starting off with anything, I would like to know what is
 the Java version that should be used by contributors for code
 contributions? I couldn't find this in any document that I read (I can send
 a patch to the docs itself when I know the answer).
 
 -Jaikiran
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 --
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 

Re: [VOTE] Release Ant 1.9.6 based on RC1

[Nicolas Lalevée]

LGTM.
+1 for the release

Nicolas

 Le 29 juin 2015 à 11:32, Stefan Bodewig bode...@apache.org a écrit :
 
 Hi all
 
 I've created a release candidate for 1.9.6:
 
 git tag: ANT_196_RC1
 hash: a143e2d3a
 on commit: b09976c
 tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 9551
 Maven artifacts:
  
 https://repository.apache.org/content/repositories/orgapacheant-1008/org/apache/ant/
 
 Vote will be open at least for 72 hours and close no earlier than Thu
 2nd July 2015 9:30UTC.
 
 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: Doing a quick 1.9.5.1? (was Re: ant git commit: COMPRESS-317 ArrayIndexOutOfBoundsException in ZipArchiveEntry#getMergedFields)

[Nicolas Lalevée]

I don’t much about popularity of these extra fields, but the bug seems annoying 
enough and the fix trivial enough to release an Ant 1.9.6 (I don’t see the need 
to add an extra number to the version).
So +1.

Nicolas

 Le 9 juin 2015 à 06:34, Stefan Bodewig bode...@apache.org a écrit :
 
 On 2015-06-09, bode...@apache.org wrote:
 
 COMPRESS-317 ArrayIndexOutOfBoundsException in
 ZipArchiveEntry#getMergedFields
 
 Too bad this hasn't been found two weeks before.
 
 Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/6e34f177
 
 Whenever the extr fields of a ZIP entry are read that contains an extra
 field we cannot parse because it doesn't follow the recommendation by
 the spec we'll throw.  The extra fields are read internally when copying
 entries from one archive to another or when looking for
 UnicodeExtraFields.
 
 To me this sounds serious enough to warrant a new release, that I'm
 willing to act as RM for.
 
 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: Bug 56721 - back quote and quote

[Nicolas Lalevée]

 Le 10 juin 2015 à 08:21, Jan Matèrne j...@materne.de a écrit :
 
 https://bz.apache.org/bugzilla/show_bug.cgi?id=56721
 
 
 
 The user was irritated by the quoting of the build sequence:
 
 Build sequence for target(s) `release' is [-set-mode-check,
 -set-release-mode, ...
 
 
 
 It starts with a 
 
 `
 
 but ends with a 
 
 '
 
 
 
 I have no problem with changing both to single quote '
 
 On the other hand I dont see any benefit.
 
 But what do you think?

My first though was: who cares ?
Then : that back quote try to put some style to some rude output, why change ?
And then : what is the right way to quote ?
I ended here: http://en.wikipedia.org/wiki/Quotation_mark#Electronic_documents 
http://en.wikipedia.org/wiki/Quotation_mark#Electronic_documents
It seems that backquote is a kind of a hack, because semantically wrong. The 
RIGHT way should be about using the unicode characters U+2018 and U+2019.
But let’s not shoot ourself in the foot by playing with other than ASCII 
characters in the output.
We should indeed use the apostrophe as a start of the quoting.

So the nerd me is about changing.
The normal me don’t care much :)

Nicolas

Re: [VOTE] Release Ant 1.9.5 based on RC1

[Nicolas Lalevée]

+1

Nicolas

 Le 31 mai 2015 à 16:46, Stefan Bodewig bode...@apache.org a écrit :
 
 Hi all
 
 I've created a release candidate for 1.9.5:
 
 git tag: ANT_195_RC1
 hash: 54ac2fedd
 on commit: ea7bf28
 tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision: 9181
 Maven artifacts:
  
 https://repository.apache.org/content/repositories/orgapacheant-1007/org/apache/ant/
 
 Vote will be open at least for 72 hours and close no earlier than Wed
 3rd June 2015.
 
 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: [jira] (IVY-1197) OutOfMemoryError during ivy:publish

[Nicolas Lalevée]

 Le 9 avr. 2015 à 16:51, Maarten Coene maarten_co...@yahoo.com.INVALID a 
 écrit :
 
 I'm not a fan of this proposal, I like it that Ivy doesn't has any 
 dependencies when using standard resolvers.
 Perhaps it could be added to the documentation that if you use the 
 URLresolver for large uploads you'll have to add httpclient to the classpath?

+1
And considering we are packaging Ivy for Eclipse, we would have to make somehow 
httpclient installed there if not.

Nicolas

 
 
 Maarten
 
 
 
 
 - Oorspronkelijk bericht -
 Van: Antoine Levy Lambert anto...@gmx.de
 Aan: Ant Developers List dev@ant.apache.org
 Cc: 
 Verzonden: donderdag 9 april 3:50 2015
 Onderwerp: Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish
 
 Also, I wonder whether we should not make the use of httpclient with ivy 
 compulsory, since Loren says that the HttpUrlConnection of the JDK is always 
 copying the full file into a ByteArray when authentication is performed.
 
 That would make the code more simple.
 
 Regards,
 
 Antoine
 
 On Apr 7, 2015, at 9:22 PM, Antoine Levy Lambert anto...@gmx.de wrote:
 
 Hi,
 
 I wonder whether we should not upgrade ivy to use the latest http client 
 library too ?
 
 Regards,
 
 Antoine
 
 On Apr 7, 2015, at 12:46 PM, Loren Kratzke (JIRA) j...@apache.org wrote:
 
 
  [ 
 https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483468#comment-14483468
  ] 
 
 Loren Kratzke edited comment on IVY-1197 at 4/7/15 4:45 PM:
 
 
 I would be happy to provide you with a project that will reproduce the 
 issue. I can and will do that. 
 
 Generally speaking from a high level, the utility classes are calling 
 convenience methods and writing to streams that ultimately buffer the data 
 being written. There is buffering, then more buffering, and even more 
 buffering until you have multiple copies of the entire content of the 
 stream stored in over sized buffers (because they double in size when they 
 fill up). Oddly, the twist is that the JVM hits a limit no matter how much 
 RAM you allocate. Once the buffers total more than about ~1GB (which is 
 what happens with a 100-200MB upload) the JVM refuses to allocate more 
 buffer space (even if you jack up the RAM to 20GB, no cigar). Honestly, 
 there is no benefit in buffering any of this data to begin with, it is just 
 a side effect of using high level copy methods. There is no memory 
 ballooning at all when the content is written directly to the network.
 
 I will provide a test project and note the break points where you can debug 
 and watch the process walk all the way down the isle to an OOME. I will 
 have this for you asap.
 
 
 was (Author: qphase):
 I would be happy to provide you with a project that will reproduce the 
 issue. I can and will do that. 
 
 Generally speaking from a high level, the utility classes are calling 
 convenience methods and writing to streams that ultimately buffer the data 
 being written. There is buffering, then more buffering, and even more 
 buffering until you have multiple copies of the entire content of the 
 stream stored in over sized buffers (because they double in size when they 
 fill up). Oddly, the twist is that the JVM hits a limit no matter how much 
 RAM you allocate. Once the buffers total more than about ~1GB (which is 
 what happens with a 100-200MB upload) the JVM refuses to allocate more 
 buffer space (even is you jack up the RAM to 20GB, no cigar). Honestly, 
 there is no benefit in buffering any of this data to begin with, it is just 
 a side effect of using high level copy methods. There is no memory 
 ballooning at all when the content is written directly to the network.
 
 I will provide a test project and note the break points where you can debug 
 and watch the process walk all the way down the isle to an OOME. I will 
 have this for you asap.
 
 
 
 -
 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: xooki to asciidoc, a proof of concept

[Nicolas Lalevée]

I did some other improvements with the convertor. I am quite happy with the 
result now. There are still some glitches, but I think it would be manageable 
to be fix them manually.

Then I tested with the website. It works nicely apart from the home page and 
the download page. These two pages are very web oriented. The first because of 
its layout. The second due to its form. I’m not sure what to do about them.

Nicolas

 Le 30 déc. 2014 à 20:57, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit 
 :
 
 
 Le 30 déc. 2014 à 17:16, Jean-Louis Boudart jeanlouis.boud...@gmail.com 
 mailto:jeanlouis.boud...@gmail.com a écrit :
 
 Hi Nicolas,
 
 Definitively yes !
 
 I was trying a similar approach with Jelly/markdown, but due to several
 issues and  lack of time i stopped there.
 I'm fine with asciidoc.
 
 Could you tell us how you imagine the next steps ?
 
 The next step would be to continue to write the migration, in the 
 xooki2asciidoc.js (see the htmltags filter, line 855). I have seen that 
 tables, and h1, h2, etc.. are still not handled properly.
 As soon as we are satisfied by the result, we actually do the migration and 
 check in the asciidoc files. We would then remove evrything about xooki. And 
 probably there will be some last manual edition to do that the automatic 
 migration didn’t handled well.
 
 Will xooki only be used to produced toc ?
 
 No need of xooki. I have managed to make asciidoctor read the toc.json, and 
 generate the proper html, exactly as xooki is doing it. See that nasty ruby 
 file, helpers.rb. :)
 
 What will be the flow to edit documentation pages ?
 
 The flow to edit the doc would simply to edit the .adoc files directly, there 
 won’t be any xooki files, we won’t need xooki anymore. The toc.json would 
 still be there too, to be edited manually. And there would be the asciidoctor 
 ant task to generate the .html files.
 
 Nicolas
 
 
 2014-12-29 23:21 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 Hi,
 
 I like xooki because it manages well the templating of the web pages, and
 it manage well how to build a toc. I hate when documentation is not «
 browsable », like in a wiki, and xooki handle it well.
 
 But is is quite slow, generating Ivy’s documentation can takes minutes.
 And on macos jrunscript is considered as a graphical app, so it get the
 focus. Launching it repeatedly makes the Mac unusable because every few
 second there is a new jrunscript app getting the focus.
 And the only web browser in which you can do inline editing is Firefox. It
 is a good web browser but unfortunately it is not my default one.
 
 Manually rewriting the entire doc in another template engine is out the
 question. And I don’t want to lose the automatic build of the toc.
 
 So, as a defi, I wondered if I could make xooki.js generate something in a
 template language rather than .html, and still generate that toc.
 
 I don’t know much any template language, even Markdown. On paper, asciidoc
 looks better to me, and some Linus recommends it, so let’s try it so I can
 have a little experience with it.
 
 A few hours of hacking later, doing dirty code in js, using Asciidoctor,
 coming down to write some Ruby (oh my!), I have something working. Hence my
 last commit in a dedicated branch in Ivy: xooki2asciidoc
 
 You can test it. To generate the asciidoc files:
 ant -f build-doc.xml generate-asciidoc
 To generate the html files from the asciidoc files (in few seconds!):
 ant -f build-doc.xml generate-doc
 And open build/doc/index.html to see the result
 
 This is a proof of concept, the conversion of the html tags barely works,
 but the toc is functional.
 
 So what do you think ? Would you consider changing of template language ?
 If so would it be asciidoc ?
 
 Is there any objection ? I spent some time on it for fun (and passing time
 because of some quite late trains), I won’t mind if this is thrown away;
 but I would like to know if there are some so I won’t continue it.
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org 
 mailto:dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org 
 mailto:dev-h...@ant.apache.org

Re: [Ivy] A workspace resolver for Ant

[Nicolas Lalevée]

 Le 26 janv. 2015 à 00:38, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Hello Nicolas,
 
 I am trying to understand in which use case I would need this resolver. It 
 seems to be in the case that you want to build using Ant a stack of modules 
 in a directory tree, and use the target/classes folder of each module as a 
 dependency.
 
 Does this workspace resolver also has something for test classes which 
 usually are output to a different root folder (for instance 
 target/test-classes).

Good use case yes. This is not supported by the current code, since we need to 
define a configuration. But I guess we could write something like this:

ivy:configure file=ivysettings.xml
 workspaceResolver name=myresolver
 fileset dir=${basedir} includes=*/ivy.xml /
 artifact conf=runtime type=dir ext= path=target/classes /
 artifact conf=test type=dir ext= path=target/test-classes /
 /workspaceResolver
/ivy:configure

Also not supported right now, real artifact files could be defined like that:
artifact name=[module] type=jar ext=jar path=target/dist/[module].jar 
/
artifact name=[module] type=source ext=jar 
path=target/dist/[module]-sources.jar /

And things we should look at also are the ant triggers from Ivy. The ideal use 
case will be that a workspace resolver will figure out which project is needed 
to build the current one, and thus trigger a build of the selected dependent 
project.

Nicolas

 
 Best regards Nicolas, great to see all the work you do for ivy.
 
 Antoine
 
 
 
 On Jan 25, 2015, at 4:51 PM, Nicolas Lalevée nicolas.lale...@hibnet.org 
 wrote:
 
 Hi,
 
 We’ve been wondering if the workspace resolver which exists for IvyDE could 
 be transposed to the Ant world. I think I have made a working one. And I 
 just pushed it.
 
 The main issue in the design was about how Ant would be able to describe to 
 Ivy the projects to take into account, and which would then be their 
 artifacts. As a principle, I didn’t want to declare the workspace resolver 
 in the ivysettings. Because the settings, for me, should be quite 
 independent of the environment is it used. For instance I want it to work 
 both within an Ant build file and in Eclipse with IvyDE. And IvyDE’s 
 workspace resolver doesn’t need a modification of the end user's ivysettings 
 in order to properly work.
 
 To describe the modules, I just used a fileset of the ivy.xml files of the 
 projects. Then everything would be relative to them, just like the buildlist 
 ant task is working.
 
 Then about declaring the artifacts, I have made them explicit. This might 
 not be the most flexible. I’m not sure how to do better though.
 
 Then the integration with Ant would be done via the configure task. Here an 
 exemple.
 
 ivy:configure file=ivysettings.xml
  workspaceResolver name=myresolver
  fileset dir=${basedir} includes=*/ivy.xml /
  artifact type=dir ext= path=target/classes /
  /workspaceResolver
 /ivy:configure
 
 
 I have only did some small unit tests for now. This need some proper 
 integration test to be fully validated.
 
 Any comment is welcomed.
 
 Nicolas
 
 
 -
 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: issue with IBiblioResolverTest.testErrorReport

[Nicolas Lalevée]

 Le 26 janv. 2015 à 00:56, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Hi,
 
 when I run the ivy test suite on my computer at home, the 
 iBiblioResolverTest.testErrorReport errors.
 
 The error happens on line 251 :
 
 ResolvedModuleRevision rmr = resolver.getDependency(new 
 DefaultDependencyDescriptor(mrid,
false), _data);
 
 What happens on that line is that :
 
 - the proxy that I use at home produces an HTML5 error report about the 
 http://unknown.host.comx 
 - this error report is consumed by ivy as if it was a POM file and generates 
 this exception :
 
 java.text.ParseException: Already seen doctype.
 at 
 org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.newParserException(PomModuleDescriptorParser.java:375)
 
 One workaround to deal with that is to surround the call to 
 resolver.getDependency with try/catch and also to remove the last assertion :
 assertLogContains(tried 
 http://unknown.host.comx/org/apache/commons-fileupload/1.0/commons-fileupload-1.0.jar”)
 
 This of course is a workaround.
 
 Is it also an intelligent solution ? 
 
 Is the normal behavior when trying to access a non existent host name to get 
 an UnknownHostException ?

I don’t know much about proxy, but considering the IP stack, I would understand 
that the IP is resolved, thus to be the IP of the proxy. But then I don’t 
understand why Ivy is not properly failing. I would expect the proxy to at 
least return a 404. Could you confirm the HTTP status ? You can put a break 
point in BasicURLHandler#checkStatusCode.

Nicolas


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

[Ivy] A workspace resolver for Ant

[Nicolas Lalevée]

Hi,

We’ve been wondering if the workspace resolver which exists for IvyDE could be 
transposed to the Ant world. I think I have made a working one. And I just 
pushed it.

The main issue in the design was about how Ant would be able to describe to Ivy 
the projects to take into account, and which would then be their artifacts. As 
a principle, I didn’t want to declare the workspace resolver in the 
ivysettings. Because the settings, for me, should be quite independent of the 
environment is it used. For instance I want it to work both within an Ant build 
file and in Eclipse with IvyDE. And IvyDE’s workspace resolver doesn’t need a 
modification of the end user's ivysettings in order to properly work.

To describe the modules, I just used a fileset of the ivy.xml files of the 
projects. Then everything would be relative to them, just like the buildlist 
ant task is working.

Then about declaring the artifacts, I have made them explicit. This might not 
be the most flexible. I’m not sure how to do better though.

Then the integration with Ant would be done via the configure task. Here an 
exemple.

ivy:configure file=ivysettings.xml
   workspaceResolver name=myresolver
   fileset dir=${basedir} includes=*/ivy.xml /
   artifact type=dir ext= path=target/classes /
   /workspaceResolver
/ivy:configure


I have only did some small unit tests for now. This need some proper 
integration test to be fully validated.

Any comment is welcomed.

Nicolas


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

Generating EasyAnt website

[Nicolas Lalevée]

Hi,

I tried to fixed the issues raised by Sebb about the links in EasyAnt’s website 
and I got issues.

I am not sure which target should be called to get things generated. The 
command « easyant -p » is listing the usual targets for a project with a bunch 
of code, but this is not helpful and unrelated to what I want to do with the 
sources of a website. Looking at the source of the build, I can see some 
specific targets, but nothing get actually generated in the « production » 
folder. Any hint on how to generate the site ?

Nicolas


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

Re: ant git commit: Arrays.copyOf is Java 1.6 only

[Nicolas Lalevée]

 Le 21 janv. 2015 à 12:10, Stefan Bodewig bode...@apache.org a écrit :
 
 On 2015-01-21, Jan Matèrne (jhm) wrote:
 
 right, we are tied to Java1.5
 http://ant.apache.org/faq.html#java-version
 
 
 http://www.oracle.com/technetwork/java/eol-135779.html
 End of public updates:
 Java5: Oct 2009
 Java6: Feb 2013
 Java7: Apr 2015 (maybe later)
 Java8: Mar 2017 (maybe later)
 
 Extended support:
 Java5: May 2015 !!!
 Java6: Dec 2018
 Java7: Jul 2022
 Java8: Mar 2025
 
 
 I think after ending the extended support for Java5 we could update here
 this year ...
 WDYT?
 
 No problem with that, but we should also increment the minor release
 version then.

I second that.

 BTW good we've got a Jenkins build on 1.5, I would have never caught
 that.

Same here, keeping an old jvm installed on my machine is too painful.

Nicolas

Re: Git workflow

[Nicolas Lalevée]

 Le 11 janv. 2015 à 18:46, Stefan Bodewig bode...@apache.org a écrit :
 
 On 2015-01-11, Nicolas Lalevée wrote:
 
 By the way, is there any way to close manually the pull requests in
 github ? The only way is to reference it in a git commit ?
 
 Probably some infra folks can since you need write access to the github
 apache organization.
 
 You can create empty commits (--allow-empty), I've done so for one
 invalid PR already.

Ok, good to know.

I’m not sure though why some of my commits didn’t get to do it:
https://github.com/apache/ant-ivy/commit/3f9eb02b76c31665b6ff44b11d4017f08065f4f3
 
https://github.com/apache/ant-ivy/commit/3f9eb02b76c31665b6ff44b11d4017f08065f4f3
https://github.com/apache/ant-ivy/commit/6b2eba430bd7abdef4e9c7851acf6b2c2459cb6d
 
https://github.com/apache/ant-ivy/commit/6b2eba430bd7abdef4e9c7851acf6b2c2459cb6d

Nicolas

Re: Git workflow

[Nicolas Lalevée]

By the way, is there any way to close manually the pull requests in github ? 
The only way is to reference it in a git commit ?

Nicolas

 Le 11 janv. 2015 à 13:17, Nicolas Lalevée nicolas.lale...@hibnet.org a 
 écrit :
 
 
 Le 7 janv. 2015 à 05:57, Stefan Bodewig bode...@apache.org a écrit :
 
 On 2015-01-07, Nicolas Lalevée wrote:
 
 For instance, to get commits from one branch to the other, I have seen
 two ways: via merge or via cherry-pick.
 Since our branches are meant to diverge à some point, I think using
 cherry-pick should be used, right ?
 
 Alternatively develop the feature on a third branch, merge that branch
 into both others and delete the feature branc afterwards.
 
 Yep, that is a great feature of git too.
 
 
 And about merging pull request, there is the direct pull, for instance:
 git pull https://github.com/jbaruch/ant-ivy
 https://github.com/jbaruch/ant-ivy patch-1
 
 And there is the rebase way, exemple:
 
 The approach I've seen taken a lot on github is to have the submitter of
 the pull request rebase (and squash) the PR before you merge it.
 Squashing means you juts get a single clean commit rather than a
 sequence of refinements.
 
 Ok.
 I find it strange that there is not a simpler way to do it from the merger 
 point of view.
 
 Nicolas
 


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

Re: Git workflow

[Nicolas Lalevée]

 Le 7 janv. 2015 à 05:57, Stefan Bodewig bode...@apache.org a écrit :
 
 On 2015-01-07, Nicolas Lalevée wrote:
 
 For instance, to get commits from one branch to the other, I have seen
 two ways: via merge or via cherry-pick.
 Since our branches are meant to diverge à some point, I think using
 cherry-pick should be used, right ?
 
 Alternatively develop the feature on a third branch, merge that branch
 into both others and delete the feature branc afterwards.

Yep, that is a great feature of git too.

 
 And about merging pull request, there is the direct pull, for instance:
 git pull https://github.com/jbaruch/ant-ivy
 https://github.com/jbaruch/ant-ivy patch-1
 
 And there is the rebase way, exemple:
 
 The approach I've seen taken a lot on github is to have the submitter of
 the pull request rebase (and squash) the PR before you merge it.
 Squashing means you juts get a single clean commit rather than a
 sequence of refinements.

Ok.
I find it strange that there is not a simpler way to do it from the merger 
point of view.

Nicolas


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

Git workflow

[Nicolas Lalevée]

Hi guys,

I am discovering a little bit of the extends of git, and it seems there are a 
lot of ways to handle branches and pull requests. Maybe we should all use the 
same way ?

For instance, to get commits from one branch to the other, I have seen two 
ways: via merge or via cherry-pick.
Since our branches are meant to diverge à some point, I think using cherry-pick 
should be used, right ?

And about merging pull request, there is the direct pull, for instance:
git pull https://github.com/jbaruch/ant-ivy 
https://github.com/jbaruch/ant-ivy patch-1

And there is the rebase way, exemple:
git remote add jbaruch https://github.com/jbaruch/ant-ivy
git checkout -b patch-1 jbaruch/patch-1
git rebase master
git checkout master
git merge --ff-only patch-1

I prefer the later one, because it produce a linear history, even if it quite 
painful on the command line. Any preferences ? Am I wrong ? Is there other 
options ?

Nicolas

Re: xooki to asciidoc, a proof of concept

[Nicolas Lalevée]

 Le 30 déc. 2014 à 17:16, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
 écrit :
 
 Hi Nicolas,
 
 Definitively yes !
 
 I was trying a similar approach with Jelly/markdown, but due to several
 issues and  lack of time i stopped there.
 I'm fine with asciidoc.
 
 Could you tell us how you imagine the next steps ?

The next step would be to continue to write the migration, in the 
xooki2asciidoc.js (see the htmltags filter, line 855). I have seen that tables, 
and h1, h2, etc.. are still not handled properly.
As soon as we are satisfied by the result, we actually do the migration and 
check in the asciidoc files. We would then remove evrything about xooki. And 
probably there will be some last manual edition to do that the automatic 
migration didn’t handled well.

 Will xooki only be used to produced toc ?

No need of xooki. I have managed to make asciidoctor read the toc.json, and 
generate the proper html, exactly as xooki is doing it. See that nasty ruby 
file, helpers.rb. :)

 What will be the flow to edit documentation pages ?

The flow to edit the doc would simply to edit the .adoc files directly, there 
won’t be any xooki files, we won’t need xooki anymore. The toc.json would still 
be there too, to be edited manually. And there would be the asciidoctor ant 
task to generate the .html files.

Nicolas

 
 2014-12-29 23:21 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 Hi,
 
 I like xooki because it manages well the templating of the web pages, and
 it manage well how to build a toc. I hate when documentation is not «
 browsable », like in a wiki, and xooki handle it well.
 
 But is is quite slow, generating Ivy’s documentation can takes minutes.
 And on macos jrunscript is considered as a graphical app, so it get the
 focus. Launching it repeatedly makes the Mac unusable because every few
 second there is a new jrunscript app getting the focus.
 And the only web browser in which you can do inline editing is Firefox. It
 is a good web browser but unfortunately it is not my default one.
 
 Manually rewriting the entire doc in another template engine is out the
 question. And I don’t want to lose the automatic build of the toc.
 
 So, as a defi, I wondered if I could make xooki.js generate something in a
 template language rather than .html, and still generate that toc.
 
 I don’t know much any template language, even Markdown. On paper, asciidoc
 looks better to me, and some Linus recommends it, so let’s try it so I can
 have a little experience with it.
 
 A few hours of hacking later, doing dirty code in js, using Asciidoctor,
 coming down to write some Ruby (oh my!), I have something working. Hence my
 last commit in a dedicated branch in Ivy: xooki2asciidoc
 
 You can test it. To generate the asciidoc files:
 ant -f build-doc.xml generate-asciidoc
 To generate the html files from the asciidoc files (in few seconds!):
 ant -f build-doc.xml generate-doc
 And open build/doc/index.html to see the result
 
 This is a proof of concept, the conversion of the html tags barely works,
 but the toc is functional.
 
 So what do you think ? Would you consider changing of template language ?
 If so would it be asciidoc ?
 
 Is there any objection ? I spent some time on it for fun (and passing time
 because of some quite late trains), I won’t mind if this is thrown away;
 but I would like to know if there are some so I won’t continue it.
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

xooki to asciidoc, a proof of concept

[Nicolas Lalevée]

Hi,

I like xooki because it manages well the templating of the web pages, and it 
manage well how to build a toc. I hate when documentation is not « browsable », 
like in a wiki, and xooki handle it well.

But is is quite slow, generating Ivy’s documentation can takes minutes.
And on macos jrunscript is considered as a graphical app, so it get the focus. 
Launching it repeatedly makes the Mac unusable because every few second there 
is a new jrunscript app getting the focus.
And the only web browser in which you can do inline editing is Firefox. It is a 
good web browser but unfortunately it is not my default one.

Manually rewriting the entire doc in another template engine is out the 
question. And I don’t want to lose the automatic build of the toc.

So, as a defi, I wondered if I could make xooki.js generate something in a 
template language rather than .html, and still generate that toc.

I don’t know much any template language, even Markdown. On paper, asciidoc 
looks better to me, and some Linus recommends it, so let’s try it so I can have 
a little experience with it.

A few hours of hacking later, doing dirty code in js, using Asciidoctor, coming 
down to write some Ruby (oh my!), I have something working. Hence my last 
commit in a dedicated branch in Ivy: xooki2asciidoc

You can test it. To generate the asciidoc files:
ant -f build-doc.xml generate-asciidoc
To generate the html files from the asciidoc files (in few seconds!):
ant -f build-doc.xml generate-doc
And open build/doc/index.html to see the result

This is a proof of concept, the conversion of the html tags barely works, but 
the toc is functional.

So what do you think ? Would you consider changing of template language ? If so 
would it be asciidoc ?

Is there any objection ? I spent some time on it for fun (and passing time 
because of some quite late trains), I won’t mind if this is thrown away; but I 
would like to know if there are some so I won’t continue it.

Nicolas


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

[RESULT][VOTE] Ivy 2.4.0 Release - take 2

[Nicolas Lalevée]

Counting my own +1, we have three +1 and one -1. The vote pass. I will publish 
the release.

Nicolas

 Le 22 déc. 2014 à 17:57, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit 
 :
 
 I have signed the tag:
 See 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0
  
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0
  
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0
 
 I’ve also build the updatesite ready to be published:
 https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/
  
 https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/
  
 https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/
  
 https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/
 
 And I’ve pushed the jars to the Nexus staging repository:
 https://repository.apache.org/content/repositories/orgapacheant-1006/ 
 https://repository.apache.org/content/repositories/orgapacheant-1006/
 
 So I think we’re good. For now we have one -1 and three +1 (including me).
 
 I’ll keep the vote open a couple of days, to be sure everyone had the time to 
 vote. And I’ll promote the artifacts.
 
 Nicolas
 
 Le 17 déc. 2014 à 14:25, Nicolas Lalevée nicolas.lale...@hibnet.org 
 mailto:nicolas.lale...@hibnet.org a écrit :
 
 
 Le 17 déc. 2014 à 04:09, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Nicolas, Jean-Louis, what are your thoughts ?
 
 The problem reported by Stefan with the ivy.xml in the source archive must 
 be caused by something in the build process replacing the ivy.xml of the 
 source tree with an expanded version of the same file generated when the 
 ivy:publish/ task runs ?
 
 The purpose of this change is that it fixes the dependencies of Ivy. I see 
 no particular harm here.
 
 But as Stefan, generally speaking, I prefer the source release to be an 
 extract of the source repository. So there is no possible confusion.
 
 I guess a minor edit in the build file to make this modified version of 
 ivy.xml go somewhere under the build folder should address this issue for 
 this release and the next ones.
 
 I have not spent myself a lot of time on ivy yet but I would like to spend 
 some in 2015 - or maybe even next week if my kids are busy out of the house 
 …
 
 I also know how it feels when one creates a release candidate and some 
 minor problems are found and one has to again go through 20 steps in a 
 ReleaseInstructions document …
 
 Actually releasing Ivy is quite straight forward, no issues with that.
 See: http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
 Probably the signing of the artifacts can be more automatic. I have seen 
 there is ant target for that but I haven’t tested it yet.
 
 What trouble me more is what is the exact process to push artifacts into 
 Maven repo after the release. And we’ll need to figure out how to push it 
 into the Eclipse updatesite too.
 
 But I am sure we will get there finally.
 
 I am sure too. We have to either be patient or actively act on it, depending 
 on our available time.
 
 On Dec 14, 2014, at 5:43 AM, Stefan Bodewig bode...@apache.org wrote:
 
 We should be using signed tags (git tag -s or -u) rather than
 lightweight tags for releases.  I know we haven't cut any releases from
 git so far, so we'll be learning as we go along.
 
 I do not know how it works, but I’ll figure it out. And update the release 
 documentation.
 
 Nicolas

[ANNOUNCE] Apache Ivy 2.4.0 Released

[Nicolas Lalevée]

December 26, 2014 - The Apache Ivy project is pleased to announce its 2.4.0 
release.
 
Apache Ivy is a tool for managing (recording, tracking, resolving and
reporting) project dependencies, characterized by flexibility,
configurability, and tight integration with Apache Ant.

Key features of this 2.4.0 release are
* some new Ant tasks
* improved OSGi support
* a Bintray resolver
* numerous bug fixes as documented in Jira and in the release notes

This version is highly recommended for Eclipse users. There were a
change with Eclipse Luna which broke some plugins, IvyDE included.
That last version of Ivy works around it. The update is available via
the IvyDE updatesite:
http://www.apache.org/dist/ant/ivyde/updatesite

You can download this 2.4.0 release at:
http://ant.apache.org/ivy/download.cgi
 
Issues should be reported to:
https://issues.apache.org/jira/browse/IVY
 
More information can be found on the website:
http://ant.apache.org/ivy/ http://ant.apache.org/ivy/

Re: [VOTE] Ivy 2.4.0 Release - take 2

[Nicolas Lalevée]

I have signed the tag:
See 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.4.0

I’ve also build the updatesite ready to be published:
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/
 
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.4.0.final_20141213170938/

And I’ve pushed the jars to the Nexus staging repository:
https://repository.apache.org/content/repositories/orgapacheant-1006/

So I think we’re good. For now we have one -1 and three +1 (including me).

I’ll keep the vote open a couple of days, to be sure everyone had the time to 
vote. And I’ll promote the artifacts.

Nicolas

 Le 17 déc. 2014 à 14:25, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit 
 :
 
 
 Le 17 déc. 2014 à 04:09, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Nicolas, Jean-Louis, what are your thoughts ?
 
 The problem reported by Stefan with the ivy.xml in the source archive must 
 be caused by something in the build process replacing the ivy.xml of the 
 source tree with an expanded version of the same file generated when the 
 ivy:publish/ task runs ?
 
 The purpose of this change is that it fixes the dependencies of Ivy. I see no 
 particular harm here.
 
 But as Stefan, generally speaking, I prefer the source release to be an 
 extract of the source repository. So there is no possible confusion.
 
 I guess a minor edit in the build file to make this modified version of 
 ivy.xml go somewhere under the build folder should address this issue for 
 this release and the next ones.
 
 I have not spent myself a lot of time on ivy yet but I would like to spend 
 some in 2015 - or maybe even next week if my kids are busy out of the house …
 
 I also know how it feels when one creates a release candidate and some minor 
 problems are found and one has to again go through 20 steps in a 
 ReleaseInstructions document …
 
 Actually releasing Ivy is quite straight forward, no issues with that.
 See: http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
 Probably the signing of the artifacts can be more automatic. I have seen 
 there is ant target for that but I haven’t tested it yet.
 
 What trouble me more is what is the exact process to push artifacts into 
 Maven repo after the release. And we’ll need to figure out how to push it 
 into the Eclipse updatesite too.
 
 But I am sure we will get there finally.
 
 I am sure too. We have to either be patient or actively act on it, depending 
 on our available time.
 
 On Dec 14, 2014, at 5:43 AM, Stefan Bodewig bode...@apache.org wrote:
 
 We should be using signed tags (git tag -s or -u) rather than
 lightweight tags for releases.  I know we haven't cut any releases from
 git so far, so we'll be learning as we go along.
 
 I do not know how it works, but I’ll figure it out. And update the release 
 documentation.
 
 Nicolas
 

Re: [VOTE] Ivy 2.4.0 Release - take 2

[Nicolas Lalevée]

 Le 17 déc. 2014 à 04:09, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Nicolas, Jean-Louis, what are your thoughts ?
 
 The problem reported by Stefan with the ivy.xml in the source archive must be 
 caused by something in the build process replacing the ivy.xml of the source 
 tree with an expanded version of the same file generated when the 
 ivy:publish/ task runs ?

The purpose of this change is that it fixes the dependencies of Ivy. I see no 
particular harm here.

But as Stefan, generally speaking, I prefer the source release to be an extract 
of the source repository. So there is no possible confusion.

 I guess a minor edit in the build file to make this modified version of 
 ivy.xml go somewhere under the build folder should address this issue for 
 this release and the next ones.
 
 I have not spent myself a lot of time on ivy yet but I would like to spend 
 some in 2015 - or maybe even next week if my kids are busy out of the house …
 
 I also know how it feels when one creates a release candidate and some minor 
 problems are found and one has to again go through 20 steps in a 
 ReleaseInstructions document …

Actually releasing Ivy is quite straight forward, no issues with that.
See: http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
Probably the signing of the artifacts can be more automatic. I have seen there 
is ant target for that but I haven’t tested it yet.

What trouble me more is what is the exact process to push artifacts into Maven 
repo after the release. And we’ll need to figure out how to push it into the 
Eclipse updatesite too.

 But I am sure we will get there finally.

I am sure too. We have to either be patient or actively act on it, depending on 
our available time.

 On Dec 14, 2014, at 5:43 AM, Stefan Bodewig bode...@apache.org wrote:
 
 We should be using signed tags (git tag -s or -u) rather than
 lightweight tags for releases.  I know we haven't cut any releases from
 git so far, so we'll be learning as we go along.

I do not know how it works, but I’ll figure it out. And update the release 
documentation.

Nicolas

Re: Develop custom Ivy parser

[Nicolas Lalevée]

 Le 17 déc. 2014 à 22:25, Martin Flores mflor...@gmail.com a écrit :
 
 Hi everyone, I'm about to develop to develop a custom Ivy parser but I
 haven't found enough information on the Ant/Ivy web sites about it.
 
 I already checkout the Ivy code but, I would like to know if someone can
 point me to a sample about how to integrate a custom parser on Ivy.

A parser need to implement the interface 
org.apache.ivy.plugins.parser.ModuleDescriptorParser.

Once you have an implementation, you will have to reference it in an 
ivysettings in order to use it.
First you’ll need to ensure that your implementation can be looked up by Ivy, 
either by ensuring that it is within Ivy’s classpath, or via the classpath 
element [1].
Then use typedef [2] to declare your parser. And finally create an instance of 
it, with some parameters if needed, by declaring the element of your parser.
It should look like that:

classpath file=myparser.jar /
tyepdef name=myparser classname=org.acme.MyParser /
myparser someparameter=somevalue /

Nicolas

[1] http://ant.apache.org/ivy/history/latest-milestone/settings/classpath.html 
http://ant.apache.org/ivy/history/latest-milestone/settings/classpath.html
[2] http://ant.apache.org/ivy/history/latest-milestone/settings/typedef.html 
http://ant.apache.org/ivy/history/latest-milestone/settings/typedef.html

Re: [VOTE] Ivy 2.4.0 Release - take 2

[Nicolas Lalevée]

Yes, it is already in the last attempt.

Nicolas

 Le 17 déc. 2014 à 22:56, anto...@gmx.de a écrit :
 
 Hi I think the bintray resolver is part of the future release.
 
 Antoine Levy-Lambert
 
 - Reply message -
 From: JBaruch jbar...@jfrog.com
 To: Ant Developers List dev@ant.apache.org
 Subject: [VOTE] Ivy 2.4.0 Release - take 2
 Date: Wed, Dec 17, 2014 3:47 PM
 
 Sorry to nag here, but any chance you can sneak the bintray resolver in?
 Now, when it has documentation and everything?
 Pretty please?
 
 Baruch.
 
 --
 JFrog Developer Advocate
 www.jfrog.com
 +972544954353
 @jbaruch https://twitter.com/jbaruch/
 http://linkd.in/jbaruch
 
 On Wed, Dec 17, 2014 at 5:25 AM, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
 
 Le 17 déc. 2014 à 04:09, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Nicolas, Jean-Louis, what are your thoughts ?
 
 The problem reported by Stefan with the ivy.xml in the source archive
 must be caused by something in the build process replacing the ivy.xml of
 the source tree with an expanded version of the same file generated when
 the ivy:publish/ task runs ?
 
 The purpose of this change is that it fixes the dependencies of Ivy. I see
 no particular harm here.
 
 But as Stefan, generally speaking, I prefer the source release to be an
 extract of the source repository. So there is no possible confusion.
 
 I guess a minor edit in the build file to make this modified version of
 ivy.xml go somewhere under the build folder should address this issue for
 this release and the next ones.
 
 I have not spent myself a lot of time on ivy yet but I would like to
 spend some in 2015 - or maybe even next week if my kids are busy out of the
 house …
 
 I also know how it feels when one creates a release candidate and some
 minor problems are found and one has to again go through 20 steps in a
 ReleaseInstructions document …
 
 Actually releasing Ivy is quite straight forward, no issues with that.
 See: http://ant.apache.org/ivy/history/trunk/dev/makerelease.html 
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
 Probably the signing of the artifacts can be more automatic. I have seen
 there is ant target for that but I haven’t tested it yet.
 
 What trouble me more is what is the exact process to push artifacts into
 Maven repo after the release. And we’ll need to figure out how to push it
 into the Eclipse updatesite too.
 
 But I am sure we will get there finally.
 
 I am sure too. We have to either be patient or actively act on it,
 depending on our available time.
 
 On Dec 14, 2014, at 5:43 AM, Stefan Bodewig bode...@apache.org wrote:
 
 We should be using signed tags (git tag -s or -u) rather than
 lightweight tags for releases.  I know we haven't cut any releases from
 git so far, so we'll be learning as we go along.
 
 I do not know how it works, but I’ll figure it out. And update the release
 documentation.
 
 Nicolas
 


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

Re: [CANCELED][VOTE] Release Ivy 2.4.0

[Nicolas Lalevée]

I pushed the current style folder into git so we can go forward with the 
release. If we have a better process later, we will just change it.

Nicolas

 Le 10 déc. 2014 à 10:57, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit 
 :
 
 Note that the style files are also useful to edit the doc within Ivy’s code 
 source. So this needs to be easily fetchable for contributors.
 
 Having to maintain the styles folders between the source and the site one 
 doesn’t seem that a burden. I prefer to have the burden on committers than on 
 contributors.
 
 Nicolas
 
 Le 10 déc. 2014 à 09:28, Jan Matèrne (jhm) apa...@materne.de a écrit :
 
 Security hint: 'pushing' is not as secure as 'polling' here ... Maybe
 passwords have to be configured...
 
 Jan
 
 -Ursprüngliche Nachricht-
 Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
 Gesendet: Mittwoch, 10. Dezember 2014 07:57
 An: 'Ant Developers List'
 Betreff: AW: [CANCELED][VOTE] Release Ivy 2.4.0
 
 The ideal solutions to all this headaches would probably to have
 everything
 in git (including ivy's website), unfortunatly as far as i know we
 can't publish website via git @ASF for the moment. Infra offers a
 gitpubsub feature but i read somewhere that we can't use it to publish
 websites.
 
 Would a Jenkins job help here?
 It could build the website from git and 'push' (not git push ;) it
 somewhere.
 
 
 Jan
 
 
 
 -Ursprüngliche Nachricht-
 Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
 Gesendet: Mittwoch, 10. Dezember 2014 01:18
 An: Ant Developers List
 Betreff: Re: [CANCELED][VOTE] Release Ivy 2.4.0
 
 Yes !!!
 
 Antoine
 On Dec 9, 2014, at 9:36 AM, Stefan Bodewig bode...@apache.org
 wrote:
 
 On 2014-12-09, Jean-Louis Boudart wrote:
 
 This directory containing styles (css,etc...) is used by both
 website
 (which is still in svn and published via svnpubsub) and project
 documentation (which is in ivy's git repository). As infra was
 proposing git-svn mirror it was a good compromise. Website could
 live
 using svn:externals to fetch appropriate files, and project
 documentation could use git submodules.
 
 Considering we're talking about a few files that doesn't move too
 often i was suggesting duplicating them by hand and/or automating
 it via a script during the release process.
 
 OK, I think I understand.  If this is really only needed for a
 release
 build, having the build process fetch them from svn (which I think
 you
 are suggesting) seems to be a good choice.
 
 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
 
 
 
 -
 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

[VOTE] Ivy 2.4.0 Release - take 2

[Nicolas Lalevée]

I have built a second release candidate for Ivy 2.4.0

The svn tag of this release is: 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=0b9db35ee7a94a719e538b04122b86cb997f3a17

The artifacts has been published to: 
https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7405

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Regards,

Re: [CANCELED][VOTE] Release Ivy 2.4.0

[Nicolas Lalevée]

Note that the style files are also useful to edit the doc within Ivy’s code 
source. So this needs to be easily fetchable for contributors.

Having to maintain the styles folders between the source and the site one 
doesn’t seem that a burden. I prefer to have the burden on committers than on 
contributors.

Nicolas

 Le 10 déc. 2014 à 09:28, Jan Matèrne (jhm) apa...@materne.de a écrit :
 
 Security hint: 'pushing' is not as secure as 'polling' here ... Maybe
 passwords have to be configured...
 
 Jan
 
 -Ursprüngliche Nachricht-
 Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
 Gesendet: Mittwoch, 10. Dezember 2014 07:57
 An: 'Ant Developers List'
 Betreff: AW: [CANCELED][VOTE] Release Ivy 2.4.0
 
 The ideal solutions to all this headaches would probably to have
 everything
 in git (including ivy's website), unfortunatly as far as i know we
 can't publish website via git @ASF for the moment. Infra offers a
 gitpubsub feature but i read somewhere that we can't use it to publish
 websites.
 
 Would a Jenkins job help here?
 It could build the website from git and 'push' (not git push ;) it
 somewhere.
 
 
 Jan
 
 
 
 -Ursprüngliche Nachricht-
 Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
 Gesendet: Mittwoch, 10. Dezember 2014 01:18
 An: Ant Developers List
 Betreff: Re: [CANCELED][VOTE] Release Ivy 2.4.0
 
 Yes !!!
 
 Antoine
 On Dec 9, 2014, at 9:36 AM, Stefan Bodewig bode...@apache.org
 wrote:
 
 On 2014-12-09, Jean-Louis Boudart wrote:
 
 This directory containing styles (css,etc...) is used by both
 website
 (which is still in svn and published via svnpubsub) and project
 documentation (which is in ivy's git repository). As infra was
 proposing git-svn mirror it was a good compromise. Website could
 live
 using svn:externals to fetch appropriate files, and project
 documentation could use git submodules.
 
 Considering we're talking about a few files that doesn't move too
 often i was suggesting duplicating them by hand and/or automating
 it via a script during the release process.
 
 OK, I think I understand.  If this is really only needed for a
 release
 build, having the build process fetch them from svn (which I think
 you
 are suggesting) seems to be a good choice.
 
 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
 
 
 
 -
 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: [CANCELED][VOTE] Release Ivy 2.4.0

[Nicolas Lalevée]

I would still would like some doc.

The doc in the code source is still broken and it make it difficult to know how 
it is rendered.
In the mean time time, you could write a page. I will then ensure myself that 
is proper included in the doc and rendered when the build will be fixed. You 
can take this file as an exemple:
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD
 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD

Nicolas

 Le 2 déc. 2014 à 22:56, JBaruch jbar...@jfrog.com a écrit :
 
 Can we use this opportunity to sneak IVY-1474 in?
 
 Baruch.
 
 --
 JFrog Developer Advocate
 www.jfrog.com
 +972544954353
 @jbaruch https://twitter.com/jbaruch/
 http://linkd.in/jbaruch
 
 On Tue, Dec 2, 2014 at 6:19 PM, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
 It was so obvious that this release candidate should be canceled that I
 forgot to officially set it. Here it is.
 
 I see that the infra ticket is resolved. Jean-Louis spotted some issues
 with it though. But I guess we will retry very soon.
 
 Nicolas
 
 Le 9 nov. 2014 à 17:56, Nicolas Lalevée nicolas.lale...@hibnet.org a
 écrit :
 
 I have built a release candidate for Ivy 2.4.0
 
 The git tag of this release is:
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2
 
 The artifacts has been published to:
 https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093
 
 Do you vote for the release of these binaries?
 
 [ ] Yes
 [ ] No
 
 Regards,
 Nicolas
 
 
 -
 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
 
 

[VOTE] Release Ivy 2.4.0

[Nicolas Lalevée]

I have built a release candidate for Ivy 2.4.0

The git tag of this release is: 
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2

The artifacts has been published to: 
https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Regards,
Nicolas


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

Re: New release process for Ivy

[Nicolas Lalevée]

As you can see via my last commits, I simplified again the release process. The 
release notes are not written anymore in the README, CHANGES and RELEASE_NOTES 
files, but only in the doc/release-notes.html file.

See the current status there:
http://ant.apache.org/ivy/history/trunk/release-notes.html

See also the update release process:
http://ant.apache.org/ivy/history/trunk/dev/makerelease.html

I think I will actually do a release this week-end.

Nicolas

Le 30 oct. 2014 à 00:51, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 So I have updated the release process to use git. I also made some 
 simplification. There used to be a release branch. I don’t think we need it 
 anymore, so I have wrote a process without it.
 
 I have pushed the doc online:
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
 
 Probably some commands won’t work exactly as expected, I’ll fix them along 
 the real release. But at least I think I have covered the idea of how we 
 should release now.
 
 Comments are welcomed.
 
 Then I’ll proceed to make a real release.
 
 Nicolas
 
 
 -
 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: Updating Ivy's trunk doc in the site

[Nicolas Lalevée]

I think I have come to something workable. It could be smarter to avoid any 
checkout, but at least it works.

svn:external have disappeared, they are now replaced with manual git checkout. 
I have made an ant target to handle it properly.

For instance, the trunk version (trunk as the name used in the path of the url) 
correspond to the master branch. Here are the command to checkout, then to 
generate:
ant checkout-history -Dhistory.version=master -Dtarget.history.folder=trunk
ant generate-history -Dhistory.version=trunk

If the name of the tag is the same as the version in the url, then no need to 
specify an ‘history folder’:
ant checkout-history -Dhistory.version=2.4.0
ant generate-history -Dhistory.version=2.4.0

Hope it makes sense.

Nicolas

Le 28 oct. 2014 à 03:01, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hi,
 
 as far as I know there is no gitpubsub for the web sites so far. At least 
 that was the case when we migrated to git.
 
 I had a look at the gitpubsub link that you mention Nicolas, I think this 
 functionality is only available to setup some automation around git commits, 
 for instance for event driven continuous integration servers.
 
 Regards,
 
 Antoine
 On Oct 27, 2014, at 7:10 PM, Nicolas Lalevée nicolas.lale...@hibnet.org 
 wrote:
 
 Le 26 oct. 2014 à 20:16, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
 écrit :
 
 Would it be possible to have everything on git ?
 Looks like there is a gitpubsub feature available[1]
 
 I don’t know either what is possible, I am not familiar with gitpubsub and 
 submodule. That’s why I am asking here.
 
 Another option could be to use svn client for github (but this relies on
 github infra not ASF one :/) [2].
 
 A manual solution could be to have website + released documentation on
 svn. Git could still contains the trunk/master documentation (we only
 publish it on the website when releasing).
 During a release we could zip/export documentation and put it on svn.
 Ideally all this could be probably done by an ant target.
 
 We can ask infra to have svn read only mirror on our git repo but this
 would make release process i think more complicated.
 
 The solution of replacing the svn:external by the copy of the files from git 
 is indeed a quite manual process. I’ll do that if nothing better is 
 suggested.
 
 Nicolas
 
 
 WDYT ?
 
 
 [1] http://www.apache.org/dev/gitpubsub.html
 [2] https://help.github.com/articles/support-for-subversion-clients/
 
 
 
 2014-10-26 19:49 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 Now that the Ivy’s code source is in git, but the site is still managed in
 svn, how do we update the doc of Ivy trunk in the site ?
 How can I update this : http://ant.apache.org/ivy/history/trunk/index.html
 
 We’ll have a similar issue when we will release, we will need to publish
 the released doc.
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
 -
 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

New release process for Ivy

[Nicolas Lalevée]

So I have updated the release process to use git. I also made some 
simplification. There used to be a release branch. I don’t think we need it 
anymore, so I have wrote a process without it.

I have pushed the doc online:
http://ant.apache.org/ivy/history/trunk/dev/makerelease.html

Probably some commands won’t work exactly as expected, I’ll fix them along the 
real release. But at least I think I have covered the idea of how we should 
release now.

Comments are welcomed.

Then I’ll proceed to make a real release.

Nicolas


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

git merge is generating a lot of mails

[Nicolas Lalevée]

As you can see on the notifications list, there is a nice bunch of mails, all 
generated from my one commit which merged the master of Ivy into the branch 
2.4. I have hard time understand the rationale. Anyone more familiar with git 
than me have some explanation ?

Note that I am not worried, I just like to understand what is going on.

Nicolas


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

Re: git merge is generating a lot of mails

[Nicolas Lalevée]

I just did a plain git merge, since I actually wanted both branches to join.

Nicolas

Le 28 oct. 2014 à 23:30, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 Can you tell us the command you use ?
 
 Did you used squash option? Did you rebase ?
 
 2014-10-28 22:55 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 As you can see on the notifications list, there is a nice bunch of mails,
 all generated from my one commit which merged the master of Ivy into the
 branch 2.4. I have hard time understand the rationale. Anyone more familiar
 with git than me have some explanation ?
 
 Note that I am not worried, I just like to understand what is going on.
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

Re: Commit Candidates for Ivy 2.4.x

[Nicolas Lalevée]

Le 26 oct. 2014 à 20:19, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 
 Le 26 oct. 2014 à 19:58, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
 écrit :
 
 Hi Nicolas,
 
 My answers bellow.
 
 2014-10-26 19:18 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 I have checked the branch 2.4.x. I have put back in the branch every thing
 that was obvious enough.
 
 There are some that may need to be merged back too, I would need some
 feedback about them.
 
 - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
 branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
 
 This commit looks like easy to merge manually, by the way what do you mean
 by doesn't apply cleanly » ?
 
 I did a cherry-pick and there were some conflict to resolve. I have to admit 
 that I didn’t looked at what the conflict was. 

So I had a closer look to it. Something is actually going wrong, git is right 
about the patch not applying cleanly, some code is missing.

As far as I could look around, 3076802a [1] needs 8d851390 (r1592624) [2]. It 
was supposed to be merged by 57892b6e [3] but it doesn’t look as fully merged. 
For instance, PomModuleDescriptorBuilder is modified by 8d851390 but not by 
57892b6e.

So I don’t trust much the state the 2.4.x branch. Maybe should we better make 
the next 2.4 from trunk ?

Nicolas

[1] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=3076802a
[2] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=8d851390
[3] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=57892b6e


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

Re: Updating Ivy's trunk doc in the site

[Nicolas Lalevée]

Le 26 oct. 2014 à 20:16, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 Would it be possible to have everything on git ?
 Looks like there is a gitpubsub feature available[1]

I don’t know either what is possible, I am not familiar with gitpubsub and 
submodule. That’s why I am asking here.

 Another option could be to use svn client for github (but this relies on
 github infra not ASF one :/) [2].
 
 A manual solution could be to have website + released documentation on
 svn. Git could still contains the trunk/master documentation (we only
 publish it on the website when releasing).
 During a release we could zip/export documentation and put it on svn.
 Ideally all this could be probably done by an ant target.
 
 We can ask infra to have svn read only mirror on our git repo but this
 would make release process i think more complicated.

The solution of replacing the svn:external by the copy of the files from git is 
indeed a quite manual process. I’ll do that if nothing better is suggested.

Nicolas

 
 WDYT ?
 
 
 [1] http://www.apache.org/dev/gitpubsub.html
 [2] https://help.github.com/articles/support-for-subversion-clients/
 
 
 
 2014-10-26 19:49 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 Now that the Ivy’s code source is in git, but the site is still managed in
 svn, how do we update the doc of Ivy trunk in the site ?
 How can I update this : http://ant.apache.org/ivy/history/trunk/index.html
 
 We’ll have a similar issue when we will release, we will need to publish
 the released doc.
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

Re: Commit Candidates for Ivy 2.4.x

[Nicolas Lalevée]

I applied the fix for IVY-1452, and to be safer than sorry I also applied the 
one for IVY-1493.

For IVY-1474, as I commented there, I would prefer to have some documentation 
about it.

Nicolas

Le 27 oct. 2014 à 17:44, Josh Suereth joshua.suer...@gmail.com a écrit :

 Ivy-1452 has my vote.  We had to backport that to ivy 2.3 for sbt
 On Oct 26, 2014 3:30 PM, Jean-Louis Boudart jeanlouis.boud...@gmail.com
 wrote:
 
 2014-10-26 20:19 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 
 
 - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
 branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
 
 This commit looks like easy to merge manually, by the way what do you
 mean
 by doesn't apply cleanly » ?
 
 I did a cherry-pick and there were some conflict to resolve. I have to
 admit that I didn’t looked at what the conflict was.
 
 So IVY-1465 is finished ? Should we mark it as fixed in 2.4 ?
 
 
 Yes
 
 
 
 - and there are two commits which don’t seem to be related to any bug:
 ‘5063d256’ [5] and ‘a6b9ca3f’ [6].
 
 They are not related to any bug, both are small improvement on API
 introduced in 2.4-rc1. Not sure it make sense to have a bug for those
 one
 but i can create one if you want.
 
 Agreed, no need to create issues for that. My point is that since they
 are
 not associated with any bug, I guess they should not be merged ? But if
 these improvements are related to the API introduced in 2.4, then I guess
 they should ?
 
 They should be merged.
 
 
 What about including the two following ones ? :
 
   - IVY-1452 NullPointerException when accessing charset to invalid URL
   [1]
   - IVY-1474 Bintray resolver [2]
 
 IVY-1452 is anoying issue that could easily be fixed, i tried the attached
 patch and it fixes the issue.
 IVY-1474 is new resolver for Bintray repository.
 
 [1] https://issues.apache.org/jira/browse/IVY-1452
 [2] https://issues.apache.org/jira/browse/IVY-1474
 


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

Commit Candidates for Ivy 2.4.x

[Nicolas Lalevée]

I have checked the branch 2.4.x. I have put back in the branch every thing that 
was obvious enough.

There are some that may need to be merged back too, I would need some feedback 
about them.

- IVY-1465 [1] doesn’t seem to be fully finished. One part is in the branch, 
the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
- use https for maven repos [3]; should we merge it ?
- and there is IVY-1491 [4]; should we merge it ?
- and there are two commits which don’t seem to be related to any bug: 
‘5063d256’ [5] and ‘a6b9ca3f’ [6].

Nicolas

[1] https://issues.apache.org/jira/browse/IVY-1465
[2] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=3076802a
[3] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=750dbb84
[4] https://issues.apache.org/jira/browse/IVY-1491
[5] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=5063d256
[6] https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=a6b9ca3f


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

Updating Ivy's trunk doc in the site

[Nicolas Lalevée]

Now that the Ivy’s code source is in git, but the site is still managed in svn, 
how do we update the doc of Ivy trunk in the site ?
How can I update this : http://ant.apache.org/ivy/history/trunk/index.html

We’ll have a similar issue when we will release, we will need to publish the 
released doc.

Nicolas


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

Re: Commit Candidates for Ivy 2.4.x

[Nicolas Lalevée]

Le 26 oct. 2014 à 19:58, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 Hi Nicolas,
 
 My answers bellow.
 
 2014-10-26 19:18 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 I have checked the branch 2.4.x. I have put back in the branch every thing
 that was obvious enough.
 
 There are some that may need to be merged back too, I would need some
 feedback about them.
 
 - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
 branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
 
 This commit looks like easy to merge manually, by the way what do you mean
 by doesn't apply cleanly » ?

I did a cherry-pick and there were some conflict to resolve. I have to admit 
that I didn’t looked at what the conflict was. 

So IVY-1465 is finished ? Should we mark it as fixed in 2.4 ?

 - use https for maven repos [3]; should we merge it ?
 - and there is IVY-1491 [4]; should we merge it ?
 
 I would say yes for both

ok

 - and there are two commits which don’t seem to be related to any bug:
 ‘5063d256’ [5] and ‘a6b9ca3f’ [6].
 
 They are not related to any bug, both are small improvement on API
 introduced in 2.4-rc1. Not sure it make sense to have a bug for those one
 but i can create one if you want.

Agreed, no need to create issues for that. My point is that since they are not 
associated with any bug, I guess they should not be merged ? But if these 
improvements are related to the API introduced in 2.4, then I guess they should 
?

Nicolas


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

Re: Release of Ivy 2.4.0

[Nicolas Lalevée]

Le 17 oct. 2014 à 08:27, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 Hi,
 
 What can i do to assist you on this first release with git ?

If you have more time than me, you can do the release :)

We need to get necessary stuff merged back in the 2.4 branch.
We need a review of the doc and the site and replace mentions of svn by git 
(some people wrote they were still confused by that, we missed some on the site 
apparently).
We need to update the doc about how to release; which would be probably done 
along the releasing.

Nicolas

 2014-10-16 22:00 GMT+02:00 Josh Suereth joshua.suer...@gmail.com:
 
 If It helps, we had to move back to 2.3 because parent-pom-properties don't
 resolve correctly in 2.4.0-rc1 which broke a lot of our users.
 On Oct 15, 2014 6:28 PM, Maarten Coene maarten_co...@yahoo.com.invalid
 wrote:
 
 If I remember correctly, the 2.4.0-RC1 also introduced some other very
 annoying bugs, these fixes should be included in the 2.4.0 release as
 well
 imho.
 
 I whish I could help you with it Nicolas, but I also have too little time
 which will be needed for the first release on git.
 (In fact, my very very low activity is also caused by the fact that we
 are
 on git now in combination with the lack of time to learn how to use it
 properly)
 
 
 Maarten
 
 
 
 
 Van: Nicolas Lalevée nicolas.lale...@hibnet.org
 Aan: Ant Developers List dev@ant.apache.org
 Verzonden: woensdag 15 oktober 18:31 2014
 Onderwerp: Release of Ivy 2.4.0
 
 
 The last release of Eclipse has introduced a nasty bug [2], IvyDE is
 impacted, and the fix/work-around is in Ivy [2]. I think we should get a
 fix out very soon.
 
 And Ivy has been in RC for quite some time, I suggest we release it with
 also that fix, as the 2.4.0.
 
 This would be the first release done from git, my free time is quite
 limited, so don’t freak if I take some time to get out a release to be
 voted upon.
 
 Nicolas
 
 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122
 [2] https://issues.apache.org/jira/browse/IVY-1487
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

Release of Ivy 2.4.0

[Nicolas Lalevée]

The last release of Eclipse has introduced a nasty bug [2], IvyDE is impacted, 
and the fix/work-around is in Ivy [2]. I think we should get a fix out very 
soon.

And Ivy has been in RC for quite some time, I suggest we release it with also 
that fix, as the 2.4.0.

This would be the first release done from git, my free time is quite limited, 
so don’t freak if I take some time to get out a release to be voted upon.

Nicolas

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122
[2] https://issues.apache.org/jira/browse/IVY-1487


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

Re: IvyDE-updatesite - fix for jenkins

[Nicolas Lalevée]

Le 27 juin 2014 à 22:29, Jan Matèrne j...@materne.de a écrit :

 https://builds.apache.org/job/IvyDE-updatesite/ is broken and I think its
 because it tries to download the ivy.jar from the wrong location.
 Because I dont have write access to that svn repo, I created a patch.
 Please try ;)

I tried to applied the patch you provided, but I couldn't either commit in the 
svn. That's when I asked if this part of svn was wrongly put read only during 
the migration to git.

Nicolas


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

Re: [jira] [Commented] (INFRA-7816) Create readonly git mirror for Xooki

[Nicolas Lalevée]

Le 10 juin 2014 à 21:29, Jan Matèrne (jhm) apa...@materne.de a écrit :

 I wouldnt count myself to the Ivy team, but I prefer changing to 
 trunk/branches structure:
 * conform to other svn repos
 * easier setup for infra for the read only git repo

+1

Nicolas


 
 Jan
 
 -Ursprüngliche Nachricht-
 Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com]
 Gesendet: Dienstag, 10. Juni 2014 20:59
 An: Ant Developers List
 Betreff: Fwd: [jira] [Commented] (INFRA-7816) Create readonly git
 mirror for Xooki
 
 Some updates about creation of xooki git mirror.
 
 @Ivy team any opinions ?
 
 -- Forwarded message --
 From: #asfinfra IRC Bot (JIRA) j...@apache.org
 Date: 2014-06-10 20:51 GMT+02:00
 Subject: [jira] [Commented] (INFRA-7816) Create readonly git mirror for
 Xooki
 To: jeanlouis.boud...@gmail.com
 
 
 
[
 https://issues.apache.org/jira/browse/INFRA-
 7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=14026838#comment-14026838
 ]
 
 #asfinfra IRC Bot commented on INFRA-7816:
 --
 
 Humbedooh The import script is fine, but we cannot import Xooki as it
 is currently laid out due to lack of a trunk/branches structure, so
 this will either take a while longer or you will have to change the svn
 to reflect this structure
 
 
 Create readonly git mirror for Xooki
 -
 
Key: INFRA-7816
URL: https://issues.apache.org/jira/browse/INFRA-7816
Project: Infrastructure
 Issue Type: Task
 Components: Git
   Reporter: Jean-Louis Boudart
 
 Could you please create a readonly git mirror of xooki (
 https://svn.apache.org/repos/asf/ant/site/xooki/) ?
 Xooki is a documentation tool used by :
 * Ivy
 * IvyDE
 * EasyAnt
 Those projects were migrated to git recently as part of ant family
 migration to git (INFRA-7759).
 We use xooki for both project documentation and official website.
 Xooki should remains in svn to make website generation, but we need a
 readonly git mirror that will be used as git submodule for project
 documentation.
 Thanks in advance.
 
 
 
 --
 This message was sent by Atlassian JIRA
 (v6.2#6252)
 
 
 
 --
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
 -
 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 compiler error @ Jenkins

[Nicolas Lalevée]

Le 5 juin 2014 à 07:12, Jan Matèrne (jhm) apa...@materne.de a écrit :

 https://builds.apache.org/view/A-D/view/Ant/job/IvyDE/lastBuild/consoleFull
 
 [java] [javac] 650. ERROR in
 /home/jenkins/jenkins-slave/workspace/IvyDE/work/eclipse/plugins/org.apache.
 ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/workspaceresolver/W
 orkspaceResolver.java (at line 222)
 
 [java] [javac]String sn =
 md.getExtraInfoContentByTagName(Bundle-SymbolicName);
 
 [java] [javac]   
 
 [java] [javac] The method getExtraInfoContentByTagName(String) is
 undefined for the type ModuleDescriptor
 
 [java] [javac] --
 
 [java] [javac] 651. ERROR in
 /home/jenkins/jenkins-slave/workspace/IvyDE/work/eclipse/plugins/org.apache.
 ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/workspaceresolver/W
 orkspaceResolver.java (at line 229)
 
 [java] [javac]String exportedPackages =
 md.getExtraInfoContentByTagName(Export-Package);
 
 [java] [javac]
 
 
 [java] [javac] The method getExtraInfoContentByTagName(String) is
 undefined for the type ModuleDescriptor
 
 
 
 This is then only/the first reason why the build fails.
 
 Unknown country for me, so I delegate to IvyDE-experts here ;-)

IvyDE trunk is requiring an API from Ivy trunk. For now the build was only 
relying on released versions of Ivy. My current laziness and lack of time make 
me choose the solution of waiting for an Ivy release rather than having the 
build be able to get a trunk version of Ivy.

 Also there are a lot of Raw-type warnings. Some of them refer to
 Java1.4-style type arguments:
 
 [java] [javac] 18. WARNING in
 /home/jenkins/jenkins-slave/workspace/IvyDE/work/eclipse/plugins/org.apache.
 ivyde.eclipse/src/java/org/apache/ivyde/common/ivyfile/IvyFileResourceListen
 er.java (at line 70)
 [java] [javac]List/* IvyClasspathContainer */containers =
 IvyClasspathContainerHelper
 [java] [javac]
 [java] [javac] List is a raw type. References to generic type
 ListE should be parameterized

There is a lot of warnings, in Ivy too, and probably in Ant too, since we 
recently switch to Java 5. This will be a continuous work to properly set 
parameterized types.

Thanks for taking time looking into it.

Nicolas


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

Re: Repository access

[Nicolas Lalevée]

I couldn't commit the patch you suggested for the ivyde updatesite in svn 
either. It must be read only.

Nicolas

Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) apa...@materne.de a écrit :

 After ivyde-updatesite (svn) this is the 2nd repo where I can't commit/push
 
 https://git-wip-us.apache.org/repos/asf/easyant-core.git
 
 
 
 Is there any reason? 
 
 
 
 
 
 Jan
 


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

Re: migration to git : next steps - Jenkins

[Nicolas Lalevée]

About IvyDE's updatesite project, it is really just a build script. We never 
release it. It is a just a helper to produce the binaries associated with an 
Ivy or IvyDE release so they can be downloaded directly into Eclipse.

And it relies on some svn:externals of Apache's dist, so it should be kept in 
svn.

Nicolas

Le 28 mai 2014 à 09:06, Jan Matèrne (jhm) apa...@materne.de a écrit :

 Here is an intermediate result and my opinion on that:
 
 All jobs are successful running or waiting for a blocking INFRA-issue.
 What about the IvyDE-updatesite?
 
 Also I updated the view (add missing ivy-tests)
 https://builds.apache.org/view/A-D/view/Ant/
 
 I deactivated the windows builds until INFRA-7823 is resolved.
 How to deal with the xooki-not-found projects (EasyAnt, IvyDE)? 
 a) leave it red
 b) change the build launch command on jenkins (to which new value?)
 c) change the buildfile so xooki is not required (not by me ;)  
 d) b+c
 
 Because I don't know what to do now (expect waiting for infra) I'll take my
 fingers from the keyboard.
 
 Found another job: Ant-test-windows
 - tied to windows1
 - jdk1.5 
 - no regular trigger 
 - updated to use git instead of svn
 - build command: 'ant' (default target)
 -- deactivated because windows1 is offline
 I want to remove that job, because JDK1.5 is part of the matrix-job. Any
 objections?  
 
 
 
 cheers
 Jan
 
 
 Open problems
 =
 I dont know wheter IvyDE-updatesite is migrated to git, too.
 -- Question to the IvyDE experts here ;)
 
 Ant-Build-Matrix has problems on Ubuntu and on Windows. 
 On Windows it seems (to me) that there is no git installed or not on the
 PATH.
 -- blocked by new INFRA-7823
 -- windows builds deactivate via groovy-selector
 
 EasyAnt doesnt find the xooki antlib.
 -- blocked by INFRA-7816
 
 IvyDE is failing because of not finding xooki antlib.
 Because that antlib.xml is searched in the local project directory, maybe
 this was an svn:external?
 -- blocked by INFRA-7816
 
 Ivy-tests has the no-git-problem on windows.
 -- blocked by new INFRA-7823
 -- windows builds deactivate via groovy-selector
 
 
 
 
 
 Current status:
 
 - Ant-Build-Matrix
  repo: git
  https://builds.apache.org/job/Ant_BuildFromPOMs/
  status: errors on the slaves
 
  Builds on Windows
  -- blocked by new INFRA-7823
 
JDK-1.5, windows2
 
 https://builds.apache.org/job/Ant-Build-Matrix/jdk=JDK%201.5%20%28latest%29,
 label=Windows/lastBuild/console
  no-git-error, like jdk1.7@windows
 
JDK-1.6, windows2
 
 https://builds.apache.org/job/Ant-Build-Matrix/jdk=JDK%201.6%20%28latest%29,
 label=Windows/lastBuild/console
  no-git-error, like jdk1.7@windows
 
JDK-1.7, windows2
 
 https://builds.apache.org/job/Ant-Build-Matrix/jdk=JDK%201.7%20%28latest%29,
 label=Windows/lastBuild/console
  ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init
 f:\jenkins\jenkins-slave\workspace\Ant-Build-Matrix@2\jdk\JDK 1.7
 (latest)\label\Windows
  Caused by: hudson.plugins.git.GitException: Error performing command:
 git init f:\jenkins\jenkins-slave\workspace\Ant-Build-Matrix@2\jdk\JDK 1.7
 (latest)\label\Windows
  Caused by: java.io.IOException: Cannot run program git (in directory
 f:\jenkins\jenkins-slave\workspace\Ant-Build-Matrix@2\jdk\JDK 1.7
 (latest)\label\Windows): CreateProcess error=2, The system cannot find the
 file specified
  -- no git installed on that slave?
 
JDK-1.8, windows2
 
 https://builds.apache.org/job/Ant-Build-Matrix/jdk=jdk-1.8.0,label=Windows/l
 astBuild/console
  [jdk-1.8.0] $
 f:\jenkins\jenkins-slave\tools\hudson.model.JDK\jdk-1.8.0\jdk.exe 
/s ADDLOCAL=ToolsFeature REBOOT=ReallySuppress
 INSTALLDIR=f:\jenkins\jenkins-slave\tools\hudson.model.JDK\jdk-1.8.0 
'/L
 \f:\jenkins\jenkins-slave\tools\hudson.model.JDK\jdk-1.8.0\jdk.exe.install.
 log\'
  Failed to install JDK. Exit code=-80
  ERROR: null
 
  Builds on Ubuntu
  -- now success
 
 - EasyAnt
  repo: git
  https://builds.apache.org/view/A-D/view/Ant/job/EasyAnt/
  status: errors
  -- blocked by new INFRA-7816
 
 - IvyDE
  https://builds.apache.org/job/IvyDE/
  repo: git
  status: 
  -- blocked by new INFRA-7816
 
 - Ivy-tests
  https://builds.apache.org/job/Ivy-tests/configure
  repo: git
  status:
  -- blocked by new INFRA-7823
 
 
 
 ==  
 == DONE ==
 ==  
 
 - IvyDE-updatesite
  https://builds.apache.org/job/IvyDE-updatesite/
  repo: still svn
  status: not triggered because not changed
 
 - Ivy
  https://builds.apache.org/job/Ivy/
  repo: git
  status: sucess
 
 - Ivy-check
  https://builds.apache.org/job/Ivy-check/
  repo: git
  status: success
 
 - Ant_Nightly
  repo: git
  https://builds.apache.org/job/Ant_Nightly/
  status: success (unstable)
 
 - Ant_BuildFromPOMs
  repo: git
  https://builds.apache.org/job/Ant_BuildFromPOMs/
  status: run fine (using locks-and-latches, no archiving)
 
 
 
 

Re: Ivy's ModuleDescriptor.getExtraInfo() is now deprecated

[Nicolas Lalevée]

Forget about that duplicate mail, this is me being tricked by the ASF email 
lag. It seems to still continue to lag a lot.

Nicolas

Le 8 mai 2014 à 17:07, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 Hi,
 
 ModuleDescriptor.getExtraInfo() is deprecated but there is no indication in 
 the doc about what should be used then. There is getExtraInfos(), but as I 
 look to the code, there is no data transfer between both, if if there is data 
 in one, I cannot get the data from the other one. And since the 
 XmlModuleDescriptorWriter is only handling ExtraInfoHolder, some data are 
 lost.
 
 For this new need method getExtraInfos() to work properly, I guess it have to 
 handle all the calls to the deprecated getExtraInfo(). Am I missing something 
 ?
 
 Nicolas
 
 
 -
 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's ModuleDescriptor.getExtraInfo() is now deprecated

[Nicolas Lalevée]

Hi,

ModuleDescriptor.getExtraInfo() is deprecated but there is no indication in the 
doc about what should be used then. There is getExtraInfos(), but as I look to 
the code, there is no data transfer between both, if if there is data in one, I 
cannot get the data from the other one. And since the XmlModuleDescriptorWriter 
is only handling ExtraInfoHolder, some data are lost.

For this new need method getExtraInfos() to work properly, I guess it have to 
handle all the calls to the deprecated getExtraInfo(). Am I missing something ?

Nicolas


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

Re: Classloading issue

[Nicolas Lalevée]

r1594279 seems to fix the issue, but I still don't understand why.
Any suggestion of a better fix is welcomed.

Nicolas

Le 11 mai 2014 à 23:41, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 Hi,
 
 I need some help to understand a bug around classloading (nothing that 
 particular to Ivy).
 
 I was looking into IVY-1471 [1] and I don't understand why it is failing that 
 way. In the classpath there are both Ivy and Jsch, but not the optional jar 
 related to managing the ssh agent via jsch. And it is failing because a class 
 in that optional jar is not found. But I don't understand why the classloader 
 is looking for it in the first place.
 
 The error is raised is AbstractSshBasedRepository, on the call of 
 SshCache.getInstance() [2]. But as far as I can tell, nothing in the loading 
 of the SshCache [3] class requires AgentProxyException. The class is only 
 needed by the function SshCache#attemptAgentUse() [4], which will be called 
 at runtime, if the end user actually want ssh agent support, in which case it 
 would naturally fail. But here it fails very earlier.
 
 I have made a test case you can test with its build.xml, no IvyDE required 
 there [5].
 
 Am I missing something ? Is there a special treatment for the loading of 
 Exception classes ?
 
 Nicolas
 
 [1] https://issues.apache.org/jira/browse/IVY-1471
 [2] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108
 [3] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true
 [4] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300
 [5] http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/
 
 
 -
 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: Classloading issue

[Nicolas Lalevée]

Le 12 mai 2014 à 02:51, Martin Gainty mgai...@hotmail.com a écrit :

 Subject: Re: Classloading issue
 From: nicolas.lale...@hibnet.org
 Date: Mon, 12 May 2014 01:51:12 +0200
 To: dev@ant.apache.org
 
 
 Le 12 mai 2014 à 01:34, Antoine Levy Lambert anto...@gmx.de a écrit :
 
 Hello Nicolas,
 
 I have tried your test case and it is failing as you except :
 
 BUILD FAILED
 /Users/antoine/dev/asf/ivyde-trunk/test/ssh-resolver/build.xml:27: 
 java.lang.NoClassDefFoundError: 
 com/jcraft/jsch/agentproxy/AgentProxyException
 
 MGHi Nicholas
 MGlocal classloader cannot resolve jdsch-agentproxy.core-0.0.7.jar?
 MGwhat happens when you place
 MGhttp://www.grepcode.com/snapshot/repo1.maven.org/maven2/com.jcraft/jsch.agentproxy.core/0.0.7/jsch.agentproxy.core-0.0.7.jar
 MGon SYSTEM classpath?

jsch-agentproxy isn't on the classpath on purpose. If we don't need the ssh 
agent feature, we shouldn't need this jar.

Nicolas

 
 at 
 org.apache.ivy.plugins.repository.ssh.AbstractSshBasedRepository.getSession(AbstractSshBasedRepository.java:108)
 at 
 org.apache.ivy.plugins.repository.ssh.SshRepository.resolveResource(SshRepository.java:82)
 at 
 org.apache.ivy.plugins.repository.ssh.SshResource.resolve(SshResource.java:101)
 
 The line 108 in AbstractSsshBasedRepository contains this :
 
  return SshCache.getInstance().getSession(host, port, user, 
 userPassword, getKeyFile(),
  getKeyFilePassword(), getPassFile(), isAllowedAgentUse());
 
 getSession is a method which calls attemptAgentUse.
 
 It is only called is attemptAgentUse is true. In our case it is false.
 
 Does this explain why an attempt to load AgentProxyException happens at 
 that time ?
 
 I have plugged a debugger, and the class loading exception is raised on the 
 call of SshCache.getInstance(). As far as I can tell, it is the class 
 SshCache which fails to load, but I don't understand why.
 
 Nicolas
 
 
 Regards,
 
 Antoine
 
 On May 11, 2014, at 5:41 PM, Nicolas Lalevée nicolas.lale...@hibnet.org 
 wrote:
 
 Hi,
 
 I need some help to understand a bug around classloading (nothing that 
 particular to Ivy).
 
 I was looking into IVY-1471 [1] and I don't understand why it is failing 
 that way. In the classpath there are both Ivy and Jsch, but not the 
 optional jar related to managing the ssh agent via jsch. And it is failing 
 because a class in that optional jar is not found. But I don't understand 
 why the classloader is looking for it in the first place.
 
 The error is raised is AbstractSshBasedRepository, on the call of 
 SshCache.getInstance() [2]. But as far as I can tell, nothing in the 
 loading of the SshCache [3] class requires AgentProxyException. The class 
 is only needed by the function SshCache#attemptAgentUse() [4], which will 
 be called at runtime, if the end user actually want ssh agent support, in 
 which case it would naturally fail. But here it fails very earlier.
 
 I have made a test case you can test with its build.xml, no IvyDE required 
 there [5].
 
 Am I missing something ? Is there a special treatment for the loading of 
 Exception classes ?
 
 Nicolas
 
 [1] https://issues.apache.org/jira/browse/IVY-1471
 [2] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108
 [3] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true
 [4] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300
 [5] http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/
 
 
 -
 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 AntUnit 1.3 based on RC1

[Nicolas Lalevée]

+1 for me

Nicolas

Le 11 mai 2014 à 12:42, Stefan Bodewig bode...@apache.org a écrit :

 Hi all,
 
 delayed because I wanted to wait for mails to arrive again.
 
  Antunit 1.3 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/
(svn revision 5298)
 
  Maven artifacts are here:

 https://repository.apache.org/content/repositories/orgapacheant-1005/org/apache/ant/ant-antunit/1.3/
 
  Details of changes since 1.2 are in the release notes:

 https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/RELEASE-NOTES-1.3.html
 
  The tag is here:
http://svn.apache.org/repos/asf/ant/antlibs/antunit/tags/1.3RC1/
(svn revision 1593382)
 
  KEYS:
  http://www.apache.org/dist/ant/KEYS
 
  Please review the release candidate and vote.
  This vote will close no sooner that 72 hours from now, i.e. after 1100
  GMT 14-May 2014.  Should we get hit by a mail-outage again I'll defer
  counting the votes as well.
 
  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...
 
  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

Ivy's ModuleDescriptor.getExtraInfo() is now deprecated

[Nicolas Lalevée]

Hi,

ModuleDescriptor.getExtraInfo() is deprecated but there is no indication in the 
doc about what should be used then. There is getExtraInfos(), but as I look to 
the code, there is no data transfer between both, if if there is data in one, I 
cannot get the data from the other one. And since the XmlModuleDescriptorWriter 
is only handling ExtraInfoHolder, some data are lost.

For this new need method getExtraInfos() to work properly, I guess it have to 
handle all the calls to the deprecated getExtraInfo(). Am I missing something ?

Nicolas


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

Classloading issue

[Nicolas Lalevée]

Hi,

I need some help to understand a bug around classloading (nothing that 
particular to Ivy).

I was looking into IVY-1471 [1] and I don't understand why it is failing that 
way. In the classpath there are both Ivy and Jsch, but not the optional jar 
related to managing the ssh agent via jsch. And it is failing because a class 
in that optional jar is not found. But I don't understand why the classloader 
is looking for it in the first place.

The error is raised is AbstractSshBasedRepository, on the call of 
SshCache.getInstance() [2]. But as far as I can tell, nothing in the loading of 
the SshCache [3] class requires AgentProxyException. The class is only needed 
by the function SshCache#attemptAgentUse() [4], which will be called at 
runtime, if the end user actually want ssh agent support, in which case it 
would naturally fail. But here it fails very earlier.

I have made a test case you can test with its build.xml, no IvyDE required 
there [5].

Am I missing something ? Is there a special treatment for the loading of 
Exception classes ?

Nicolas

[1] https://issues.apache.org/jira/browse/IVY-1471
[2] 
https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108
[3] 
https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true
[4] 
https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300
[5] http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/


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

Re: Ivy's ModuleDescriptor.getExtraInfo() is now deprecated

[Nicolas Lalevée]

Le 11 mai 2014 à 19:12, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 Hi Nicolas,
 
 This was introduced by IVY-1457 and breaks backward compatibility as
 mentioned there. All call to old api from ivy-core itslef has been migrated
 on trunk. I didn't find any elegant way to make it backward compatible.
 Suggestion are welcome.
 
 But yeah basically you get the idea :/

As far as I understand getExtraInfo was kind of broken. I think I have managed 
to make getExtraInfo and getExtraInfos work together, explicating in the doc 
that the former will barely work, but at least work a little bit. See my commit 
r1593855. As far as I can tell, tests pass well.

Nicolas

 
 
 2014-05-11 17:07 GMT+02:00 Nicolas Lalevée nicolas.lale...@hibnet.org:
 
 Hi,
 
 ModuleDescriptor.getExtraInfo() is deprecated but there is no indication
 in the doc about what should be used then. There is getExtraInfos(), but as
 I look to the code, there is no data transfer between both, if if there is
 data in one, I cannot get the data from the other one. And since the
 XmlModuleDescriptorWriter is only handling ExtraInfoHolder, some data are
 lost.
 
 For this new need method getExtraInfos() to work properly, I guess it have
 to handle all the calls to the deprecated getExtraInfo(). Am I missing
 something ?
 
 Nicolas
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

Re: Classloading issue

[Nicolas Lalevée]

Le 12 mai 2014 à 01:34, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hello Nicolas,
 
 I have tried your test case and it is failing as you except :
 
 BUILD FAILED
 /Users/antoine/dev/asf/ivyde-trunk/test/ssh-resolver/build.xml:27: 
 java.lang.NoClassDefFoundError: com/jcraft/jsch/agentproxy/AgentProxyException
   at 
 org.apache.ivy.plugins.repository.ssh.AbstractSshBasedRepository.getSession(AbstractSshBasedRepository.java:108)
   at 
 org.apache.ivy.plugins.repository.ssh.SshRepository.resolveResource(SshRepository.java:82)
   at 
 org.apache.ivy.plugins.repository.ssh.SshResource.resolve(SshResource.java:101)
 
 The line 108 in AbstractSsshBasedRepository contains this :
 
   return SshCache.getInstance().getSession(host, port, user, 
 userPassword, getKeyFile(),
   getKeyFilePassword(), getPassFile(), isAllowedAgentUse());
 
 getSession is a method which calls attemptAgentUse.

It is only called is attemptAgentUse is true. In our case it is false.

 Does this explain why an attempt to load AgentProxyException happens at that 
 time ?

I have plugged a debugger, and the class loading exception is raised on the 
call of SshCache.getInstance(). As far as I can tell, it is the class SshCache 
which fails to load, but I don't understand why.

Nicolas

 
 Regards,
 
 Antoine
 
 On May 11, 2014, at 5:41 PM, Nicolas Lalevée nicolas.lale...@hibnet.org 
 wrote:
 
 Hi,
 
 I need some help to understand a bug around classloading (nothing that 
 particular to Ivy).
 
 I was looking into IVY-1471 [1] and I don't understand why it is failing 
 that way. In the classpath there are both Ivy and Jsch, but not the optional 
 jar related to managing the ssh agent via jsch. And it is failing because a 
 class in that optional jar is not found. But I don't understand why the 
 classloader is looking for it in the first place.
 
 The error is raised is AbstractSshBasedRepository, on the call of 
 SshCache.getInstance() [2]. But as far as I can tell, nothing in the loading 
 of the SshCache [3] class requires AgentProxyException. The class is only 
 needed by the function SshCache#attemptAgentUse() [4], which will be called 
 at runtime, if the end user actually want ssh agent support, in which case 
 it would naturally fail. But here it fails very earlier.
 
 I have made a test case you can test with its build.xml, no IvyDE required 
 there [5].
 
 Am I missing something ? Is there a special treatment for the loading of 
 Exception classes ?
 
 Nicolas
 
 [1] https://issues.apache.org/jira/browse/IVY-1471
 [2] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108
 [3] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true
 [4] 
 https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300
 [5] http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/
 
 
 -
 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: Ant-Matrix-Job

[Nicolas Lalevée]

Yesterday I was wondering why it didn't appeared in my Personal View, but I 
didn't looked into it, merly though it was a UI bug.
But it seems indeed gone…

Nicolas

Le 5 mai 2014 à 12:35, Jan Matèrne (jhm) apa...@materne.de a écrit :

 Does anyone know where (and why) the matrix build is gone?
 
 https://builds.apache.org/job/Ant-Build-Matrix/
 
 
 
 Jan
 
 
 
 
 


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

Re: Hoped for advantages of migrating to git

[Nicolas Lalevée]

While I was getting to know better another ASF project Spark [1], I have found 
that they use git, and they heavily use github in their workflow. So I asked 
them how they work it it [2].

Of course the ASF git repo is the official source repo. But contributions are 
asked to go through github. A pull request is open there, discussion may happen 
there [3]. And once a committer is satisfied with the result, the work is being 
imported into the git repo with a script [4].

I am not suggesting we use that workflow or we shouldn't use it. It is just an 
interesting workflow I have found and which we may discuss.

Nicolas

[1] https://spark.apache.org/
[2] 
http://apache-spark-developers-list.1001551.n3.nabble.com/Mailing-list-td6451.html
[3] https://github.com/apache/spark/pull/634
[4] https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py

Le 1 mai 2014 à 02:19, Matt Sicker boa...@gmail.com a écrit :

 Apache projects are already mirrored at GitHub.
 
 https://github.com/apache/
 
 We just need better support for merging back from GitHub (or even being
 able to write to the GitHub repositories).
 
 
 On 30 April 2014 18:00, Andre-John Mas andrejohn@gmail.com wrote:
 
 Fair point.
 
 My experience has been the same. Was a little stubborn at first, but once
 I made the move from Subversion I haven't looked back. One thing that I
 found it fixed, in my environment, is avoiding devs using the main source
 control as a form of backup.
 
 André-John
 
 Sent from my phone. Envoyé depuis mon téléphone.
 
 On 30 Apr 2014, at 18:48, Josh Suereth joshua.suer...@gmail.com wrote:
 
 I'd argue that the convenience of pull requests in ASF should be a
 fixable
 problem.  If ASF is running repositories, Gerrit would be a great way to
 set up an elegant ASF workflow...
 
 In any case, I applaud the effort to migrate to get and understand the
 concerns.  My experience has been truly great moving to git.
 
 
 On Wed, Apr 30, 2014 at 6:33 PM, Andre-John Mas andrejohn@gmail.com
 wrote:
 
 Could we conceive of having a GitHub project, that serves as a point for
 pull-requests and other community work and at the same time have a git
 repo
 at Apache that syncs with this?
 
 
 André-John
 
 Sent from my phone. Envoyé depuis mon téléphone.
 
 On 30 Apr 2014, at 17:33, Nicolas Lalevée nicolas.lale...@hibnet.org
 
 wrote:
 
 Even if I share some of your enthusiasm with git, don't forget that git
 at the ASF isn't like git in github. Pull request, code review and so
 on is
 not as integrated as in github.
 
 Nicolas
 
 Le 30 avr. 2014 à 16:01, Josh Suereth joshua.suer...@gmail.com a
 écrit :
 
 If you don't mind some recommendations from the peanut gallery (been
 using
 git for 5 years now)
 
 
 On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert 
 anto...@gmx.de
 wrote:
 
 
 Hello Maarten,
 
 I do not know a lot about git either.
 
 Here are the advantages I see in migrating to git :
 
 - git allows third-parties to clone an original repository and in
 fact
 to
 create a fork while keeping the possibility of contributing back what
 they
 have created if they want to, and also importantly to incorporate
 inside
 their branches changes done elsewhere including in the reference
 repository. So I see git as having the same strategic importance for
 the
 source code like the fact of uploading the ant jars to maven central
 is for
 the use of the binaries.
 This is pretty huge. The cost of contributions is a lot lower *and*
 you
 can
 perform magic on branches (git rebase) before submitting to upstream
 projects.  We (sbt + Scala) generally have a workflow of:
 
 1. hack, hack, hack on our own clone/branch with a name wip
 2. When done (across the group working on it), rebase the commits and
 clean
 up the commit messages to be as useful as possible
 3. Submit a pull request, code review, go back to #1 as necessary
 4. Merge into master, delete local branch, continue work.
 
 Not only that, we're already using the git Ivy mirror to collaborate
 between sbt devs and outside ivy contributors.  It's a very good model
 for
 highly distributed (i.e. OSS) teams where coordination of
 contributions
 is
 hard.
 
 
 - for the developers of the Apache project - us - the small
 advantages
 are
 to be able to commit stuff locally on our computers before pushing
 when we
 are happy with our changes. Also one can switch branch very quickly
 within
 the same workspace when using git, this might be an advantage.
 I often run 3-5 branches of code for OSS projects.  1-2 of itch
 scratching and 1-3 of bug fixing.  It's a great thing.
 
 
 - because of the popularity of git I imagine that the change is good
 for
 the long run but this is speculation
 Popularity definitely puts it above something like mercurial.   It
 also
 means the tooling for git has become pretty good over the past few
 years.
 JGit even provides really good Git support for programatic access.
 
 
 
 I imagine that some corporations, individuals,or other open source

Re: [VOTE] Release Ant 1.9.4 (second attempt)

[Nicolas Lalevée]

Le 30 avr. 2014 à 05:46, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hi all,
 
 restarting the vote thread after having fixed the pom of ant-testutil and 
 rebuilt
 
 a release with many bug fixes and improvements, including the initial support 
 for Java 1.9,
 the possibility to run JUnit tests in multiple threads (when they are forked)
 and the refactoring of Ant's own test suite which is now based on JUnit 4.
 
 I propose to adopt the following as Ant 1.9.4
 
 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/
  revision 1591180
 Tarballs: https://dist.apache.org/repos/dist/dev/ant/
  revision 5204
 Maven Artifacts:
  
 https://repository.apache.org/content/repositories/orgapacheant-1004/org/apache/ant/
 
 Vote will be open until Monday, May 5 due to upcoming May 1st holiday


+1 for the release

Nicolas


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

Re: Ivy slow resolution

[Nicolas Lalevée]

Le 28 avr. 2014 à 16:36, Josh Suereth joshua.suer...@gmail.com a écrit :

 On Mon, Apr 28, 2014 at 10:13 AM, Nicolas Lalevée 
 nicolas.lale...@hibnet.org wrote:
 
 
 Le 28 avr. 2014 à 13:59, Josh Suereth joshua.suer...@gmail.com a écrit :
 
 On a whim, I implemented parallel download of artifacts by hooking the
 downloadArtifacts
 method of Resolve engine.  While this can potentially speed up download
 performance, the resolution times (getDepedencies) still dominates (of
 course).  Parallel downloads is an often requested feature of sbt, so we
 may still release this hook for our users, as they request it, but I
 think
 the *really* just want faster resolution times.
 
 We may be doing some investigation into improving the performance of
 getDependencies (and most importantly fetchDependencies).  I was curious
 if
 anyone else in the Ivy community has attempted this before and what sorts
 of guidance they could offer before we dig in.
 
 This has been discussed, but AFAIR nothing has been done other than
 discussing the potential issues to tackle.
 
 Things which would require some attention would be to find a way to
 properly report the progress of the parallel download: in the console when
 it's done via Ant or via the listeners for IvyDE.
 A thing that is worrying me, is that Ivy is quite sensitive to which
 thread is actually working on the resolve, see IvyContext's thread local.
 So a parallelization may not be a very upper level than the artifact
 downloading.
 
 
 Totally understand.  I haven't had time to check if my resolution on
 different threads has mucked up the ivy context, but I know I can propagate
 context as needed, as long as downloading artifacts is idempotent (i.e. no
 changes to artifacts).   The first implementation just defers reporting all
 progress until AFTER the entire download, then notifies, which probably
 breaks IvyDE, except I'm only overriding this in sbt itself, so there is no
 IvyDE there :).
 
 So, if this was something to contribute back to ivy (which I'm not sure it
 is, given the lack of real speed-up we're seeing), I'd have to figure out
 how to maintain the progress reporting notifications with the IvyContext,
 possibly adapting my worker pool such that we register a thread-safe
 IvyContext locally for the reporting events to get fired out of?
 
 Does the event model, as it exist, prevent parallelism?

As far as I can tell, no special care has been taken to ensure that even inner 
part of Ivy can be run on multiple threads. So this is to be tested and code 
reviewed.

 In terms of resolution improvements, mostly I was hoping that some
 memoization/cache of immutable graph pieces could help avoid re-resolving
 the same bits of the graph repeatedly.  Again, I haven't dug fully into the
 details of IvyNode, ResolveData + VisitNode, but it seems likely to me that
 we should be able to avoid calling resolve for an artifact (the same
 ModuleRevisionId) more than once during full graph resolution, which (and I
 may be wrong) appears to be the case when we profile Ivy.  I'm mostly
 concerned with this aspect, and was wondering if anyone else has seen this
 or if we're doing something very wrong in sbt.


I don't think Ivy is doing a resolution twice. This part of Ivy is quite 
complex, so I may be wrong, but we shouldn't forget that a resolve of a module 
is often contextualized by the caller, because there are some different 
versioning constraints, or because the root configuration is not the same.
But I think that it can be parallelized. At least in theory.

Nicolas


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

Re: Hoped for advantages of migrating to git

[Nicolas Lalevée]

Even if I share some of your enthusiasm with git, don't forget that git at the 
ASF isn't like git in github. Pull request, code review and so on is not as 
integrated as in github.

Nicolas

Le 30 avr. 2014 à 16:01, Josh Suereth joshua.suer...@gmail.com a écrit :

 If you don't mind some recommendations from the peanut gallery (been using
 git for 5 years now)
 
 
 On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert anto...@gmx.dewrote:
 
 
 Hello Maarten,
 
 I do not know a lot about git either.
 
 Here are the advantages I see in migrating to git :
 
 - git allows third-parties to clone an original repository and in fact to
 create a fork while keeping the possibility of contributing back what they
 have created if they want to, and also importantly to incorporate inside
 their branches changes done elsewhere including in the reference
 repository. So I see git as having the same strategic importance for the
 source code like the fact of uploading the ant jars to maven central is for
 the use of the binaries.
 
 
 This is pretty huge. The cost of contributions is a lot lower *and* you can
 perform magic on branches (git rebase) before submitting to upstream
 projects.  We (sbt + Scala) generally have a workflow of:
 
 1. hack, hack, hack on our own clone/branch with a name wip
 2. When done (across the group working on it), rebase the commits and clean
 up the commit messages to be as useful as possible
 3. Submit a pull request, code review, go back to #1 as necessary
 4. Merge into master, delete local branch, continue work.
 
 Not only that, we're already using the git Ivy mirror to collaborate
 between sbt devs and outside ivy contributors.  It's a very good model for
 highly distributed (i.e. OSS) teams where coordination of contributions is
 hard.
 
 
 - for the developers of the Apache project - us - the small advantages are
 to be able to commit stuff locally on our computers before pushing when we
 are happy with our changes. Also one can switch branch very quickly within
 the same workspace when using git, this might be an advantage.
 
 
 I often run 3-5 branches of code for OSS projects.  1-2 of itch
 scratching and 1-3 of bug fixing.  It's a great thing.
 
 
 - because of the popularity of git I imagine that the change is good for
 the long run but this is speculation
 
 
 Popularity definitely puts it above something like mercurial.   It also
 means the tooling for git has become pretty good over the past few years.
 JGit even provides really good Git support for programatic access.
 
 
 
 I imagine that some corporations, individuals,or other open source
 organizations will take advantage of our projects moving to git to create
 these forks, either because the contribution process via JIRA is too slow,
 or because they want to create proprietary enhancements, or because they
 are not sure that the changes that they do match the views /plans... of our
 the Ant/Ivy/Ivyde/Easyant Apache project.
 
 
 From an sbt perspective, you'd see us attempting to contribute things back
 far more often than we do now.  If you'd like an example project that
 contains website assets in it, feel free to checkout github.com/sbt/sbt and
 see how long it takes to switch branches / load the repository initially.
 
 - The Peanut Gallery (Josh)


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

Re: [VOTE] migration to git

[Nicolas Lalevée]

Le 28 avr. 2014 à 05:02, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hi,
 
 Let's vote about migrating to git :
 
 -  Ant
 
 - Ivy 
 
 - easyant
 
 - Ivyde
 
 - the antlibs
 
 I am not including the sandbox in the thread intentionally.
 
 The web sites will remain in svn in any event because svnpubsub is the only 
 supported mechanism to maintain web sites AFAIK.
 
 [] Yes
 [] No

+0 for all.

It's not a +1 because even if I like git more than svn, I am not sure of the 
amount of work required afterwards (documentation update, CI, release scripts, 
etc…), so I don't want my vote to be counted as important as the vote of 
someone who doesn't want to make the transition.

But it's a positive 0 as I would gladly follow any decision taken by the PMC, 
especially on IvyDE.

Nicolas


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

Re: [VOTE] migration to git

[Nicolas Lalevée]

Le 28 avr. 2014 à 07:29, Jan Matèrne (jhm) apa...@materne.de a écrit :

 Let's vote about migrating to git :
 -  Ant
 
 +1
 
 - Ivy
 
 +0, because I dont work on that codebase and therefore dont want to
 influence these committers.
 
 - easyant
 
 +0, same as for Ivy
 
 
 - Ivyde
 
 +0, dito
 
 
 - the antlibs
 
 +1
 
 
 
 I am not including the sandbox in the thread intentionally.
 
 Why not having one sandbox repo? New projects could be added there as one
 directory, if creating a gitmodule would enforce infra to act.

What would be the process of a sandbox project becoming mainstream with a one 
for all ? In the upgrade, we would want a standalone repo for it. Cloning the 
sandbox would mean having the full history of every other sandbox project in 
there. Would that work well ?

Nicolas


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

Re: Ivy slow resolution

[Nicolas Lalevée]

Le 28 avr. 2014 à 13:59, Josh Suereth joshua.suer...@gmail.com a écrit :

 On a whim, I implemented parallel download of artifacts by hooking the
 downloadArtifacts
 method of Resolve engine.  While this can potentially speed up download
 performance, the resolution times (getDepedencies) still dominates (of
 course).  Parallel downloads is an often requested feature of sbt, so we
 may still release this hook for our users, as they request it, but I think
 the *really* just want faster resolution times.
 
 We may be doing some investigation into improving the performance of
 getDependencies (and most importantly fetchDependencies).  I was curious if
 anyone else in the Ivy community has attempted this before and what sorts
 of guidance they could offer before we dig in.

This has been discussed, but AFAIR nothing has been done other than discussing 
the potential issues to tackle.

Things which would require some attention would be to find a way to properly 
report the progress of the parallel download: in the console when it's done via 
Ant or via the listeners for IvyDE.
A thing that is worrying me, is that Ivy is quite sensitive to which thread is 
actually working on the resolve, see IvyContext's thread local. So a 
parallelization may not be a very upper level than the artifact downloading.

Nicolas


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

Re: Migrating to Git

[Nicolas Lalevée]

Le 20 avr. 2014 à 17:34, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hi,
 
 like Michael one of my hopes in migrating to git is that it will allow non 
 ASF committers 
 to create their own forks of projects and be able to keep them (or not) up to 
 date with the
 master branch.
 
 I have also done a little bit of investigation to see how other projects have 
 migrated to GIT
 (by looking in the INFRA JIRA).
 
 Here some examples :
 
 Migration of Wicket to Git [1]
 Migration of Maven to Git [2]
 Migration of Cayenne to Git [3]
 
 and a document about switching to git [4]
 
 list of ASF GIT repos [5]

Thank you for the pointers.

 Do we need to make a formal vote before requesting the migration to git ?

I think we'll need one, this is not a trivial change.

And by the way, what will be migrated ? I guess not everything. I would like to 
keep the sandbox in svn, so we can create prototypes as will, not requiring 
infra to do so.

Nicolas


 
 
 Regards,
 
 
 Antoine
 
 [1] https://issues.apache.org/jira/browse/INFRA-4204
 [2] https://issues.apache.org/jira/browse/INFRA-5390
 [3] https://issues.apache.org/jira/browse/INFRA-5936
 [4] https://git-wip-us.apache.org/docs/switching-to-git.html
 [5] https://git-wip-us.apache.org/repos/asf
 
 
 
 On Apr 20, 2014, at 5:46 AM, Michael Clarke michael.m.cla...@gmail.com 
 wrote:
 
 I think a move to Git is a good idea.
 
 I personally don't have a huge issue with using Subversion, but Git would
 make it easier to allow potentially high impact changes to be made outside
 of the mainline repository. These changes could then be opened up for
 review by others before any decision about whether they get accepted into
 master (I know that SVN had branches for doing this, but this was only
 available to people who already had commit status). I think that moving to
 Git would make it easier to submit features and patches given the
 prevalence of the likes of Github.
 
 Thanks,
 Michael
 
 
 On 14 April 2014 15:15, Martin Gainty mgai...@hotmail.com wrote:
 
 Jan/Stefan
 
 This is the license.txt which sits in every apache project
 Maven currently contains license in  $M2_HOME/license.txt
 
 
Apache License
  Version 2.0, January 2004
   http://www.apache.org/licenses/
 
  TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 
  1. Definitions.
 
 License shall mean the terms and conditions for use, reproduction,
 and distribution as defined by Sections 1 through 9 of this document.
 
 Licensor shall mean the copyright owner or entity authorized by
 the copyright owner that is granting the License.
 
 Legal Entity shall mean the union of the acting entity and all
 other entities that control, are controlled by, or are under common
 control with that entity. For the purposes of this definition,
 control means (i) the power, direct or indirect, to cause the
 direction or management of such entity, whether by contract or
 otherwise, or (ii) ownership of fifty percent (50%) or more of the
 outstanding shares, or (iii) beneficial ownership of such entity.
 
 You (or Your) shall mean an individual or Legal Entity
 exercising permissions granted by this License.
 
 Source form shall mean the preferred form for making modifications,
 including but not limited to software source code, documentation
 source, and configuration files.
 
 Object form shall mean any form resulting from mechanical
 transformation or translation of a Source form, including but
 not limited to compiled object code, generated documentation,
 and conversions to other media types.
 
 Work shall mean the work of authorship, whether in Source or
 Object form, made available under the License, as indicated by a
 copyright notice that is included in or attached to the work
 (an example is provided in the Appendix below).
 
 Derivative Works shall mean any work, whether in Source or Object
 form, that is based on (or derived from) the Work and for which the
 editorial revisions, annotations, elaborations, or other
 modifications
 represent, as a whole, an original work of authorship. For the
 purposes
 of this License, Derivative Works shall not include works that remain
 separable from, or merely link (or bind by name) to the interfaces
 of,
 the Work and Derivative Works thereof.
 
 Contribution shall mean any work of authorship, including
 the original version of the Work and any modifications or additions
 to that Work or Derivative Works thereof, that is intentionally
 submitted to Licensor for inclusion in the Work by the copyright
 owner
 or by an individual or Legal Entity authorized to submit on behalf of
 the copyright owner. For the purposes of this definition, submitted
 means any form of electronic, verbal, or written communication sent
 to the Licensor or its 

Re: Migrating to Git

[Nicolas Lalevée]

I like git, so I like the idea.

But what about the publication of the doc on the website ? Today we rely on 
svn:externals for the doc of each release. How would it be managed if it's 
migrated to git ?

And I have not searched in the ASF docs, but do you have any pointer on some 
guidelines about handling IP ? Can we merge any pull request ?

Nicolas

Le 14 avr. 2014 à 08:24, Jean-Louis Boudart jeanlouis.boud...@gmail.com a 
écrit :

 HI there,
 
 Since write git repository are accessible for a while, i suggest (as many
 of you) to switch projects to git.
 I know this has been discussed many times [1] but never in a dedicated
 thread.
 
 So what do you think about this ?
 
 Are you ok to migrate :
 * ant
 * ivy / ivyde
 * easyant
 * rest of stuff (antlibs, stuff from sandbox?)
 
 
 [1] http://markmail.org/message/6ik4nyueayz2fpnx
 -- 
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/


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

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Nicolas Lalevée]

Note that the release if not accepted yet, it cannot be published.

Nicolas

Le 14 févr. 2014 à 14:55, Charles Duffy char...@dyfis.net a écrit :

 Apologies -- new job; I dropped the ball somewhat. I'll try to get things
 back on track this weekend.
 
 
 On Fri, Feb 14, 2014 at 1:58 AM, Jean-Louis Boudart 
 jeanlouis.boud...@gmail.com wrote:
 
 Is the release over ?
 
 I dont find it on maven central
 Le 28 janv. 2014 01:46, Charles Duffy char...@dyfis.net a écrit :
 
 The keys are actually different -- the one used by the currently-posted
 .asc files is associated with Indeed, Inc. I'll be resigning the binaries
 after verifying that their Indeed signatures are intact (and moving them
 to
 dist.apache.org at that time).
 
 Expect a note in this thread when that happens.
 
 
 On Mon, Jan 27, 2014 at 6:42 PM, Nicolas Lalevée 
 nicolas.lale...@hibnet.org
 wrote:
 
 
 Le 22 janv. 2014 à 00:52, Nicolas Lalevée nicolas.lale...@hibnet.org
 a
 écrit :
 
 I have found some issues. The source distribution seems to miss some
 test files. I guess this has been the case for quite some time. And it
 is
 just about the tests. And it is an RC. So OK for me. And I will fix
 that
 soon in trunk.
 
 To avoid confusion and make things simpler, I suggest we modify the
 release process to that everything goes through the svn of
 dist.apache.org,
 and not use anymore people.apache.org. In the end, everything is
 published there.
 And I'll modify in the doc of the release process the template of the
 email of the vote to include a line that is referencing the svn tag. So
 it's more difficult to miss it, and it is helpful to do review.
 
 I have tested the staging update site: works like a charm.
 
 So LGTM.
 
 I will cast my vote as soon as I can verify the signature of the
 artifacts.
 
 You pushed some keys to the KEYS files, but it doesn't seems to be the
 same as the one you used to sign the proposed artifacts.
 
 My gpg is asking for the key ID 93FB868A. Did I do something wrong or
 the
 keys are actually different ?
 
 Nicolas
 
 
 
 Nicolas
 
 Le 21 janv. 2014 à 17:19, Charles Duffy char...@dyfis.net a écrit
 :
 
 FYI --
 
 A tag at
 https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1now
 exists. This differs from the branch head from which the binaries
 for
 test
 were built only inasmuch as its svn:externals specify a specific
 revision
 of the documentation build tools rather than leaving their revision
 floating.
 
 
 On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy char...@dyfis.net
 wrote:
 
 Howdy --
 
 I've attempted to follow the documentation at
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
 
 http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html(as
 included-by-reference in the former) in preparing the above. That
 said, it
 appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1
 branch,
 from the present tip of which the binaries were built, but no
 associated
 tag).
 
 I'll be sure to get KEYS up-to-date. Thank you for the pointers.
 
 
 On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig 
 bode...@apache.org
 wrote:
 
 Hi Charles,
 
 we don't really release binaries, they are just a convenience.
 All
 that
 matters as a release is the sources.
 
 I'm not sure there is anything documenting the release process for
 Ivy
 but in general you create an svn tag and build source and binary
 distributions from that.
 
 What you have built now is a binary for testing and you don't
 really
 need to vote on that at all.  Just encourage people to try it out
 :-)
 
 If you want to perform some sort of test-release, have a look at
 http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions
 and
 similar instructions to get an idea of what is expected.
 
 PS -- As this build was performed on hardware owned by Indeed,
 Inc.,
 the
 binaries are signed with the du...@indeed.com GPG key. For any
 final
 release, I would be using hardware under personal control and a
 key
 associated with cdu...@apache.org.
 
 Please make sure whatever key you use is inside
 https://dist.apache.org/repos/dist/release/ant/KEYS - if you need
 any
 help committing it there, please yell.
 
 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
 
 
 
 -
 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.4 Based on RC1

[Nicolas Lalevée]

+1

Nicolas

Le 21 janv. 2014 à 13:33, Stefan Bodewig bode...@apache.org a écrit :

 Hi all,
 
 following the Commons Compress 1.7 release I'd like to release a new
 version of the Antlib as well.  Most importantly this adds tasks and
 resources for Snappy and traditional Unix .Z compress.  Both of them
 read-only.
 
 svn tag:
https://svn.apache.org/repos/asf/ant/antlibs/compress/tags/1_4_RC1/
(svn revision 1559922)
 
 Tarballs:
https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
(svn revision 4125)
 
 Maven Central Stuff:

 https://repository.apache.org/content/repositories/orgapacheant-1001/org/apache/ant/ant-compress/1.4/
 
 Stefan
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


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

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Nicolas Lalevée]

Le 22 janv. 2014 à 00:52, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 I have found some issues. The source distribution seems to miss some test 
 files. I guess this has been the case for quite some time. And it is just 
 about the tests. And it is an RC. So OK for me. And I will fix that soon in 
 trunk.
 
 To avoid confusion and make things simpler, I suggest we modify the release 
 process to that everything goes through the svn of dist.apache.org, and not 
 use anymore people.apache.org. In the end, everything is published there.
 And I'll modify in the doc of the release process the template of the email 
 of the vote to include a line that is referencing the svn tag. So it's more 
 difficult to miss it, and it is helpful to do review.
 
 I have tested the staging update site: works like a charm.
 
 So LGTM.
 
 I will cast my vote as soon as I can verify the signature of the artifacts.

You pushed some keys to the KEYS files, but it doesn't seems to be the same as 
the one you used to sign the proposed artifacts.

My gpg is asking for the key ID 93FB868A. Did I do something wrong or the keys 
are actually different ?

Nicolas


 
 Nicolas
 
 Le 21 janv. 2014 à 17:19, Charles Duffy char...@dyfis.net a écrit :
 
 FYI --
 
 A tag at https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1 now
 exists. This differs from the branch head from which the binaries for test
 were built only inasmuch as its svn:externals specify a specific revision
 of the documentation build tools rather than leaving their revision
 floating.
 
 
 On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy char...@dyfis.net wrote:
 
 Howdy --
 
 I've attempted to follow the documentation at
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
 http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html (as
 included-by-reference in the former) in preparing the above. That said, it
 appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1 branch,
 from the present tip of which the binaries were built, but no associated
 tag).
 
 I'll be sure to get KEYS up-to-date. Thank you for the pointers.
 
 
 On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig bode...@apache.orgwrote:
 
 Hi Charles,
 
 we don't really release binaries, they are just a convenience.  All that
 matters as a release is the sources.
 
 I'm not sure there is anything documenting the release process for Ivy
 but in general you create an svn tag and build source and binary
 distributions from that.
 
 What you have built now is a binary for testing and you don't really
 need to vote on that at all.  Just encourage people to try it out :-)
 
 If you want to perform some sort of test-release, have a look at
 http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions and
 similar instructions to get an idea of what is expected.
 
 PS -- As this build was performed on hardware owned by Indeed, Inc., the
 binaries are signed with the du...@indeed.com GPG key. For any final
 release, I would be using hardware under personal control and a key
 associated with cdu...@apache.org.
 
 Please make sure whatever key you use is inside
 https://dist.apache.org/repos/dist/release/ant/KEYS - if you need any
 help committing it there, please yell.
 
 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
 


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

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Nicolas Lalevée]

Le 22 janv. 2014 à 06:27, Stefan Bodewig bode...@apache.org a écrit :

 On 2014-01-22, Nicolas Lalevée wrote:
 
 To avoid confusion and make things simpler, I suggest we modify the
 release process to that everything goes through the svn of
 dist.apache.org, and not use anymore people.apache.org.
 
 +1
 
 we may need to adjust things if Charles cannot commit there - I vaguelly
 recall a thread in Commons where only PMC members had write access but
 changing that was only a matter of a JIRA ticket for infra.

He can, since the staging eclipse updatesite as already been pushed there. But 
maybe there are different rights between the dev and release spaces of dist.

Nicolas


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

Re: [VOTE] Ivy 2.4.0-rc1 Release

[Nicolas Lalevée]

I have found some issues. The source distribution seems to miss some test 
files. I guess this has been the case for quite some time. And it is just 
about the tests. And it is an RC. So OK for me. And I will fix that soon in 
trunk.

To avoid confusion and make things simpler, I suggest we modify the release 
process to that everything goes through the svn of dist.apache.org, and not use 
anymore people.apache.org. In the end, everything is published there.
And I'll modify in the doc of the release process the template of the email of 
the vote to include a line that is referencing the svn tag. So it's more 
difficult to miss it, and it is helpful to do review.

I have tested the staging update site: works like a charm.

So LGTM.

I will cast my vote as soon as I can verify the signature of the artifacts.

Nicolas

Le 21 janv. 2014 à 17:19, Charles Duffy char...@dyfis.net a écrit :

 FYI --
 
 A tag at https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1 now
 exists. This differs from the branch head from which the binaries for test
 were built only inasmuch as its svn:externals specify a specific revision
 of the documentation build tools rather than leaving their revision
 floating.
 
 
 On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy char...@dyfis.net wrote:
 
 Howdy --
 
 I've attempted to follow the documentation at
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
 http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html (as
 included-by-reference in the former) in preparing the above. That said, it
 appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1 branch,
 from the present tip of which the binaries were built, but no associated
 tag).
 
 I'll be sure to get KEYS up-to-date. Thank you for the pointers.
 
 
 On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig bode...@apache.orgwrote:
 
 Hi Charles,
 
 we don't really release binaries, they are just a convenience.  All that
 matters as a release is the sources.
 
 I'm not sure there is anything documenting the release process for Ivy
 but in general you create an svn tag and build source and binary
 distributions from that.
 
 What you have built now is a binary for testing and you don't really
 need to vote on that at all.  Just encourage people to try it out :-)
 
 If you want to perform some sort of test-release, have a look at
 http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions and
 similar instructions to get an idea of what is expected.
 
 PS -- As this build was performed on hardware owned by Indeed, Inc., the
 binaries are signed with the du...@indeed.com GPG key. For any final
 release, I would be using hardware under personal control and a key
 associated with cdu...@apache.org.
 
 Please make sure whatever key you use is inside
 https://dist.apache.org/repos/dist/release/ant/KEYS - if you need any
 help committing it there, please yell.
 
 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: IvyDE's workspace resolver taking directory structure into account

[Nicolas Lalevée]

Le 15 janv. 2014 à 15:37, Andrew January andrewjanu...@gmail.com a écrit :

 Has there been any previous discussion around optionally taking directory
 structure into account in IvyDE's workspace resolver?
 
 Our project structure is set up as:
 
project-1/
project-1
util-1
project-2/
project-2
util-2
 
 Where util-1 and util-2 are checked out from the same scm location, and so
 publish the same revision of the same module.
 
 Currently we can use the workspace resolver and close util-2 when working
 on project-1, and vice-versa.
 The problem is this can be error prone, and people tend to forget, end up
 referencing the wrong project and get confused.

If util-1 and util-2 come from the same scm location, why do you need to switch 
? util-1 and util-2 should have the same content, right ?

 We have been contemplating modifying IvyDE to walk through all projects in
 the workspace, and pick the one whose location URI is the closest match.
 
 We only have a maximum of a dozen projects in a workspace, so it seems like
 this wouldn't be a huge performance issue.
 Has this been tried or discussed before? What were the drawbacks?
 
 If we were to go ahead and do this, would a patch be considered?

I would need to understand your use case before going forward. Maybe there is a 
simpler solution. I would prefer keep thing as simple as possible.

As soon as we agree on a solution for your use case, any patch will be 
welcomed. :)

Nicolas


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

Re: Proposal: Make Xooki spoof TiddlyWiki to use TiddlyFox plugin?

[Nicolas Lalevée]

Le 20 janv. 2014 à 17:23, Charles Duffy char...@dyfis.net a écrit :

 Howdy, all --
 
 The release process for Ivy includes using Xooki to edit the documentation
 before publication.
 
 Unfortunately, the code Xooki uses for saving updated files, borrowed from
 an early TiddlyWiki release, is no longer supported on modern FireFox or
 Chrome -- and while HTML5 has its own filesystem API, that refers to a
 sandbox cut off from the real visible filesystem, so HTML5 apps can't
 edit files on the filesystem directly.
 
 Older versions of TiddlyWiki use a Java plugin for filesystem access;
 however, this isn't actively maintained, and when testing code that uses it
 for saving from Xooki, I get a notice that future security changes are
 going to cause breakage.
 
 The way modern versions of TiddlyWiki are able to edit filesystem contents
 consists of using the TiddlyFox plugin. The mechanism used by this plugin
 to detect when it's being used to edit a TiddlyWiki document is
 straightforward to duplicate -- basically, one need only identify oneself
 as a TiddlyWiki in a tag in the header, and the user will be prompted to
 allow write access should the plugin be correctly installed.
 
 Any yeas/nays/alternative approaches? In preparing the Ivy 2.4.0-rc1
 branch, I ended up editing HTML by hand -- but if we're going to be doing
 that on an ongoing basis, we should update the process documentation to no
 longer point at tools which aren't still supported.

Indeed I no longer edit documentation within the browser, I edit them with my 
preferred text editor. The documentation is indeed not up to date. But it is 
still using the wiki syntax, we don't actually write all HTML tags by hand. And 
the html preview of the source file is still working.

I don't mind changing a little bit of tools for the doc and the site. For the 
little test I did, TiddlyFox didn't work on my Mac. So it seems that using 
TiddlyFox won't help for me. But it won't make things worst either. So no 
objection.

Nicolas


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

Re: Ivy Code formatting

[Nicolas Lalevée]

Le 12 janv. 2014 à 21:43, Jan Matèrne (jhm) apa...@materne.de a écrit :

 Maybe we could store the configuration files in the repo.
 E.g. Apache Camel does that in a way for multiple IDEs:
 https://github.com/apache/camel/tree/master/buildingtools
 https://github.com/apache/camel/tree/master/etc

We do store it in svn. That is what Jean-Louis is actually suggesting: changing 
the configuration for everybody since it's shared via svn. It is just spread in 
each project rather than centralized in an etc folder.

About the proposal, I am not a fan of Saved actions (probably because I will 
have to change a little bit my habits, lazy that I am !). But I don't care that 
much, I still can adapt myself. So +1 for the change.

Nicolas

 
 Jan
 
 -Ursprüngliche Nachricht-
 Von: Charles Duffy [mailto:char...@dyfis.net]
 Gesendet: Sonntag, 12. Januar 2014 19:11
 An: Ant Developers List
 Betreff: Re: Ivy Code formatting
 
 +1
 
 
 On Sun, Jan 12, 2014 at 11:14 AM, Jean-Louis Boudart 
 jeanlouis.boud...@gmail.com wrote:
 
 Hi there,
 
 While fixing a bug i noticed that ivy source code was not fully
 formatted.
 Eclipse formatter is not exported as a plain file but present through
 eclipse project preferences in .settings folder [1].
 
 Considering .settings folder is already commited i suggest to
 activate
 Saved actions to apply on each save :
 
   - code formatting
   - organize import
 
 
 I also suggest to apply formatting on whole project (could be done in
 a few clicks with cleanup feature in eclipse).
 
 Are you in favor of those code modifications ?
 
 We could take the opportunity to cut this before 2.4.0 release.
 
 PS: This could aslo applied on others subprojects (ant for example)
 
 [1]
 
 
 https://svn.apache.org/repos/asf/ant/ivy/core/trunk/.settings/org.ecli
 pse.jdt.core.prefs
 
 --
 Jean Louis Boudart
 Independent consultant
 Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
 
 -
 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 release schedule

[Nicolas Lalevée]

Le 4 janv. 2014 à 14:11, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit :

 
 Le 2 janv. 2014 à 17:34, Nicolas Lalevée nicolas.lale...@hibnet.org a écrit 
 :
 
 
 Le 2 janv. 2014 à 17:10, Charles Duffy char...@dyfis.net a écrit :
 
 Absolutely, then. :)
 
 I was under the impression that only members of the PMC could call a vote
 for a release.
 
 Here is the official rules:
 http://ant.apache.org/bylaws.html
 
 You can do a release, but it will be officially accepted only by a majority 
 of the PMC.
 
 If that's something any committer can do, I'll gladly run the process after
 your pending feature is in.
 
 I think we have a good doc about how to release:
 http://ant.apache.org/ivy/history/trunk/dev/makerelease.html
 
 I willing to help, especially for the optional publication to the Eclipse 
 updatesite.
 
 I'll keep you posted about my progress.
 
 I nailed it. It needs a little bit of documentation thought. I'll write some 
 soon.

doc written. It's good for me.

Nicolas

 
 Nicolas
 
 
 Cheers,
 Nicolas
 
 
 Thanks!
 
 
 On Thu, Jan 2, 2014 at 10:02 AM, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
 
 Le 30 déc. 2013 à 19:35, Charles Duffy char...@dyfis.net a écrit :
 
 Howdy, all --
 
 There's rather a lot of good stuff on Ivy's trunk.
 
 Agreed.
 
 Any thoughts as to when
 we might be in a position to start a release candidate series?
 
 I think any time a committer is willing to do so.
 
 (As there are tickets assigned to 2.4.0, and nothing on 2.3.1, would I be
 correct in gathering that that's where we're going next?)
 
 Yep 2.4.0 should be the next one.
 
 I only have one wish. I am working on supporting packed (.pack.gz)
 resources from Eclipse update sites. For that I would need to redesign a
 feature which is only in trunk: uncompress artifact on resolve (not
 documented yet, see DefaultRepositoryCacheManager#uncompressArtifact).
 Since I would like to break it a little bit, I would like to do it before
 releasing it, so no backward compatibility have to be supported.
 I am struggling a little bit with it, but I don't think it will take very
 long.
 
 Nicolas
 
 
 -
 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: Cleanup callbacks in IvyContext?

[Nicolas Lalevée]

Le 8 janv. 2014 à 16:47, Charles Duffy char...@dyfis.net a écrit :

 Apologies about the delay before providing a full reply -- I was
 unexpectedly stuck in Chicago without my laptop.

No worries, I am myself usually random in my response time, due to my sparse 
free time.

 The problem with the LockStrategy interface is that it's too fine-grained
 for the use case wherein a read lock needs to be held for the duration of a
 high-level operation.
 
 Consider the case where a user calls ivy:resolve, ivy:retrieve and
 ivy:report in sequence. An ivy:clean run by an external process between any
 of these operations would cause a failure, and would be prevented by any
 proper repository-wide read-lock mechanism.
 
 The above _does_ indicate a potential problem with the proposal I opened
 this thread with -- inasmuch as it doesn't provide a way to hold locks
 spanning multiple high-level operations while still putting each of those
 operations in a separate IvyContext. I wonder if it might make sense to
 allow a given member in the stack to indicate that it should hold locks its
 children. For ant, being generally a short-lived process, it might make
 sense for the parent context to be the read lock holder.
 
 Does this clarify the issue I'm trying to solve?

Yep, a quite hard problem to resolve. At the ant task level I don't know how 
you could nail it without asking the end user to call some ivy:lock task.

I myself don't have much experience with file based lock mechanism between 
different process. For instance what happens if a process holding a lock is 
killed -9, or whatever which make the jvm not even able to trigger its shutdown 
hooks ?

Nicolas

 
 
 On Sat, Jan 4, 2014 at 8:06 AM, Nicolas Lalevée
 nicolas.lale...@hibnet.orgwrote:
 
 
 Le 3 janv. 2014 à 22:28, Charles Duffy char...@dyfis.net a écrit :
 
 Howdy, all --
 
 I'm trying to strengthen Ivy's locking system to make it strong enough to
 allow ivy:clean at arbitrary times on systems which can have other
 actions
 making use of the same shared caches.
 
 There are a few requirements to make this happen while still allowing
 multiple resolves (and like operations) to occur concurrently. One of
 those
 is maintaining nonexclusive read locks (as opposed to the write locks
 which
 are currently supported), and cleaning them up when necessary. For
 ease-of-implementation, I'm currently proposing to only support this
 behavior when NIO locks (which implicitly support shared locking
 semantics)
 are enabled.
 
 To clean these locks up without requiring end-user code to be modified, I
 propose using the IvyContext stack -- allowing Runnables to be attached
 to
 a stack element, and invoking them implicitly when the stack is popped.
 
 
 Because converting a read lock to a write lock is inherently prone to
 race
 conditions, we might need to break backwards compatibility with respect
 to
 ivy:clean, allowing this to be called only inside a context where no read
 operations have been done -- or breaking read lock semantics by dropping
 all read locks before grabbing the write lock.
 
 
 Thoughts?
 
 My first blind though would be that IvyContext seems to be high level to
 handle locking. Couldn't it be done by improving the LockStrategy interface
 so that it also handles read locks ?
 
 Nicolas
 
 
 
 -
 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: Cleanup callbacks in IvyContext?

[Nicolas Lalevée]

Le 9 janv. 2014 à 19:43, Charles Duffy char...@dyfis.net a écrit :

 On Thu, Jan 9, 2014 at 12:17 PM, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
 Yep, a quite hard problem to resolve. At the ant task level I don't know
 how you could nail it without asking the end user to call some ivy:lock
 task.
 
 
 I'd like to argue that for ant tasks, a default behavior of releasing locks
 only on process shutdown should be adequate -- ant invocations not being
 long-lived by nature.

I was just thinking about locking the usual configure - resolve - retrieve - 
report, but I forgot that to run tests you need a classpath which needs to 
continue to exist on disk. You're right, releasing at shutdown seems to fit 
every usual use case.

 IDE plugins alter this a bit... but then, is it really safe to delete
 caches while a running IDE expects them to persist?

I think there will be some trouble with Eclipse users if IvyDE starts using 
locks. I remember IvyDE bugs on Windows where users would complain they cannot 
delete files because IvyDE via Eclipse was holding a reference to them. Since 
it is in an IDE and humans have only one brain, let's assume they only do one 
thing at a time, they are not ivy:cleaning via ant and running something in 
Eclipse at the same time, at least not on a daily basis. If they do, then thing 
will expectedly break, and the break is quite understandable.
And actually Eclipse is having a layer of cache upon the filesystem, which make 
errors on file search if the cache is not in sync, generate unsolvable bugs 
[1]. So I guess it will be OK if Eclipse show errors on such concurrent use 
case, users should be used to it.

To come back to the original topic, and to answer the use case about allowing 
to safely run an ivy:clean next to an ivy:resolve-and-others, for instance 
for the use case of a CI server, the IvyContext will not have an enough wide 
scope. The jvm shutdown hook should be better used, right ? And it should be 
optional so that in IDE like in IvyDE, locks can be disabled and won't be an 
issue.

 I myself don't have much experience with file based lock mechanism between
 different process. For instance what happens if a process holding a lock is
 killed -9, or whatever which make the jvm not even able to trigger its
 shutdown hooks ?
 
 
 I would only propose to support this with NIO locks in use. These are
 implicitly released on file descriptor release, even when this is caused by
 SIGKILL, power termination, etc.

I didn't know, that is nice.

Nicolas

[1] https://issues.apache.org/jira/browse/IVYDE-302
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org