Re: [VOTE] Retire the IvyDE Subproject

[Nicolas Lalevée]

> Le 23 nov. 2023 à 08:19, Stefan Bodewig  a écrit :
> 
> I'm really sorry and embarrassed but I seem to have misunderstood the
> purpose of the Attic, it is not responsible for retiring subprojects,
> only for top level projects like Ant as a whole with all subprojects.
> 
> The correct process to follow is
> https://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component
> 
> This is a new vote as I do not want to assume I could transfer the votes
> of a different vote and repurpose them.

Thank you for your diligence.

> 
> The actual vote:
> 
> Following our own rules I propose zo retire IvyDE.
> 
> Vote will be open for at lease 72 hours, will not end before 2023-11-26T07:30 
> UTC

+1

Nicolas

Re: [VOTE] Send IvyDE to the Apache Attic

[Nicolas Lalevée]

> Le 19 nov. 2023 à 18:39, Stefan Bodewig  a écrit :
> 
> Hi all,
> 
> within the "Future of Ivy and IvyDE" thread[1] I started about three
> months ago to me it seemed as if people wouldn't be happy if IvyDE died
> but I also didn't sense there was a community willing to keep it
> alive. Consequently I now call for a vote to send IvyDE to the Apache
> Attic following the rules layed out in https://attic.apache.org/process.html
> 
> The attic doesn't have to be a dead-end. If there are people who want to
> fork IvyDE outside of the ASF they are free to (and have always
> been). Basically it would resolve the Ant PMC of the duty of oversight
> over the code base.
> 
> This vote will require either three PMC members to vote +1 to pass or
> alternatively less than three -1s - but I really hope we don't end up
> with not getting enough votes at all. If there is any -1 by a PMC member
> I'm willing to immediately cancel the vote and rediscuss.
> 
> 
> So here is the formal vote:
> 
> I hereby propose to create a board resolution that will send IvyDE to
> the Apache Attic.

+1

Nicolas

PS: a little part of me is crying, this project was my first substantial 
involvement in the ASF ^^


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

Re: Trying my hands at an ivy-updatesite (was Re: Future of Ivy and IvyDE)

[Nicolas Lalevée]

> Le 19 nov. 2023 à 18:16, Stefan Bodewig  a écrit :
> 
> On 2023-09-05, Nicolas Lalevée wrote:
> 
>> And we tried our best to be opened on how to build and release the
>> plugin and the updatesite, it is documented [2]. On my machine which
>> just have Ant and Java installed, I just tried and I have been able to
>> build of the updatesite with the last release of Ivy without much
>> effort.
> 
> Many thanks for the pointer, Nicolas.
> 
> In my case it immediately stopped with
> 
> ,
> | eclipse-startup-check:
> | 
> | BUILD FAILED
> | /home/stefan/devel/ASF/ivy-updatesite/build.xml:39: An Eclipse install is 
> needed to run the build. Set your Eclipse install dir into the baseLocation 
> property.
> `
> 
> and I haven't got any idea of which version of Eclipse I'd need to
> install. So I went with 202309 and kept my fingers crossed. At least the
> build proceeded.
> 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.2.final_20230817170011/
> is what I created. TBH I have no idea what I have created and signed -
> nor do I have any way of verifying it works.
> 
> If anybody wants - and is able - to check what I've created, I'd be
> grateful. Even then I don't really feel comfortable calling for a vote
> on something I don't even trust myself.

Thank you Stefan to have tried, and successfully build an Eclipse updatesite ! 
(I admit I didn’t validated them functionally, I just looked at the files).

It reassures me that the scripts are still working, not only on my machine, 
even for someone not used to this very particular build system.

Considering the ongoing vote on IvyDE retirement, I don’t think we need to make 
them official Apache release artifacts. Anyone actually interested to have this 
plugin installed in his Eclipse should be able to be rebuild it. If in the 
future there is a newer version of Ivy, the situation will be the same.

Nicolas

> 
> Cheers
> 
>Stefan
> 
>> [2] https://ant.apache.org/ivy/ivyde/history/latest-milestone/dev.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: Future of Ivy and IvyDE

[Nicolas Lalevée]

Hi there,

I used to be involved, especially in IvyDE, and as many, my build tools and my 
IDE changed (for the IDE I am glad, not for the build tools…). So I had no 
particular interest of doing any maintenance, so much that lost track of the 
last releases of Ivy, where I could help. Many many thanks for those still 
around keep things not completely stalled, especially for those who doesn’t 
know the code base.

For IvyDE, we wanted to retire it some years ago. The community raised some 
interests, so we didn’t proceed. But many years later, the proof is that is not 
maintained. Me too, I think it should be retired now.

For the current IvyDE users, it shouldn’t be a concern that IvyDE is retired as 
an Apache project. You will still be able to continue to use the plugin. The 
released artifacts of the updatesite are archived [1] and won’t disappear. We 
would just announcing officially what in practice happens: it is not maintained 
anymore.

And we tried our best to be opened on how to build and release the plugin and 
the updatesite, it is documented [2]. On my machine which just have Ant and 
Java installed, I just tried and I have been able to build of the updatesite 
with the last release of Ivy without much effort. Doing a proper Apache release 
of that is another subject, there are signatures, at least verify that it 
actually works in a real Eclipse, votes, and so on. And adding features and 
even fixing bugs is a very big step to get involved, it requires a complete 
Eclipse SDK setup. But at least headless, if it is required, I think anybody 
motivated enough should be able to re build it locally, the updatesite too. It 
wouldn’t be as much user friendly as it is today, but you should be able to 
work with your preferred IDE and dependency manager for as long as Eclipse is 
having 4.x versions.

Due to my particular former involvement in IvyDE (I know it well), and my lack 
of involvement in the Ant community lately (I don’t read all mailinglists), if 
you have issues with the build or the code of IvyDE, you can mail on ant-dev@ 
and CC me directly.

That’s for IvyDE. For Ivy, it kind of feels different due to the general usage 
which continues to exists, as we can see people are searching vulnerabilities 
in it.

I am very sorry to read about missed opportunities to help new contributors, I 
didn’t saw them, very sorry about that.

Then, acknowledging that even fixing vulnerabilities is painful to the 
community, I think we should accept to declare that we officially stop the 
maintenance, stop the burden on people involved in the Ant project.

I hear the user community that we should still try our best to keep maintaining 
it, it is still worth it, I understand.

So maybe we can declare a last call. The last maintenance window where only 
vulnerabilities will be fixed. Months ? 6 ? And hope that before that deadline, 
there are some interested parties that are willing to do proper maintenance 
over the project, here at Apache or elsewhere.

Nicolas

[1] https://archive.apache.org/dist/ant/ivyde/updatesite/
[2] https://ant.apache.org/ivy/ivyde/history/latest-milestone/dev.html

> Le 22 août 2023 à 18:02, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> before I get to the actual content of this mail:
> 
> * I'm cross-posting to three lists but I ask you to keep responses to
>  dev@ant only (and join the list if necessary) if you want to respond.
> 
> * what I write is my personal opinion and not shared by the PMC as a
>  whole. The people on the PMC know I'd be writing a mail like this
>  sooner or later, though.
> 
> * this is a discussion, not a vote.
> 
> phew
> 
> I'm not quite sure what I hope to achieve with this email, but I'd like
> to share my thoughts - and raise the awareness of an elephant being in
> the room.
> 
> Over the past year we've had three security vulnerabilities discovered
> in Ivy and it took us much too long to get them fixed. The reason for
> this is there are no people left around who are familiar with the Ivy
> code base. Most of the remaining developers around Ant are not even
> users of Ivy - I know I am not and have never been.
> 
> When it comes to IvyDE things are probably even worse as nobody of us
> uses Eclipse, either. But then again I've not managed to create an
> Eclipse update site for the last two Ivy releases so maybe nobody is
> using IvyDE anymore anyway.
> 
> At least *I* don't see myself digging deeper into the Ivy code base in
> order to fix non-critical bugs. And even for the critical ones I feel we
> are not doing an adequate job. To me it looks as if Ivy and in
> particilar IvyDE are no longer really supported by the Ant project.
> 
> TBH I'm not quite sure what to do about this. Even if people stepped up
> to maintain Ivy, the rest of the Ant devs would probably be unable to
> verify the changes they want to make. At least I certainly am not
> willing to review bigger PRs/patches to a code base I don't understand
> well.
> 
> Personally I 

Re: Java 11 Compatibility Problem

[Nicolas Lalevée]

To be complete on this subject, the pack200 algorithm has been implemented to 
be able to resolve artifacts in an Eclipse updatesite. I don’t know how 
nowadays artifacts are packaged on a « p2 repository », but some documentation 
still exists and doesn’t contain any warnings:
https://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Pack200_Optimization

Nicolas



> Le 10 oct. 2018 à 14:04, Jaikiran Pai  a écrit :
> 
> Hi Jan,
> 
> For end users (of Ivy), the place where pack200 packaging becomes
> visible is when they reference it in their dependencies as noted in our
> doc[1]. So IMO, I think we should probably add a note/warning within our
> documentation than a runtime log/warn message. But I still think, it's a
> bit too early to do that. Maybe we should wait a few more releases of
> Java and see if any alternatives show up?
> 
> [1]
> https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging
> 
> -Jaikiran
> On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote:
>> If I understand Dragans point right, the warning comes when analyzing the 
>> code.
>> Not just running Ivy.
>> So the normal user won't see the warning. Maybe we should implement a 
>> warning?
>> 
>> Jan
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
>>> Gesendet: Mittwoch, 10. Oktober 2018 07:08
>>> An: dev@ant.apache.org
>>> Betreff: Re: Java 11 Compatibility Problem
>>> 
>>> I agree with Stefan, at the moment I recommend ignoring those warnings.
>>> There isn't anything else we can do (other than removing support for
>>> pack200, which isn't a good option).
>>> 
>>> -Jaikiran
>>> 
>>> 
>>> On 10/10/18 9:56 AM, Stefan Bodewig wrote:
 Hi Krzysztof
 
 I'm not actively working on Ivy so take my response with a grain of
 salt.
 
 On 2018-10-09, Dragan, Krzysztof wrote:
 
> Hi,
> scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on
> jdk11 I noticed two problems with this jar.
> These two methods using internal jdk marked for removal and will be
>>> deleted:
>  * class org/apache/ivy/util/FileUtil uses deprecated class
>java/util/jar/Pack200$Unpacker (forRemoval=true)
>  * class org/apache/ivy/util/FileUtil uses deprecated class
>java/util/jar/Pack200 (forRemoval=true)
 For background see https://openjdk.java.net/jeps/336
 
 The Java community has decided to eventually remove support for the
 pack200 format, but it still is there in Java11. Right now this is
 only a warning, it will only become a real problem once the classes
 actually get removed. They do not offer any alternative
>>> implementation
 right now, and may never do (unlike the JAXB case, which is available
 as an external library now).
 
 I am aware of an alternative based on the former Apache Harmony code
 in https://github.com/pfirmstone/pack200 but am unsure about its
>>> state
 - both technically and legally - I very vaguely recall the Pack200
 spec was encumbered with Oracle patents but may be totally wrong.
 
 In Ivy's case the only save option right now was to remove support
>>> for
 pack200 archives and break existing setups that consume such archives
 which seems to be excessive just in order to get rid of a warning.
 
 If yu ask me I'd recommend to live with the warning for now and wait
 for an alternative to the class library's pack200 classes to become
 available - which hopefully happens before the Java version removing
 support gets released.
 
 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

Re: ant git commit: Check spelling

[Nicolas Lalevée]

> [1] https://github.com/apache/ant/pull/66/files
> [2]
> https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506 
> <https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506>

At the *first* line of the diff presented on github, I can tell the commit is 
not only about check spelling.

Not knowing if we have the same presentation, let’s be precise:
https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506#diff-9ad784be5493fb9473c8d4e8a26aadedL25
 
<https://github.com/apache/ant/commit/54b6df2f44c5cb4f9573f99330c2d2908f1bf506#diff-9ad784be5493fb9473c8d4e8a26aadedL25>

Nicolas

> 
> -Jaikiran
> 
> 
> On 11/09/18 12:17 PM, Gintautas Grigelionis wrote:
>> How was this different from PR #66?
>> 
>> Gintas
>> 
>> On Tue, 11 Sep 2018 at 06:55, Jaikiran Pai  wrote:
>> 
>>> Things haven't changed (nor do I expect any changes anymore). To say the
>>> least - it's followed the same pattern:
>>> 
>>> - do changes like these
>>> 
>>> - when requested not to do such changes, argue over it and move it to
>>> some abstract discussion
>>> 
>>> - then give an impression it won't be repeated
>>> 
>>> - few days down the line push changes like these and repeat the whole
>>> cycle again.
>>> 
>>> Although I stay silent with these commits these days it's because I have
>>> nothing good or new to say about this behaviour and am fully exhausted
>>> with this exercise to the extent that I just delete such commit
>>> notifications instead of reviewing them, to avoid it ruining any energy
>>> I might have to contribute anything in my spare time.
>>> 
>>> Committer rights is a privilege as well as a responsibility, but this
>>> behaviour is nothing but an abuse of it and no different than being a
>>> troll.
>>> 
>>> -Jaikiran
>>> 
>>> 
>>> On 10/09/18 5:12 AM, Nicolas Lalevée wrote:
>>>> I have been away from the project out of boredom. Still curious, I came
>>> to read some emails. It seems things didn’t changed much: yet another
>>> unreadable commit with a log which doesn’t indicate what it actually do.
>>>> 
>>>>> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
>>>>> 
>>>>> Repository: ant
>>>>> Updated Branches:
>>>>> refs/heads/master fde6b0e94 -> 54b6df2f4
>>>>> 
>>>>> 
>>>>> Check spelling
>>>>> 
>>>>> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
>>>>> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
>>>>> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
>>>>> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
>>>>> 
>>>>> Branch: refs/heads/master
>>>>> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
>>>>> Parents: fde6b0e
>>>>> Author: Gintas Grigelionis 
>>>>> Authored: Sat Sep 8 22:12:24 2018 +0200
>>>>> Committer: Gintas Grigelionis 
>>>>> Committed: Sun Sep 9 09:07:18 2018 +0200
>>>>> 
>>>>> --
>>>>> .../checkstyle-frames-sortby-check.xsl  | 194
>>> +--
>>>>> src/etc/jdepend-frames.xsl  |  18 +-
>>>>> src/etc/jdepend.xsl |  48 +++--
>>>>> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
>>>>> .../taskdefs/optional/unix/symlink.xml  |  78 
>>>>> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
>>>>> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
>>>>> src/etc/testcases/types/assertions.xml  | 178 +
>>>>> src/etc/testcases/types/selectors.xml   | 104 +-
>>>>> src/main/org/apache/tools/ant/Diagnostics.java  |   2 +-
>>>>> src/main/org/apache/tools/ant/taskdefs/Ant.java |   2 +-
>>>>> .../org/apache/tools/ant/taskdefs/Checksum.java |   2 +-
>>>>> .../org/apache/tools/ant/taskdefs/Exec.java |   2 +-
>>>>> .../org/apache/tools/ant/taskdefs/SignJar.java  |   2 +-
>>>>> src/main/org/apache/tools/ant/taskdefs/Zip.java |   2 +-
>>>>> .../ant/taskdefs/condition/IsReachable.java |   4 +-
>>>>> .../optional/ejb/GenericDe

Re: ant git commit: Check spelling

[Nicolas Lalevée]

I have been away from the project out of boredom. Still curious, I came to read 
some emails. It seems things didn’t changed much: yet another unreadable commit 
with a log which doesn’t indicate what it actually do.


> Le 9 sept. 2018 à 09:09, gin...@apache.org a écrit :
> 
> Repository: ant
> Updated Branches:
>  refs/heads/master fde6b0e94 -> 54b6df2f4
> 
> 
> Check spelling
> 
> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/54b6df2f
> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/54b6df2f
> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/54b6df2f
> 
> Branch: refs/heads/master
> Commit: 54b6df2f44c5cb4f9573f99330c2d2908f1bf506
> Parents: fde6b0e
> Author: Gintas Grigelionis 
> Authored: Sat Sep 8 22:12:24 2018 +0200
> Committer: Gintas Grigelionis 
> Committed: Sun Sep 9 09:07:18 2018 +0200
> 
> --
> .../checkstyle-frames-sortby-check.xsl  | 194 +--
> src/etc/jdepend-frames.xsl  |  18 +-
> src/etc/jdepend.xsl |  48 +++--
> src/etc/testcases/taskdefs/exec/exec.xml|   4 +-
> .../taskdefs/optional/unix/symlink.xml  |  78 
> .../optional/xml/endpiece-noSchema-invalid.xml  |   9 +-
> .../taskdefs/optional/xml/endpiece-noSchema.xml |   7 +-
> src/etc/testcases/types/assertions.xml  | 178 +
> src/etc/testcases/types/selectors.xml   | 104 +-
> src/main/org/apache/tools/ant/Diagnostics.java  |   2 +-
> src/main/org/apache/tools/ant/taskdefs/Ant.java |   2 +-
> .../org/apache/tools/ant/taskdefs/Checksum.java |   2 +-
> .../org/apache/tools/ant/taskdefs/Exec.java |   2 +-
> .../org/apache/tools/ant/taskdefs/SignJar.java  |   2 +-
> src/main/org/apache/tools/ant/taskdefs/Zip.java |   2 +-
> .../ant/taskdefs/condition/IsReachable.java |   4 +-
> .../optional/ejb/GenericDeploymentTool.java |   4 +-
> .../optional/ejb/JonasDeploymentTool.java   |   4 +-
> .../tools/ant/taskdefs/optional/jsp/WLJspc.java |   2 +-
> .../junitlauncher/JUnitLauncherTask.java|   2 +-
> .../optional/junitlauncher/TestRequest.java |   8 +-
> .../tools/ant/taskdefs/optional/net/FTP.java|   4 +-
> .../optional/net/FTPTaskMirrorImpl.java |   4 +-
> .../tools/ant/taskdefs/optional/vss/MSVSS.java  |   2 +-
> .../ant/taskdefs/optional/vss/MSVSSCHECKIN.java |   2 +-
> .../org/apache/tools/ant/types/XMLCatalog.java  |   2 +-
> .../org/apache/tools/ant/util/FileUtils.java|   2 +-
> .../org/apache/tools/ant/util/ProxySetup.java   |   2 +-
> .../org/apache/tools/zip/ZipOutputStream.java   |   4 +-
> src/script/antenv.cmd   |   2 +-
> src/script/envset.cmd   |   2 +-
> src/tests/antunit/taskdefs/echoxml-test.xml |   2 +-
> .../apache/tools/ant/taskdefs/UnzipTest.java|   2 +-
> .../ant/taskdefs/optional/TraXLiaisonTest.java  |   2 +-
> .../tools/ant/util/ReaderInputStreamTest.java   |   4 +-
> 35 files changed, 350 insertions(+), 362 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant/blob/54b6df2f/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> --
> diff --git a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl 
> b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> index 060f878..1f02b90 100644
> --- a/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> +++ b/src/etc/checkstyle/checkstyle-frames-sortby-check.xsl
> @@ -22,7 +22,7 @@
> -->
> 
> 
> -
> +
> 
> 
> 
> @@ -43,7 +43,7 @@
> 
> 
> 
> -
> +
> 
> 
> 
> @@ -76,15 +76,15 @@
> 
> 
> 
> 
> 
> 
> 
>  
> +Generates the navigation bar.
> +-->
> 
> 
> 
> @@ -100,13 +100,13 @@
> 
> 
> 
> - 
> +
> 
> 
> 
>  
> +-->
> 
> 
> 
> @@ -120,13 +120,13 @@
> 
> 
> 
> - 
> +
> 
> 
> 
> 
> 
> 
> @@ -157,7 +157,7 @@
> Generates the data rows for the current check module.
> Ignores errors in the current file from other modules.
> @param node the file with the errors
> -@param filter full qualified module name 
> +@param filter full qualified module name
> -->
> 
> 
> @@ -180,68 +180,68 @@
> 
> 
> 
> - Generates the CSS with the layout instructions.
> Generated so this XSL is the single source of the whole report.
> -->
> 
> -body { 
> +body {
>   font:normal 80% arial,helvetica,sanserif;
> -  color: black; 
> -  background-color: white; 
> -  margin: 0; 
> -  padding: 1em; 
> +  color: 

Re: Jenkins-Builds failing

[Nicolas Lalevée]

> Le 24 juil. 2018 à 08:38, Jan Matèrne (jhm)  a écrit :
> 
> "Looks like someone called 'hibou' restricted the job to themselves. (See 
> screenshot attached to this ticket)"
> 
> This was a "run as hibou" configuration.
> 
> @Nicolas: What was the reason to add that? Is it required?

For some reason, this was the only way to make job dependencies work: once 
IvyDE is built, it will trigger the build of the updatesite. When I setup it, 
there was some right issues, the job trigger was done as ‘anonymous’, so I 
forced the job to run as 'me'.

Nicolas

> 
> 
> Gavin removed that part and I could add the https.protocols=TLSv1.2 parameter.
> Job restarted.
> 
> 
> Jan
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
>> Gesendet: Sonntag, 22. Juli 2018 12:54
>> An: 'Ant Developers List'
>> Betreff: AW: Jenkins-Builds failing
>> 
>> Checked by myself that a PMC chair could do (AFAIK).
>> Opened a ticket
>> https://issues.apache.org/jira/browse/INFRA-16799
>> 
>> Jan
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>>> Gesendet: Sonntag, 22. Juli 2018 10:48
>>> An: Ant Developers List
>>> Betreff: Re: Jenkins-Builds failing
>>> 
>>> Should we ask infra if nobody else knows about Jenkins authorization?
>>> 
>>> Gintas
>>> 
>>> On Fri, 20 Jul 2018 at 11:26, Jan Matèrne (jhm) 
>>> wrote:
>>> 
 Neither do I.
 
 Jan
 
> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Freitag, 20. Juli 2018 10:15
> An: dev@ant.apache.org
> Betreff: Re: Jenkins-Builds failing
> 
> Now that I checked the job's logs, I think that's true. We had
> this issue in Ant too (not really against Maven repos, but HTTPS
> hosted Apache infrastructure). I tried setting that property in
> the job, but I too don't have the necessary authorization. I
>> don't
> remember if I ever had those permissions or if it's something
>> that
> changed with the recent Jenkins upgrade.
> 
> -Jaikiran
> 
> 
> On 20/07/18 1:34 PM, Gintautas Grigelionis wrote:
>> My hypothesis is that Java 7 must have TLS version forced to
>> 1.2
>> in order to avoid protocol errors when downloading new binaries
>> from Maven Central because earlier versions are disabled [1]
>> (and TLS 1.0 is the default in Java 7).
>> 
>> Gintas
>> 
>> 1.
>> https://blog.pcisecuritystandards.org/are-you-ready-for-30-
>> june-
>>> 20
>> 18-
> s
>> ayin-goodbye-to-ssl-early-tls
>> 
>> On Fri, 20 Jul 2018 at 09:31, Jaikiran Pai
>> 
> wrote:
>> 
>>> Haven't checked the job, but why is this system property
>>> required
>>> to be set?
>>> 
>>> -Jaikiran
>>> 
>>> 
>>> On 20/07/18 12:51 AM, Gintautas Grigelionis wrote:
 I'd like to add a Java option to Ivy builds
 -Dhttps.protocols=TLSv1.2
>>> but I
 get
 This job's current authorization strategy does not permit
>>> gintas
 to
>>> modify
 the job configuration
 
 Gintas
 
 On Tue, 3 Jul 2018 at 19:09, Gintautas Grigelionis <
>>> g.grigelio...@gmail.com>
 wrote:
 
> Ant nightly is stuck on archiving for 30 hours now.
> It should be escalated, I believe that could have something
> to do with
>>> the
> last upgrade of Jenkins.
> 
> Gintas
> 
> On Mon, 2 Jul 2018 at 14:18, Jan Matèrne 
>>> wrote:
> 
>> Several of our Jenkins builds are failing:
>> 
>> 
>> 
>> IvyDE:
>> 
>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/
>> 
>> 
> 
>> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/cons
>> ole
>> 
>> Can't get
>> 
>> 
>>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-
>>> 3.4
>>> .2-
> 2
>>> 0130208
>> 151217/wtp4x-R-3.4.2-20130208151217.zip
>> <
>>> http://download.eclipse.org/webtools/downloads/drops/R3.4.2/R-
>>> 3.4
>>> .2-
> 2
>>> 0130208151217/wtp4x-R-3.4.2-20130208151217.zip
>> to
>> 
>> 
>>> /home/jenkins/jenkins-
>> slave/workspace/IvyDE/dependencies/wtp4x-
>>> R-
> 3.4.
>>> 2-20130
>> 208151217.zip
>> 
>> 
>> 
>> The source URL gives a 404.
>> 
>> 
>> 
>> 
>> 
>> AntLib - AntUnit
>> 
>> https://builds.apache.org/view/A/view/Ant/job/AntLib-
>> antunit
>> /
>> 
>> 
>> 
>>> https://builds.apache.org/view/A/view/Ant/job/AntLib-
> antunit/lastBuil
>>> d/conso
>> le
>> 
>> [ivy:resolve]   Server access error at url
>> 
>> 

Re: Testing IvyDE

[Nicolas Lalevée]

So the crash of Eclipse occurs also with Java 8. But I have managed to make it 
crash with other kind of Eclipse console, so this is probably not related to 
IvyDE.

While testing I have found a little bug, some context menu doing nothing, most 
probably not a regression. Still, I have fixed it in master.
And I have fixed some test projects.

It would be great if somebody could do some testing on Windows, since I tested 
on MacOS.

Then for me it is all good.

Nicolas

PS: since now I am mainly using Intellij, it was a bit of pain to get back into 
Eclipse. But this was a joy to use IvyDE, which is way better integrated than 
IvyIDEA :)

> Le 15 juil. 2018 à 21:06, Nicolas Lalevée  a 
> écrit :
> 
> I have fixed the build, now relying on more recent dependencies. The 
> updatesite built by Jenkins is now up to date.
> 
> I have started to do some test, but there are some crashes, the jvm of 
> Eclipse is crashing on clearing the Ivy console for instance. I bet this is 
> more due to the fact that I am running with Java 10. I’ll try to run it with 
> a lower Java version and redo the tests.
> 
> Nicolas
> 
>> Le 4 juil. 2018 à 14:01, Jaikiran Pai  a écrit :
>> 
>> 
>> On 01/07/18 6:35 PM, Nicolas Lalevée wrote:
>>> Le 28 juin 2018 à 08:41, Jaikiran Pai  a écrit :
>>>> 
>>>> On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
>>>>> Since there is a work around (hitting refresh after resolve) and it is an 
>>>>> RC, we could ship it like that and fix it later. But due to the automatic 
>>>>> update via the update site, I bet most users will update even if it is an 
>>>>> RC. So I am not sure what I should vote. So I vote -0 for me for now.
>>>> I was reserving my vote just for this reason. I don't use Eclipse so I 
>>>> wanted to see if someone more familiar with it has an opinion about this 
>>>> bug. You are right that it's going to end up affecting everyone once we 
>>>> release this. Given that the purpose of this release is revive this 
>>>> project a bit and not break setups where things are working fine and the 
>>>> fact that this will end up being an annoying kind of workaround (having to 
>>>> hit refresh after resolve), I don't see rushing this release without 
>>>> fixing this issue serves any purpose.
>>>> 
>>>> So I'll vote a -1 on this now. I know we have gone through 3 voting rounds 
>>>> for this release, so thank you everyone for being patient and testing out 
>>>> the binaries. I'll file this issue in JIRA and hopefully spend some time 
>>>> in Eclipse this weekend to try and sort this out.
>>> I have found the issue and pushed a fix.
>> Thank you.
>>> 
>>> I am then worried that the master is not well tested nor used after the big 
>>> cleanups.
>> Yes, I agree.
>> 
>>> 
>>> So I suggest we do a little testing now of the master.
>>> 
>>> To help with that, there is a folder in the IvyDE project which contains 
>>> projects ready to be imported into Eclipse, they are samples of many 
>>> different configurations which should be supported
>> I'll test some of these out during the week.
>> 
>> -Jaikiran
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Testing IvyDE

[Nicolas Lalevée]

I have fixed the build, now relying on more recent dependencies. The updatesite 
built by Jenkins is now up to date.

I have started to do some test, but there are some crashes, the jvm of Eclipse 
is crashing on clearing the Ivy console for instance. I bet this is more due to 
the fact that I am running with Java 10. I’ll try to run it with a lower Java 
version and redo the tests.

Nicolas

> Le 4 juil. 2018 à 14:01, Jaikiran Pai  a écrit :
> 
> 
> On 01/07/18 6:35 PM, Nicolas Lalevée wrote:
>> Le 28 juin 2018 à 08:41, Jaikiran Pai  a écrit :
>>> 
>>> On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
>>>> Since there is a work around (hitting refresh after resolve) and it is an 
>>>> RC, we could ship it like that and fix it later. But due to the automatic 
>>>> update via the update site, I bet most users will update even if it is an 
>>>> RC. So I am not sure what I should vote. So I vote -0 for me for now.
>>> I was reserving my vote just for this reason. I don't use Eclipse so I 
>>> wanted to see if someone more familiar with it has an opinion about this 
>>> bug. You are right that it's going to end up affecting everyone once we 
>>> release this. Given that the purpose of this release is revive this project 
>>> a bit and not break setups where things are working fine and the fact that 
>>> this will end up being an annoying kind of workaround (having to hit 
>>> refresh after resolve), I don't see rushing this release without fixing 
>>> this issue serves any purpose.
>>> 
>>> So I'll vote a -1 on this now. I know we have gone through 3 voting rounds 
>>> for this release, so thank you everyone for being patient and testing out 
>>> the binaries. I'll file this issue in JIRA and hopefully spend some time in 
>>> Eclipse this weekend to try and sort this out.
>> I have found the issue and pushed a fix.
> Thank you.
>> 
>> I am then worried that the master is not well tested nor used after the big 
>> cleanups.
> Yes, I agree.
> 
>> 
>> So I suggest we do a little testing now of the master.
>> 
>> To help with that, there is a folder in the IvyDE project which contains 
>> projects ready to be imported into Eclipse, they are samples of many 
>> different configurations which should be supported
> I'll test some of these out during the week.
> 
> -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] Release Ant 1.10.5 based on RC1

[Nicolas Lalevée]

+1


> Le 10 juil. 2018 à 11:55, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> I've created a new release candidate for 1.10.5 with a few bug fixes and
> and the "single source executable" feature for Java11.
> 
> git tag: ANT_1.10.5_RC1
> on commit: c0848d2c6
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
> revision: 28015
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-1035/org/apache/ant/
> 
> This Vote will be open at least for 72 hours and close no earlier than
> 2018-07-13 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] Release Ant 1.9.13 based on RC1

[Nicolas Lalevée]

+1

> Le 10 juil. 2018 à 11:56, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> I've created a new release candidate for 1.9.13 with a few bug fixes.
> 
> git tag: ANT_1.9.13_RC1
> on commit: e7a4d8683
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
> revision: 28014
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-1034/org/apache/ant/
> 
> This Vote will be open at least for 72 hours and close no earlier than
> 2018-07-13 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: ant git commit: Unbreak tests

[Nicolas Lalevée]

I have re done the revert and merge locally, and compared the diff between my 
local banches and the remote one. I had only diffs due to my editor 
automatically removing trailing space on empty lines, and I had to figure out 
what the status of the apt tasks (and indeed it doesn’t need to be merged back 
into master).

I have not tested as much as you have, but I have tested the revert, merge and 
conflicts resolve, and it is ok for me.

So thank you for you detailed mail about what you did. I think we should have 
that rule: in case of a commits which generates a lot of diff, share the 
commands which generated these diffs. Thus anyone can check the rationale of 
the commands and make the diff between local and remote.

Nicolas

> Le 7 juil. 2018 à 14:53, Jaikiran Pai  a écrit :
> 
> Here's a status of the current state of upstream repo branches "master" and 
> "1.9.x". But before getting to it, I would like to state that I really had no 
> pleasure in doing these reverts. I really do mean it. I wish we had never 
> ended up in this situation (and hopefully will never again), but I do believe 
> reverting this was the right decision.
> 
> 1.9.x branch:
> 
> - Before starting the revert operation, the latest commit on this branch was 
> 7df9120ebc1f9bee97a6a1a47f0a5fda986e4ab0 which was the trailing whitespace 
> commit.
> - Reverted that commit by issuing a "git revert 
> 7df9120ebc1f9bee97a6a1a47f0a5fda986e4ab0"
> - Did a clean build (just compilation and jar generation, no test cases were 
> run locally)
> - Finally to make sure I didn't introduce any unnecessary changes/problems of 
> my own in this efforts, I compared the latest commit (which was the revert 
> commit) against the 7df9120ebc1f9bee97a6a1a47f0a5fda986e4ab0 commit's parent 
> on 1.9.x, b2da27513c7806357bf146bde44b3cc469757122 using the following 
> command:
> 
> git diff b2da27513c7806357bf146bde44b3cc469757122 
> 9b1b8dbbc6e9aa98922da28683f3773f586811e5
> 
> This returned empty (which is a good thing)
> 
> Pushed this state to upstream 1.9.x branch.
> 
> master branch:
> 
> This was a bit more complicated than the 1.9.x branch, given merge commits 
> plus additional master only commits that had happened on this branch between 
> the trailing whitespace commit, plus the fact that the trailing whitespace 
> commit touched extremely large number of files.
> 
> - Before starting the revert on this branch, the latest commit on it was 
> 4ce54bf3b6c521af9c8db3229df5cd8b3199a3b2.
> - The trailing whitespace commit was done before that above commit and was 
> 2f64e0b51c295960cb15aa77c7c1f447b2518e14. There were some other unrelated 
> commits between these 2 commits.
> - Reverted that commit by issuing:
> 
> git revert 2f64e0b51c295960cb15aa77c7c1f447b2518e14
> 
> Needed to sort out merge conflicts with the following files:
> Unmerged paths:
>   (use "git reset HEAD ..." to unstage)
>   (use "git add ..." to mark resolution)
> 
> both modified:   src/etc/testcases/taskdefs/cvspass.xml
> both modified:   src/etc/testcases/taskdefs/delete.xml
> both modified:   src/etc/testcases/taskdefs/jar.xml
> both modified: src/etc/testcases/taskdefs/optional/pvcs.xml
> both modified: 
> src/etc/testcases/taskdefs/optional/xml/endpiece-ns-no-location.xml
> both modified: src/etc/testcases/taskdefs/optional/xml/endpiece.xml
> both modified:   src/etc/testcases/taskdefs/typedef.xml
> both modified:   src/tests/antunit/taskdefs/copy-test.xml
> both modified:   src/tests/antunit/taskdefs/get-test.xml
> 
> Manually fixed those conflicts and completed the revert.
> 
> - Did one round of local clean build to make sure things were fine.
> - At this point, the revert was complete, but there remained one more step to 
> merge 1.9.x branch into master.
> - Issued "git merge 1.9.x" (where 1.9.x was the branch which included the 
> fully reverted state)
> - Merge conflicts had to be resolved in the following files:
> 
> Unmerged paths:
>   (use "git add/rm ..." as appropriate to mark resolution)
> 
> both modified:   src/etc/poms/ant-javamail/pom.xml
> both modified:   src/etc/poms/ant-swing/pom.xml
> both modified:   src/etc/poms/ant-testutil/pom.xml
> both modified:   src/etc/testcases/filters/build.xml
> both modified: src/etc/testcases/taskdefs/conditions/antversion.xml
> both modified:   src/etc/testcases/taskdefs/delete.xml
> both modified:   src/etc/testcases/taskdefs/java.xml
> both modified: src/etc/testcases/taskdefs/optional/pvcs.xml
> both modified: src/etc/testcases/taskdefs/optional/script.xml
> both modified: src/tests/antunit/core/extension-point-test.xml
> deleted by us:   src/tests/antunit/taskdefs/apt-test.xml
> both modified:   src/tests/antunit/taskdefs/get-test.xml
> both modified:   src/tests/antunit/taskdefs/javac-test.xml
> both modified:   src/tests/antunit/taskdefs/tar-test.xml
> both modified: src/tests/antunit/taskdefs/taskdef-antlib-test.xml
> 
> 

Testing IvyDE

[Nicolas Lalevée]

Le 28 juin 2018 à 08:41, Jaikiran Pai  a écrit :
> 
> 
> On 27/06/18 10:12 PM, Nicolas Lalevée wrote:
>> Since there is a work around (hitting refresh after resolve) and it is an 
>> RC, we could ship it like that and fix it later. But due to the automatic 
>> update via the update site, I bet most users will update even if it is an 
>> RC. So I am not sure what I should vote. So I vote -0 for me for now.
> I was reserving my vote just for this reason. I don't use Eclipse so I wanted 
> to see if someone more familiar with it has an opinion about this bug. You 
> are right that it's going to end up affecting everyone once we release this. 
> Given that the purpose of this release is revive this project a bit and not 
> break setups where things are working fine and the fact that this will end up 
> being an annoying kind of workaround (having to hit refresh after resolve), I 
> don't see rushing this release without fixing this issue serves any purpose.
> 
> So I'll vote a -1 on this now. I know we have gone through 3 voting rounds 
> for this release, so thank you everyone for being patient and testing out the 
> binaries. I'll file this issue in JIRA and hopefully spend some time in 
> Eclipse this weekend to try and sort this out.

I have found the issue and pushed a fix.

I am then worried that the master is not well tested nor used after the big 
cleanups. Two big bugs were raised during the release process.

So I suggest we do a little testing now of the master.

To help with that, there is a folder in the IvyDE project which contains 
projects ready to be imported into Eclipse, they are samples of many different 
configurations which should be supported:
https://github.com/apache/ant-ivyde/tree/master/test 
<https://github.com/apache/ant-ivyde/tree/master/test>
And the last build can be installed from an update site built there:
https://builds.apache.org/view/A/view/Ant/job/IvyDE-updatesite/ 
<https://builds.apache.org/view/A/view/Ant/job/IvyDE-updatesite/>

Nicolas

Re: FileUtils.normalize/isLeadingPath have bitten me

[Nicolas Lalevée]

At my first read of the code I wondered if paths ending with slash are properly 
handled in every case. After more careful reading, it is seems ok. Maybe some 
unit tests about it would be nice, just to be sure.

Then, about tackling the bug, I am on the same page as you both. It looks good 
to me.

Nicolas

> Le 1 juil. 2018 à 11:27, Stefan Bodewig  a écrit :
> 
> On 2018-06-28, Stefan Bodewig wrote:
> 
>> On 2018-06-28, Jaikiran Pai wrote:
> 
>>> Which then makes me wonder - in the context of this specific
>>> untar/expand/unzip issue, should we probably be using a different
>>> custom very specific logic (which relies on canonical files and
>>> getParent()) instead of a call to isLeadingPath()?
> 
>> Probably. I used isLeadingPath because it has been already there - and )
>> simply didn't realize it wouldn't do what I expected it to.
> 
> I decided to "fix" isLeadingPath for this edge case and add a method
> using canonical paths instead - and use that in unzip and friends.
> 
> Please have a look at the proposed solution, I won't close the Bugzilla
> issue before we have agreed this is the proper fix.
> 
> 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] Release 2.3.0-rc1 of Apache IvyDE

[Nicolas Lalevée]

Everything looks good apart from the bug Ross reported which I have been able 
to reproduce. And it seems pretty consistent, not very random. And I see no 
error in Eclipse’s log.

I have been able to reproduce it with the Eclipse version:
Version: Neon.3 Release (4.6.3)
Build id: 20170314-1500

I am also using java 10, which is a bit tricky to make it run smoothly due to 
the modules thing. Maybe it is related.

And the project I tried to build in Eclipse is the Ivy project, which is about 
just an ivy.xml and a version.properties.

I know that the IvyDE code which is triggering the update of the classpath is 
tricky, it is quite sensible, partly due to the non trivial Eclipse APIs. Maybe 
with the last « cleanup » the resolve process has been messed up, and somehow 
it still work in the refresh case.

Since there is a work around (hitting refresh after resolve) and it is an RC, 
we could ship it like that and fix it later. But due to the automatic update 
via the update site, I bet most users will update even if it is an RC.
So I am not sure what I should vote.

So I vote -0 for me for now.

Nicolas

> Le 25 juin 2018 à 07:52, Jaikiran Pai  a écrit :
> 
> I'm initiating a newer vote mail for 2.3.0-rc1 release of Apache IvyDE 
> project. This addresses the blocker issue that Nicolas identified, the last 
> time a vote was initiated for this version.
> 
> The newly updated tag is here 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=tag;h=refs/tags/2.3.0-rc1
>  with sha1 3581a61ec159ede16005f36e58e5e258d32090fa
> 
> You can download the distribution from this URL: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/ at rev 27709
> 
> The Eclipse p2 repository is here: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806251008-RELEASE/
>  at rev 27707
> 
> The 2.3.0-rc1 release of IvyDE consists of the following changes:
> 
> * FIX: xml bomb in workspace causes hang in Ivy code during Search or 
> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
> * FIX: Deadlock in classpath container 
> (https://issues.apache.org/jira/browse/IVYDE-361)
> * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362)
> * FIX: User-selected configurations not checked in the viewer 
> (https://issues.apache.org/jira/browse/IVYDE-378)
> * FIX: Fix ClassCastException 
> (https://issues.apache.org/jira/browse/IVYDE-386)
> * FIX: Fix the issue where the IvyDE preferences couldn't be saved 
> (https://issues.apache.org/jira/browse/IVYDE-388)
> 
> * NEW: Support for OSGi 'Bundle-Classpath' directive
> * NEW: Basic support for the workspace resolver to find OSGi bundles managed 
> by Ivy in the workspace
> * NEW: Support for storing credentials securely
> 
> 
> Do you vote for the release of these binaries?
> 
> -Jaikiran
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 

Re: .git(modules|attributes|ignore) files in source dists?

[Nicolas Lalevée]

> Le 19 juin 2018 à 16:42, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> when I set up the build for AntUnit I realized the source tarball didn't
> contain the git config files that are part of the source repo and
> changed the antlibs-common module to include them (they are part of
> Ant's defaultexcludes for DirectoryScanner).
> 
> Later it dawned on me this may not be a good idea as we don't include
> anything else that is SCM related either, so maybe not including the
> files has been the correct choice all along.
> 
> Any opinions on whether we should include or exclude them?

My preference is that the packaged sources should be as close as possible to a 
direct checkout from the SCM. I like very much the idea that packaging is about 
calling git archive. It is then a no brainer, if it can build from a checkout, 
then it can build from a source archive.

I don’t directly answer your question though.
I would say then that we should (and not must) include them.

Nicolas


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

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Nicolas Lalevée]

First, thank you very much Jaikiran to make this release happen.

So checksum, signatures, installation, build, resolve on projects went well. 
But I have found a regression: global preferences cannot be saved anymore.
cf https://issues.apache.org/jira/browse/IVYDE-388 


Looking at the code, indeed it cannot work.
https://github.com/apache/ant-ivyde/blob/c92ed1b9247642dfaa67e5cf84528cfa20931c47/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/ui/preferences/PreferenceConstants.java#L136
 


I think it deserves to be fixed before being consumed by end users.
So -1 for me.

Also, it will be better to mention the sha1 of the git tag and the svn revision 
of the artifact in dist. We should update the release instructions to not 
forgot it, like I have done for the last release of Ivy:
https://github.com/apache/ant-ivy/blob/master/asciidoc/dev/makerelease.adoc#11-call-for-a-vote-to-approve-the-release
 


Nicolas

> Le 17 juin 2018 à 08:45, Jaikiran Pai  a écrit :
> 
> This is a newer vote mail that I'm initiating for the 2.3.0-rc1 release of 
> IvyDE.
> 
> The newly updated tag is here 
> https://git1-us-west.apache.org/repos/asf?p=ant-ivyde.git;a=commit;h=refs/tags/2.3.0-rc1
> 
> You can download the distribution from this URL: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/2.3.0-rc1/
> 
> The Eclipse p2 repository is here: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivyde-2.3.0.rc1-201806171016-RELEASE/
> 
> The 2.3.0-rc1 release of IvyDE consists of the following changes:
> 
> * FIX: xml bomb in workspace causes hang in Ivy code during Search or 
> Synchronize operations (https://issues.apache.org/jira/browse/IVYDE-354)
> * FIX: Deadlock in classpath container 
> (https://issues.apache.org/jira/browse/IVYDE-361)
> * FIX: Typo in IvyResolveJob (https://issues.apache.org/jira/browse/IVYDE-362)
> * FIX: User-selected configurations not checked in the viewer 
> (https://issues.apache.org/jira/browse/IVYDE-378)
> * FIX: Fix ClassCastException 
> (https://issues.apache.org/jira/browse/IVYDE-386)
> 
> * NEW: Support for OSGi 'Bundle-Classpath' directive
> * NEW: Basic support for the workspace resolver to find OSGi bundles managed 
> by Ivy in the workspace
> * NEW: Support for storing credentials securely
> 
> 
> Do you vote for the release of these binaries?
> 
> 
> -Jaikiran
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 

Re: [VOTE] Apache IvyDE 2.3.0-rc1 release

[Nicolas Lalevée]

Just a quick comment on the mirror url not working. The page is telling "The 
requested file or directory is not on the mirrors. »
And indeed, the artifacts are not published yet to the final location, the 
release is not accepted yet.

Nicolas



> Le 14 juin 2018 à 10:19, Gintautas Grigelionis  a 
> écrit :
> 
> 2018-06-14 8:15 GMT+02:00 Stefan Bodewig  >:
> 
>> On 2018-06-13, Gintautas Grigelionis wrote:
>> 
>>> org.xml.sax.SAXParseException; systemId:
>>> http://ant.apache.org/ivy/ivyde/updatesite/p2-mirrors--xml.
>> cgi?path=ivyde-2.3.0.rc1-201806132023-RELEASE=
>> se=1=xml;
>>> lineNumber: 39; columnNumber: 3; Element type "link" lack matching end
>> tag
>>> "".
>> 
>> When I follow the link above, I get an HTML page which is not
>> well-formed XML, so the messages are to be expected.
>> 
>> BTW, wherever thos link comes from, it would be good if it used https
>> rather than http.
> 
> 
> I followed the link to the source in svn
> 
> https://svn.apache.org/viewvc/ant/site/ivyde/production/updatesite/p2-mirrors--xml.cgi?view=markup
>  
> 
> 
> #!/bin/sh
> # Wrapper script around mirrors.cgi script
> # (we must change to that directory in order for python to pick up the
> # python includes correctly)
> cd /www/www.apache.org/dyn/mirrors 
> /www/www.apache.org/dyn/mirrors/mirrors.cgi 
>  $
> 
> It seems that mirrors.cgi bails out, since it redirects to a (correct
> HTML-wise, incorrect XML-wise) page containing
> 
> The requested file or directory is *not* on the mirrors.
> 
> I wonder whether there is some documentation available on what output
> the CGI script (and corresponding HTML template?) should produce.
> Apparently, they do not work as intended since last changes were made
> 6 years ago.
> 
> Gintas

Re: Migrating Ivy and IvyDE site to asciidoc

[Nicolas Lalevée]

> Le 7 mai 2018 à 08:24, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> 2018-04-23 15:25 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:
> 
>> One page I am worried about is the main page [2]. I am not sure there are
>> some sane asciidoc directives to render something similar. If you already
>> have ideas, please share. If I remember correctly there is directive to
>> blindly render content, which could be html, as a fall back.
>> 
> 
> I'd like to see more SVG :-) So, how about replacing the four images
> (download, demo, manual, forum)? Then, style them as a flexbox for
> responsivity.

The issue isn’t about the format of the image but about the layout of the page. 
If you have some proof of concept of how a home page can be done in asciidoc, 
please share, in a gist of whatever.

Nicolas


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

Re: ant git commit: Inline buildfile names, make search easier

[Nicolas Lalevée]

> Le 30 avr. 2018 à 11:58, Stefan Bodewig  a écrit :
> 
> On 2018-04-30, Jaikiran Pai wrote:
> 
>> Changes like these are random personal preferences.
> 
> Right.
> 
>> The fact that these are being done even after the mail discussions we
>> recently had, indicates that the request to not do such changes have
>> been ignored. This is going down the route of a being some kind of a
>> personal individual hobby project. So I'm just going to stop bothering
>> looking into these commits anymore and just stay away from them and
>> stop sending this frustrated and rude sounding mails.
> 
> I must admit I share your frustration and have to thank you for voicing
> it when I didn't dare to do.
> 
> TBH I've given up on giving the changes to tests more that a cursory
> look and hoping "this one is going to be the last one".

Same here.

Nicolas


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

Re: Migrating Ivy and IvyDE site to asciidoc

[Nicolas Lalevée]

> Le 23 avr. 2018 à 17:23, Matt Sicker <boa...@gmail.com> a écrit :
> 
> For what it's worth, I used pandoc <https://pandoc.org> to automate most of
> the conversion from xdoc and markdown to asciidoc over at Log4j. The only
> struggles I had with that tool are that it supports HTML, not xdoc, so it
> doesn't understand the section/subsection/etc. tags, and it doesn't output
> the correct syntax for nested tables (need to convert | to ! in a nested
> table).

Very interesting.
I won’t have time to investigate if it is useful here, since xooki2ascii is 
working. But if pandoc can do a better job, I am all ears.
At least next time I’ll probably start with that.

Nicolas

> 
> On 23 April 2018 at 08:25, Nicolas Lalevée <nicolas.lale...@hibnet.org>
> wrote:
> 
>> Hi,
>> 
>> I would like to go forward and migrate the part of the site about Ivy and
>> IvyDE to asciidoc, since it has gone well for the documentation about Ivy
>> and IvyDE.
>> 
>> So first, is OK for everybody ?
>> Reminding of the pros: way faster, more standard source of doc. For the
>> cons: not 'html-hackable’ easily, see below about the home page.
>> 
>> For a first base of the discussion, I have give it a shot. I have reused
>> the xooki2asciidoc tool developed for Ivy's documentation. And I have done
>> a first run, committed the result of the asciidoc files. I think that since
>> the amount of the pages is reasonable, the quality is fine enough and can
>> fix the page manually from there.
>> 
>> You can see the generated site from the asciidoc files with: ant -f
>> build-doc.xml generate-site
>> The new site is generated in a ‘production2’ folder, so we do not mess
>> with the real site. It is only for testing purpose for now.
>> 
>> There are some cleanup to do, I haven't fix any page manually. If somebody
>> want to start, he is welcome to do so.
>> 
>> One page I am worried about is the main page [2]. I am not sure there are
>> some sane asciidoc directives to render something similar. If you already
>> have ideas, please share. If I remember correctly there is directive to
>> blindly render content, which could be html, as a fall back.
>> 
>> Then, if we’re OK with the change, and if we find something suitable to
>> generate the Home page, we prepare a new version of the site, pushing
>> somewhere so we can review it online. Once happy with the result, we
>> switch. And then we apply the same process with the site for IvyDE. Sounds
>> good ?
>> 
>> Nicolas
>> 
>> [1] http://ant.apache.org/ivy/index.html <http://ant.apache.org/ivy/
>> index.html>
>> 
>> 
> 
> 
> -- 
> Matt Sicker <boa...@gmail.com>


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

Re: ivy change

[Nicolas Lalevée]

> Le 23 avr. 2018 à 14:21, Maarten Coene  a 
> écrit :
> 
> Hi,
> I've committed a change to ModuleDescriptorMemoryCache.Where should I 
> document this change? Is it 'release-notes.adoc’?

Yes, this is the place, it is the new doc/release-notes.html.

Nicolas


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

[Announce] Release of Apache Ivy 2.5.0-rc1

[Nicolas Lalevée]

The Apache Ivy project is pleased to announce its 2.5.0-rc1 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.5.0-rc1 release are
* The minimum runtime Java version required is now Java 7
* Ivy now uses BouncyCastle OpenPGP API 1.59. Due to the non backward 
compatibility of that library, earlier versions are not supported.
* Ivy now uses HttpComponents HttpClient 4.5.x version with HTTP backed 
resolvers. Users are expected to have this version of the library (and its 
dependencies) in their runtime classpath if they want to use such resolvers. 
The previous (similarly named but not the same) commons-httpclient library is 
no longer used or supported. (IVY-1563)

As a release candidate version, we strongly encourage the use of this version 
for 
testing and validation.

Issues should be reported to:
https://issues.apache.org/jira/browse/IVY 
<https://issues.apache.org/jira/browse/IVY>

Download the 2.5.0-rc1 release at:
http://ant.apache.org/ivy/download.cgi <http://ant.apache.org/ivy/download.cgi>

More information can be found on the Ivy website:
http://ant.apache.org/ivy/ <http://ant.apache.org/ivy/>

Regards,
Nicolas Lalevée

Re: Ant JUnit tests

[Nicolas Lalevée]

> Le 20 avr. 2018 à 18:48, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> 2018-04-20 15:26 GMT+00:00 Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>>:
> 
>>> Le 20 avr. 2018 à 07:09, Gintautas Grigelionis <g.grigelio...@gmail.com>
>> a écrit :
>>> 
>>> I am refactoring Ant JUnit tests with a goal to make them more
>>> "IDE-friendly". I found several tests that are implictly dependent on
>>> ant.home property being set. In these cases, the test should be prevented
>>> from execution by adding an assumption; however, perhaps there might be a
>>> suitable default, like basedir + "/bootstrap" or some other location that
>>> might be suggested in, say, javadoc?
>> 
>> Rather than being skipped, it would prefer that such tests fail. I would
>> assume that the test being skipped are only the tests that I cannot run,
>> like the one testing a special feature of Windows while I am on MacOS. If
>> it is just about an incorrect configuration of my IDE, I would want to be
>> clearly notified that I can do something to run the tests, rather than
>> silently skipping such tests. Because in the end I would want to run such
>> tests.
> 
> 
> I think I was clear that assumptions are not silent; here's an example of
> assumptions from Ant build log
> 
> Testsuite: org.apache.tools.ant.util.JavaEnvUtilsTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0,01 sec
> 
> Testcase: 
> java10IsDetectedProperly(org.apache.tools.ant.util.JavaEnvUtilsTest):SKIPPED:
> got: , expected: is 
> Testcase: 
> testGetExecutableWindows(org.apache.tools.ant.util.JavaEnvUtilsTest):SKIPPED:
> Test only runs on windows
> Testcase: 
> testGetExecutableNetware(org.apache.tools.ant.util.JavaEnvUtilsTest):SKIPPED:
> Test only runs on netware
> 
> The first SKIPPED line is emitted by a messageless assumption
> 
> assumeTrue("10".equals(System.getProperty("java.specification.version")));
> 
> Now, I don't see a point why a system property "ant.home" should be treated
> differently from a system property "java.specification.version ».

The property ‘ant.home’ is about how the test runner is setup, which is 
controlled by the end user.
The other one is about which jvm is running. The end user can certainly change 
it, but he is then shooting himself in the foot.

The ‘ant.home’ is not an unchangeable property like the jvm or the OS.

> An
> assumption should inform you that the test won't run unless the property is
> set, and that's what you wanted: a notification that you can (and must) do
> something to run the test.

I still need to make the distinction between the thing I cannot change to make 
the test pass, like the OS, and the things that I can and should fix in the 
config of my IDE.

Nicolas

Re: Ant JUnit tests

[Nicolas Lalevée]

> Le 20 avr. 2018 à 07:09, Gintautas Grigelionis  a 
> écrit :
> 
> I am refactoring Ant JUnit tests with a goal to make them more
> "IDE-friendly". I found several tests that are implictly dependent on
> ant.home property being set. In these cases, the test should be prevented
> from execution by adding an assumption; however, perhaps there might be a
> suitable default, like basedir + "/bootstrap" or some other location that
> might be suggested in, say, javadoc?

Rather than being skipped, it would prefer that such tests fail. I would assume 
that the test being skipped are only the tests that I cannot run, like the one 
testing a special feature of Windows while I am on MacOS. If it is just about 
an incorrect configuration of my IDE, I would want to be clearly notified that 
I can do something to run the tests, rather than silently skipping such tests. 
Because in the end I would want to run such tests.

Nicolas


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

Re: [RESULT][VOTE] Ivy 2.5.0-rc1 Release

[Nicolas Lalevée]

Binaries have been pushed, but the process to update the site still reference 
the old way, with a documentation managed with xooki. So I’ll need some time to 
create a process for asciidoc based documentation and run it.

Nicolas

> Le 19 avr. 2018 à 20:13, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> The release got 4 binding +1. The release is thus accepted.
> 
> I’ll get it published then.
> 
> Nicolas
> 
>> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a 
>> écrit :
>> 
>> I have built a release candidate for Ivy 2.5.0-rc1.
>> 
>> The git tag of this release is: 
>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>>  
>> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
>> 
>> The artifacts has been published to: 
>> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
>> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
>> 
>> The staging Maven repository is available there: 
>> https://repository.apache.org/content/repositories/orgapacheant-1026 
>> <https://repository.apache.org/content/repositories/orgapacheant-1026>
>> 
>> The Eclipse updatesite has been build there: 
>> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>>  
>> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
>> 
>> Do you vote for the release of these binaries?
>> 
>> 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

[RESULT][VOTE] Ivy 2.5.0-rc1 Release

[Nicolas Lalevée]

The release got 4 binding +1. The release is thus accepted.

I’ll get it published then.

Nicolas

> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> I have built a release candidate for Ivy 2.5.0-rc1.
> 
> The git tag of this release is: 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>  
> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
> The artifacts has been published to: 
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> The staging Maven repository is available there: 
> https://repository.apache.org/content/repositories/orgapacheant-1026 
> <https://repository.apache.org/content/repositories/orgapacheant-1026>
> 
> The Eclipse updatesite has been build there: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>  
> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
> 
> Do you vote for the release of these binaries?
> 
> Regards,
> Nicolas
> 


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

Re: [VOTE] Ivy 2.5.0-rc1 Release

[Nicolas Lalevée]

> Le 14 avr. 2018 à 19:02, Stefan Bodewig <bode...@apache.org> a écrit :
> 
> On 2018-04-12, Nicolas Lalevée wrote:
> 
>> I have built a release candidate for Ivy 2.5.0-rc1.
> 
>> The git tag of this release is: 
>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>>  
>> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
>> The artifacts has been published to: 
>> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
>> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> As usual I haven't tested anything, just looked at the legal stuff,
> i.e. NOTICE and LICENSE are where they should be an look OK, checksums
> are fine, tag and source archive match and RAT is reasonably happy.
> 
>> Do you vote for the release of these binaries?
> 
> +1
> 
> If you want to call them 2.5.0-rc1. If you want the release to be 2.5.0
> then the names of the archives and the jars are all wrong and you'll
> have to rebuild everything (and call for another vote).

We should probably have discussed it, or I should have been more clear in my 
proposal for this release. The last release we did of Ivy was a long time ago, 
so a lot has been included in this release. Then yes, that was intentional, a 
2.5.0-rc1 will be for public consumption, with that rc marker showing the 
release may be not as stable as expected.

> It would be good if you could sign the tag as well.

I think I did. I remember using 'git tag -s’ and being asked the password of my 
private key.

I can see a PGP signature in SourceTree.
Github states it is verified: 
https://github.com/apache/ant-ivy/releases/tag/2.5.0-rc1 
<https://github.com/apache/ant-ivy/releases/tag/2.5.0-rc1>
'git verify-tag 2.5.0-rc1’ states it has a 'Good signature’

I am not fluent with git. I may have missed something.

> A minor nit, the .gitignore and .gitattributes files are mssing from the
> source archives. I don't consider this important but it would be nice if
> this could be fixed after the release.

Nice catch. I’ll fix that.

Thank you for your time Stefan.

Nicolas

Re: Junit Task warning about multiple versions of Ant

[Nicolas Lalevée]

I have been able to make unit test which reproduces the false warning. And I 
have fixed the way the classloader was created. Thanks for the insights.

Nicolas

> Le 13 avr. 2018 à 07:38, Stefan Bodewig <bode...@apache.org> a écrit :
> 
> On 2018-04-12, Nicolas Lalevée wrote:
> 
>> As far as I can see, the classpath used by checkForkedPath is the
>> proper one. The function which manipulates the classpath to add the
>> Ant runtime [1] is called before. So I should start looking into the
>> AntClassLoader which is improperly finding the Ant classes. Maybe we
>> should « isolate » it.
> 
> Sounds reasonable, so we can ensure it really only contains what will be
> on -classpath as we..
> 
>> Or maybe that check for duplicate ant jar is only useful when
>> includeantruntime is _not_ set to « no ». Since includeantruntime is
>> true by default, it is nice that Ant is printing a warning when it
>> also find Ant classes in the provided classpath, it is a common
>> pitfall. But when includeantruntime is explicitely set to false, then
>> I would say that the user know what he's doing, thus no need for
>> special check.
> 
> I'm not sure. To be honest the check and message are there so we get
> fewer bug reports by helping people figure out their problem
> themselves. At one point in time this has been a very common problem,
> which likely predated the includeAntRuntime attribute. If we manage to
> isolate the classloader (the infrastructure should be there) then we
> shouldn't need to disable the check.
> 
> 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: Junit Task warning about multiple versions of Ant

[Nicolas Lalevée]

> Le 12 avr. 2018 à 16:57, Stefan Bodewig <bode...@apache.org> a écrit :
> 
> On 2018-04-12, Nicolas Lalevée wrote:
> 
>> The Junit task is printing a warning if it finds multiple versions of
>> Ant in the classpath of the unit tests. It seems it doesn’t do
>> correctly the job if the ant runtime is explicitly removed from the
>> classpath.
> 
> Quite possible.
> 
>> Here the function which checks the classpath:
>> https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1362
>>  
>> <https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1362>
> 
> this is in the forked case.
> 
>> And here is the one which build the classloader during the actual forked run:
>> https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1952
>>  
>> <https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1952>
> 
> AFAICT createClassloader is not invoked for forked VMs, only in the
> non-forked case.
> 
>> Shouldn’t the classloader be built the same way in both function?
> 
> In the forked case, the classloader is not built by the task, the
> CommandLineJava instance collects the classpath and sets it as
> -classpath command line argument.

Ha yes, you’re right.

As far as I can see, the classpath used by checkForkedPath is the proper one. 
The function which manipulates the classpath to add the Ant runtime [1] is 
called before. So I should start looking into the AntClassLoader which is 
improperly finding the Ant classes. Maybe we should « isolate » it.

Or maybe that check for duplicate ant jar is only useful when includeantruntime 
is _not_ set to « no ». Since includeantruntime is true by default, it is nice 
that Ant is printing a warning when it also find Ant classes in the provided 
classpath, it is a common pitfall. But when includeantruntime is explicitely 
set to false, then I would say that the user know what he's doing, thus no need 
for special check.

Nicolas

[1] 
https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1320
 
<https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1320>

Re: [VOTE] Ivy 2.5.0-rc1 Release

[Nicolas Lalevée]

> Le 12 avr. 2018 à 18:29, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> I have built a release candidate for Ivy 2.5.0-rc1.
> 
> The git tag of this release is: 
> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1
>  
> <https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=tag;h=refs/tags/2.5.0-rc1>
>  with the sha1 887fd46f3e90016e313f7724ca259b936d30a03e
> 
> The artifacts has been published to: 
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1 
> <https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-rc1> at revision 26310
> 
> The staging Maven repository is available there: 
> https://repository.apache.org/content/repositories/orgapacheant-1026 
> <https://repository.apache.org/content/repositories/orgapacheant-1026>
> 
> The Eclipse updatesite has been build there: 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306
>  
> <https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.5.0.cr1_20180412005306>
> 
> Do you vote for the release of these binaries?

I have a very poor internet connection, I had to do the build on a remote 
server, so I have only done the basic checks, but it seems to works properly. 
Well, I have at least loaded in an Eclipse and it resolves properly.
I have only missed to set the date in the release notes in the packaged zip and 
tgz distributions, it still looks like this: 
http://ant.apache.org/ivy/history/master/release-notes.html 
<http://ant.apache.org/ivy/history/master/release-notes.html>. I think this is 
OK. I’ll just fix the version on the site once actually published.

So +1 for me.

Nicolas

Junit Task warning about multiple versions of Ant

[Nicolas Lalevée]

The Junit task is printing a warning if it finds multiple versions of Ant in 
the classpath of the unit tests. It seems it doesn’t do correctly the job if 
the ant runtime is explicitly removed from the classpath.

Here the function which checks the classpath:
https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1362
 


And here is the one which build the classloader during the actual forked run:
https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTask.java#L1952
 


Shouldn’t the classloader be built the same way in both function?

Nicolas,
trying to release Ivy, finding bugs in Ant :p

Re: Mass changes to various projects under Ant umbrella - should we be doing it?

[Nicolas Lalevée]

> Le 9 avr. 2018 à 20:46, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> 2018-04-09 16:48 GMT+00:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:
> 
>> I have not been reading ant-dev lately, so I cannot comment much about the
>> last patches. For a while now I have not been involved much, but probably
>> the last reviews of patches bored me enough so I lost track of the dev
>> community entirely.
>> 
>> Nicolas
>> 
> 
> Sorry for being boring

Again, it is not you. It is the « code cleaning ». And there is always boring 
stuff to do. We are discussing here how much we can handle, as a community.

Nicolas


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

Ivy release

[Nicolas Lalevée]

The last thread about a release has been stuck in the discussion about which 
PR, patch or Jira needed to be tackled before releasing. I suggest we just move 
forward with the current master. I volunteer to build a 2.5.0-rc1.

Nicolas


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

Re: Mass changes to various projects under Ant umbrella - should we be doing it?

[Nicolas Lalevée]

Le 7 avr. 2018 à 14:13, Gintautas Grigelionis  a écrit 
:
> 
> I sense a personal attack using broad, generalised accusations :-)
> Could we please stop the inflammatory comments and be more to the point?

Please don’t. Nothing is personal here. Jaikiran used « we ». Even if you are 
the author of the majority of the patches, people are reviewing it, people are 
finding errors and fixing them afterwards, this is a community effort. Thus 
this is a community discussion.

I have not been reading ant-dev lately, so I cannot comment much about the last 
patches. For a while now I have not been involved much, but probably the last 
reviews of patches bored me enough so I lost track of the dev community 
entirely.

Nicolas


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

Re: Ivy upcoming release - where we stand

[Nicolas Lalevée]

> Le 19 sept. 2017 à 06:37, Gintautas Grigelionis  a 
> écrit :
> 
> I would like to propose upgrading BouncyCastle to at least 1.57 [1] to
> include all security and PGP/GPG related fixes.

+1

Nicolas

> 
> Gintas
> 
> [1] https://www.bouncycastle.org/releasenotes.html
> 
> 2017-09-11 21:45 GMT+02:00 Gintautas Grigelionis :
> 
>> I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included
>> in the upcoming release.
>> 
>> There were few opinions about using SVG graphics, so I'm not sure whether
>> the proposals could just simply be merged. It would be nice to refresh the
>> site for the 10th anniversary of graduation from the incubator, though.
>> 
>> Finally, there is a contentious issue of API change regarding the use of
>> generics. Arrays of generics is a no-no in Java [1]. Thus, the method in
>> question should be deprecated. IMHO, the suggested mitigation by providing
>> a default implementation of the new method in terms of the old one in the
>> abstract class is sufficient for the use cases found in the wild.
>> 
>> Gintas
>> 
>> [1] https://docs.oracle.com/javase/tutorial/java/generics/
>> restrictions.html
>> 
>> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai :
>> 
>>> It's been a while since we have decided to revive the Ivy project and
>>> work towards a usable release. Since then, we have fixed a good number of
>>> bugs, added some enhancements and updated the documentation (we also
>>> switched to asciidoc based docs internally). When we started this, the goal
>>> was to reach a certain state where we can do a release. At this point, IMO,
>>> we are _almost_ there to do the release. I say almost because, there's one
>>> specific bug that I want to be fixed in this release -
>>> https://issues.apache.org/jira/browse/IVY-1485. There's been a
>>> discussion about what it involves and why it isn't an easy fix in this
>>> mailing list before. I have been working on it and as was expected, it's a
>>> bit complex and since it touches a critical part of the code, I don't want
>>> to rush it.
>>> 
>>> The past few weeks, I have been shifting between this issue and fixing
>>> certain other issues that have been reported in JIRA. But at this point, I
>>> plan to just focus on this single issue (and one minor task involving
>>> reviewing the tutorial docs), before I personally consider things done for
>>> this release.
>>> 
>>> -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 upcoming release - where we stand

[Nicolas Lalevée]

> Le 11 sept. 2017 à 21:45, Gintautas Grigelionis  a 
> écrit :
> 
> I'd like to have https://issues.apache.org/jira/browse/IVY-1420 included in
> the upcoming release.

Every bug is important, but I think releasing often is more important. Apart 
from IVY-1485 which is kind of special, I think we should release what we have. 

> There were few opinions about using SVG graphics, so I'm not sure whether
> the proposals could just simply be merged. It would be nice to refresh the
> site for the 10th anniversary of graduation from the incubator, though.

I had a quick look, but as commented in an earlier email, the commit in your PR 
brings a lot of stuff. I haven’t noticed anything wrong about the SVG stuff (I 
was worried about the huge IvyLogo.java duplicating the svg file, but it was 
nicely documented that it was generated and how, so it is OK). But if you want 
a more proper review, please make a dedicated PR.

> Finally, there is a contentious issue of API change regarding the use of
> generics. Arrays of generics is a no-no in Java [1]. Thus, the method in
> question should be deprecated. IMHO, the suggested mitigation by providing
> a default implementation of the new method in terms of the old one in the
> abstract class is sufficient for the use cases found in the wild.

IIRC, we agree to a least make the change in a backward compatible way, and 
then have a deeper discussion (vote?) about an API break. Are we still on track 
?

Nicolas

> 
> Gintas
> 
> [1] https://docs.oracle.com/javase/tutorial/java/generics/restrictions.html
> 
> 2017-09-11 17:05 GMT+02:00 Jaikiran Pai :
> 
>> It's been a while since we have decided to revive the Ivy project and work
>> towards a usable release. Since then, we have fixed a good number of bugs,
>> added some enhancements and updated the documentation (we also switched to
>> asciidoc based docs internally). When we started this, the goal was to
>> reach a certain state where we can do a release. At this point, IMO, we are
>> _almost_ there to do the release. I say almost because, there's one
>> specific bug that I want to be fixed in this release -
>> https://issues.apache.org/jira/browse/IVY-1485. There's been a discussion
>> about what it involves and why it isn't an easy fix in this mailing list
>> before. I have been working on it and as was expected, it's a bit complex
>> and since it touches a critical part of the code, I don't want to rush it.
>> 
>> The past few weeks, I have been shifting between this issue and fixing
>> certain other issues that have been reported in JIRA. But at this point, I
>> plan to just focus on this single issue (and one minor task involving
>> reviewing the tutorial docs), before I personally consider things done for
>> this release.
>> 
>> -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 upcoming release - where we stand

[Nicolas Lalevée]

> Le 11 sept. 2017 à 17:05, Jaikiran Pai  a écrit :
> 
> It's been a while since we have decided to revive the Ivy project and work 
> towards a usable release. Since then, we have fixed a good number of bugs, 
> added some enhancements and updated the documentation (we also switched to 
> asciidoc based docs internally). When we started this, the goal was to reach 
> a certain state where we can do a release. At this point, IMO, we are 
> _almost_ there to do the release. I say almost because, there's one specific 
> bug that I want to be fixed in this release - 
> https://issues.apache.org/jira/browse/IVY-1485. There's been a discussion 
> about what it involves and why it isn't an easy fix in this mailing list 
> before. I have been working on it and as was expected, it's a bit complex and 
> since it touches a critical part of the code, I don't want to rush it.
> 
> The past few weeks, I have been shifting between this issue and fixing 
> certain other issues that have been reported in JIRA. But at this point, I 
> plan to just focus on this single issue (and one minor task involving 
> reviewing the tutorial docs), before I personally consider things done for 
> this release.

I don’t want to rush it either, but it was IVY-1485 which reanimated the 
community. I would be disappointed it a fix is not included for that bug.
We can be several to look at it. Don’t hesitate to show some work in progress 
or ask for help.

Nicolas


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

Re: Ivy - Latest snapshots will now be regularly available in Apache Maven Snapshot repository

[Nicolas Lalevée]

Awesome!

> Le 31 août 2017 à 10:43, Jaikiran Pai  a écrit :
> 
> Starting today, we now have an Ivy Jenkins job[1] which will publish our Ivy 
> snapshot artifactto Apache Maven Snapshots repository[2]. This job has been 
> configured to run after a successfulcompletion of our Ivy tests job (which 
> runs on *nix).
> 
> What this effectively means is that we now have regular Ivy snapshots 
> available as Maven artifacts in the Apache Maven snapshots repository. This 
> will allow users and other projects to test out (on a continuous basis) 
> latest Ivy snapshots and help catch any issues more quickly.
> 
> The Maven co-ordinates for the 2.5.0-SNAPSHOT (the current master version) 
> are:
> 
> org.apache.ivy
> ivy
> 2.5.0-SNAPSHOT
> 
> and can be found here 
> https://repository.apache.org/content/groups/snapshots/org/apache/ivy/ivy/2.5.0-SNAPSHOT/
> 
> [1] https://builds.apache.org/job/Ivy-Snapshot-Deploy/
> 
> [2] https://repository.apache.org/snapshots/
> 
> -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: [1/6] ant-ivy git commit: Documentation review (partly inspired by IVY-1089) [Forced Update!]

[Nicolas Lalevée]

> Le 6 sept. 2017 à 08:27, Jaikiran Pai  a écrit :
> 
> IMO, we should avoid force updates to upstream repos, since it rewrites 
> history of the repo. Typically a force update is a sign that the local state 
> of a repo is not in sync with whatever is latest upstream and that should be 
> solved locally by rebasing the local changes (and locally resolving merge 
> conflicts, if any) against the relevant branch of the latest upstream.

+1
Especially on the master branch.

Nicolas

> 
> -Jaikiran
> 
> 
> On 06/09/17 8:46 AM, gin...@apache.org wrote:
>> Repository: ant-ivy
>> Updated Branches:
>>   refs/heads/master 614bf1ad5 -> b693aa0a2 (forced update)
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/b693aa0a/asciidoc/use/resolve.adoc
>> --
>> diff --git a/asciidoc/use/resolve.adoc b/asciidoc/use/resolve.adoc
>> index 371d2c4..fcc7bd9 100644
>> --- a/asciidoc/use/resolve.adoc
>> +++ b/asciidoc/use/resolve.adoc
>> @@ -17,21 +17,21 @@
>> under the License.
>>  
>>  -The resolve task actually resolve dependencies described in an 
>> link:../ivyfile.html[ivy file], and put the resolved dependencies in the ivy 
>> cache.
>> -If configure has not been called before resolve is called, a default 
>> configuration will be used (equivalent to call configure with no attributes).
>> +The resolve task actually resolve dependencies described in an 
>> link:../ivyfile.html[Ivy file], and put the resolved dependencies in the Ivy 
>> cache.
>> +If configure has not been called before resolve is called, a default 
>> configuration will be used (equivalent to calling configure without 
>> attributes).
>>  -After the call to this task, four properties are set in ant:
>> +After the call to this task, four properties are set in Ant:
>>  -* `ivy.organisation`: set to the organisation name found in the ivyfile 
>> which was used for resolve
>> -* `ivy.module`: set to the module name found in the ivyfile which was used 
>> for resolve
>> -* `ivy.revision`: set to the revision name found in the ivyfile which was 
>> used for resolve, or a generated revision name if no revision was specified 
>> in the file
>> +* `ivy.organisation`: set to the organisation name found in the Ivy file 
>> which was used for resolve
>> +* `ivy.module`: set to the module name found in the Ivy file which was used 
>> for resolve
>> +* `ivy.revision`: set to the revision name found in the Ivy file which was 
>> used for resolve, or a generated revision name if no revision was specified 
>> in the file
>>  * `ivy.resolved.configurations`: set to the comma separated list of 
>> configurations resolved
>>*Since 1.2:*
>>  An additional property is set to `true` if the resolved dependencies are 
>> changes since the last resolve, and to `false` otherwise: `ivy.deps.changed`.
>>*Since 2.0:*
>> -The property `ivy.deps.changed` will not be set (and not be computed) if 
>> you set the parameter `checkIfChanged` to `false`. (by default it is `true` 
>> to keep backward compatibility).  This allow to optimize your build when you 
>> have multi-module build with multiple configurations.
>> +The property `ivy.deps.changed` will not be set (and not be computed) if 
>> you set the parameter `checkIfChanged` to `false`. (By default, it is `true` 
>> to keep backward compatibility).  This allows to optimize your build when 
>> you have multi-module build with multiple configurations.
>>*Since 2.0:*
>>  In addition, if the `resolveId` attribute has been set, the following 
>> properties are set as well:
>> @@ -45,15 +45,15 @@ In addition, if the `resolveId` attribute has been set, 
>> the following properties
>>  *Since 2.4*
>>  If current module extends other modules:
>>  -* `ivy.parents.count`: number of parents module
>> -* `ivy.parent[__index__].organisation`: set to the organisation name found 
>> in the parent ivyfile which was used for resolve
>> -* `ivy.parent[__index__].module`: set to the module name found in the 
>> parent ivyfile which was used for resolve
>> -* `ivy.parent[__index__].revision`: set to the revision name found in the 
>> parent ivyfile which was used for resolve
>> -* `ivy.parent[__index__].branch`: set to the branch name found in the 
>> parent ivyfile which was used for resolve
>> +* `ivy.parents.count`: number of parent modules
>> +* `ivy.parent[__index__].organisation`: set to the organisation name found 
>> in the parent Ivy file which was used for resolve
>> +* `ivy.parent[__index__].module`: set to the module name found in the 
>> parent Ivy file which was used for resolve
>> +* `ivy.parent[__index__].revision`: set to the revision name found in the 
>> parent Ivy file which was used for resolve
>> +* `ivy.parent[__index__].branch`: set to the branch name found in the 
>> parent Ivy file which was used for resolve
>>Where __index__ represent the index of extends module.
>>  -When ivy has finished the 

Re: IVY-450

[Nicolas Lalevée]

Hi,

Sorry for the delay, I have been less attentive to ant stuff lately.

> Le 4 sept. 2017 à 10:51, Gintautas Grigelionis  a 
> écrit :
> 
> Changing ids is not supposed to change navigation -- if it does, then we
> have a problem :-)
> I was only wondering if anybody uses these ids for styling, so that pages
> in Subversion or some other strange place would need retrofitting.
> I have not seen CSS escaping [1] anywhere (but maybe I don't know where to
> look :-) and I prefer KISS (whatever your opinion of the terrible
> JavaScript oneliner that does the job for IVY-450 ;-).

No objection to changing ids in the html.
And indeed if it changes the paths of the files then we must avoid it.

> Ditto about the bitmap icons (esp discovery and grippie).
> 
> If there are no objections, should I go forward and merge PR-55 and -60? Or
> should I wait for input from Nicolas?

There are a lot of stuff in these PR. There are xml style formatting, there is 
the downgrade of asciidoctor, there is the svg stuff, there is list styling. 
You should really try to separate stuff. It gets then easier to review and the 
things get committed faster.
For instance, a commit just about xml formatting could be pushed right away, 
there is nothing much to comment or review.
For other stuff you are unsure of and you require some review, juste create a 
branch dedicated to it from master. If while being reviewed other commits get 
onto master, a rebase of the branch will fix it nicely.

About downgrading asciidoctor, I have no objection either. If you are blocked 
by it and you think it is not related to your environment, then let’s downgrade 
it. We will upgrade it later once we’ll figure out what is going wrong.

> Then, I guess http://svn.apache.org/viewvc/ant/site/ivy/sources/style
> should change to the new unified style.css from asciidoc…

The site has not been migrated to asciidoc yet, so the generated html is not 
the same. So we still must keep the css separated.

Nicolas

> 
> Gintas
> 
> [1] https://mathiasbynens.be/notes/css-escapes
> 
> 2017-09-04 7:36 GMT+02:00 Jan Matèrne (jhm) :
> 
>> This would break BC of the website ...
>> Ok, I am joking. This is daily business with websites ;)
>> I think we dont even need a 301-permantent-redirect and following the W3C
>> recommendations would be fine.
>> 
>> Jan
>> 
>>> -Ursprüngliche Nachricht-
>>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>>> Gesendet: Freitag, 1. September 2017 22:00
>>> An: Ant Developers List
>>> Betreff: IVY-450
>>> 
>>> I started looking at IVY-450 (highlight current menu) and realized that
>>> menu ids break W3C recommendations by containing "/" like "xooki-
>>> ivyfile/dependency-conf". I'd like to change the URL transformation so
>>> that the generated ids would contain double hyphen like "xooki-ivyfile-
>>> -dependency-conf". Any objections/alternatives?
>>> 
>>> TIA, Gintas
>> 
>> 
>> -
>> 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 - No more support for commons-httpclient 2.x in runtime classpath?

[Nicolas Lalevée]

> Le 24 juil. 2017 à 08:19, Jaikiran Pai  a écrit :
> 
> That's a a big enough reason to move to HttpComponents Client 4.x version! 
> I'll have that done in this release of Ivy then.

+1

Nicolas

> 
> -Jaikiran
> 
> 
> On 24/07/17 11:43 AM, Stefan Bodewig wrote:
>> On 2017-07-24, Jaikiran Pai wrote:
>> 
>>> Ivy currently uses commons-httpclient for dealing with HTTP
>>> repositories. This is an internal implementation detail of Ivy. The
>>> way it's implemented, it allows the user to use a version of their
>>> choice, of this library, by placing them in the runtime classpath
>>> (similar to some other libraries we use). The implementation
>>> internally checks for the presence of 2.x as well as 3.x version of
>>> library to decide which version to use at _runtime_ .
>> Let me point out that even 3.x has long reached end of life. It's
>> successor fixed CVE-2012-5783[1] with 4.2.3 but there hasn't been any
>> 3.x release that has fixed it AFAIK.
>> 
>> Stefan
>> 
>> [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5783
>> 
>> -
>> 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

[RESULT] [VOTE] IvyDE requirements

[Nicolas Lalevée]

Counting my own implicit +1 on both questions,

To make IvyDE require Java 7 as minimum, I count 3 binding +1, one non binding 
+1. The vote pass.
To make IvyDE require Eclipse 4.3 aka Eclipse Kepler as minimum, I count 3 
binding +1, one non binding +1. The vote pass.

Cheers,
Nicolas


> Le 11 juil. 2017 à 23:07, Nicolas Lalevée <nicolas.lale...@hibnet.org> a 
> écrit :
> 
> We have recently voted to make Ivy require Java 1.7. I think we should do it 
> for IvyDE too.
> Do you vote for it ?
> 
> 
> And while making the build of IvyDE work again nicely, I had to update its 
> dependencies. Mainly, the build requires Eclipse 4.3, aka Eclipse Kepler (it 
> is not the newest one as you can see [1]). So let’s make it official that we 
> require at least Eclipse 4.3.
> Do you vote for it ?
> 
> 
> Nicolas
> 
> [1] https://en.wikipedia.org/wiki/Eclipse_(software)#Releases 
> <https://en.wikipedia.org/wiki/Eclipse_(software)#Releases>
> 


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

Re: ant-ivy git commit: An asciidoctor macro to create links to Jira

[Nicolas Lalevée]

I look deeper into asciidoctor and asciidoctor-ant, and I have managed to 
create a simple macro. It creates links to jira just by declaring the name of 
the issue.

The Ant tasks only supports macro implemented in Java, not Ruby, even if it 
seems that asciidoctor itself might support them in Ruby. So the build is a 
little more complex. I hope it is ok. At least the setup is in place in case 
somebody wants to add more macros.

Nicolas

> Le 12 juil. 2017 à 22:55, hi...@apache.org a écrit :
> 
> Repository: ant-ivy
> Updated Branches:
>  refs/heads/master 1a36ae09d -> 6f22f4b49
> 
> 
> An asciidoctor macro to create links to Jira
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/6f22f4b4
> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/6f22f4b4
> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/6f22f4b4
> 
> Branch: refs/heads/master
> Commit: 6f22f4b49c2a3a59840d28e6cbe0c37a56ab1f90
> Parents: 1a36ae0
> Author: Nicolas Lalevée 
> Authored: Wed Jul 12 22:54:25 2017 +0200
> Committer: Nicolas Lalevée 
> Committed: Wed Jul 12 22:54:25 2017 +0200
> 
> --
> asciidoc/release-notes.adoc | 54 ++--
> .../src/org/apache/ivy/asciidoc/JiraMacro.java  | 40 +++
> build-release.xml   | 23 -
> 3 files changed, 88 insertions(+), 29 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/6f22f4b4/asciidoc/release-notes.adoc
> --
> diff --git a/asciidoc/release-notes.adoc b/asciidoc/release-notes.adoc
> index c2b7962..3b691b6 100644
> --- a/asciidoc/release-notes.adoc
> +++ b/asciidoc/release-notes.adoc
> @@ -50,40 +50,40 @@ http://issues.apache.org/jira/browse/ivy
> 
> List of changes since Ivy 2.4.0:
> 
> -- FIX: Local conflict manager didn't handle deeper conflicts in transitive 
> dependencies (link:https://issues.apache.org/jira/browse/IVY-1404[IVY-1404])
> -- FIX: Made the maven 'test' configuration public so we can use the test-jar 
> as dependency (link:https://issues.apache.org/jira/browse/IVY-1444[IVY-1444])
> -- FIX: NullPointerException in dependencytree with no dependencies 
> (link:https://issues.apache.org/jira/browse/IVY-1539[IVY-1539])
> -- FIX: checkIfChanged is not settable attribute for checkdepsupdate ant task 
> (link:https://issues.apache.org/jira/browse/IVY-1549[IVY-1549])
> -- FIX: ArrayIndexOutOfBoundsException when using a p2 repository for 
> dependencies (link:https://issues.apache.org/jira/browse/IVY-1504[IVY-1504])
> +- FIX: Local conflict manager didn't handle deeper conflicts in transitive 
> dependencies (jira:IVY-1404[])
> +- FIX: Made the maven 'test' configuration public so we can use the test-jar 
> as dependency (jira:IVY-1444[])
> +- FIX: NullPointerException in dependencytree with no dependencies 
> (jira:IVY-1539[])
> +- FIX: checkIfChanged is not settable attribute for checkdepsupdate ant task 
> (jira:IVY-1549[])
> +- FIX: ArrayIndexOutOfBoundsException when using a p2 repository for 
> dependencies (jira:IVY-1504[])
> - FIX: fixdeps remove transitive 'kept' dependencies
> -- FIX: PomModuleDescriptorParser should parse licenses from parent POM 
> (link:https://issues.apache.org/jira/browse/IVY-1526[IVY-1526]) (Thanks to 
> Jaikiran Pai)
> -- FIX: dynamic revisions are not cached per resolver 
> (link:https://issues.apache.org/jira/browse/IVY-1430[IVY-1430]) (Thanks to 
> Stephen Haberman)
> -- FIX: Dependencies failed using branch attribute (and extra attributes) 
> (link:https://issues.apache.org/jira/browse/IVY-1141[IVY-1141]) (Thanks to 
> Stephen Haberman)
> -- FIX: useCacheOnly should allow lookup of changing dependencies in cache 
> (link:https://issues.apache.org/jira/browse/IVY-1515[IVY-1515]) (Thanks to 
> Ilya)
> -- FIX: Translation of POM to Ivy XML with * exclusion is removing main 
> artifact (link:https://issues.apache.org/jira/browse/IVY-1531[IVY-1531]) 
> (Thanks to Jaikiran Pai)
> -- FIX: Have makepom task take description from ivy-module > info > 
> description element 
> (link:https://issues.apache.org/jira/browse/IVY-1520[IVY-1520])
> -- FIX: Fix RetrieveEngine to take into account the correct extension while 
> dealing with unpacked artifacts 
> (link:https://issues.apache.org/jira/browse/IVY-1478[IVY-1478]) (Thanks to 
> Jaikiran Pai)
> -- FIX: ParseException "Unsupported repository, resources names are not uris" 
> for ivy.xml with parent on Windows 
> (link:https://issues.apache.org/jira/browse/IVY-1448[IVY-1448]) (Thanks to 
> Riccardo Foschia and Jaikiran Pai)
> -- FIX: Ivy 2.4.0 improperly handles modules with colon (:) in version 
> 

[VOTE] IvyDE requirements

[Nicolas Lalevée]

We have recently voted to make Ivy require Java 1.7. I think we should do it 
for IvyDE too.
Do you vote for it ?


And while making the build of IvyDE work again nicely, I had to update its 
dependencies. Mainly, the build requires Eclipse 4.3, aka Eclipse Kepler (it is 
not the newest one as you can see [1]). So let’s make it official that we 
require at least Eclipse 4.3.
Do you vote for it ?


Nicolas

[1] https://en.wikipedia.org/wiki/Eclipse_(software)#Releases 

Re: Build failed in Jenkins: IvyDE #320

[Nicolas Lalevée]

Indeed, with the proper urls it builds, thank both of you.

Nicolas

> Le 11 juil. 2017 à 07:29, Jaikiran Pai <jai.forums2...@gmail.com> a écrit :
> 
> 
> On 11/07/17 3:26 AM, Nicolas Lalevée wrote:
>> I don’t understand what is going on. The files are there and then they 
>> disappear… I have been able to download this file, and now it is gone. It 
>> happens several times for different files locally… I though I had finally 
>> have found a stable set of zip to download, but it seems actually not...
>> 
>> Nicolas
>> 
>>> 
>>> eclipse-check-download-gef:
>>> 
>>> eclipse-get-gef:
>>>  [get] Getting: 
>>> http://www.eclipse.org/downloads/download.php?file=/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-SDK-3.9.100.zip_id=1
>>>  [get] To: 
>>> <https://builds.apache.org/job/IvyDE/ws/dependencies/GEF-SDK-3.9.100.zip>
>>> *[get] 
>>> http://www.eclipse.org/downloads/download.php?file=/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-SDK-3.9.100.zip_id=1
>>>  moved to 
>>> http://archive.eclipse.org/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-SDK-3.9.100.zip
>>>  *  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] 
>>>  [get] .
>>> 
>>> eclipse-check-download-zest:
>>> 
>>> eclipse-get-zest:
>>>  [get] Getting: 
>>> http://www.eclipse.org/downloads/download.php?file=/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-zest-3.9.100.zip_id=1
>>>  [get] To: 
>>> <https://builds.apache.org/job/IvyDE/ws/dependencies/GEF-zest-3.9.100.zip>
>>>  [*get] 
>>> http://www.eclipse.org/downloads/download.php?file=/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-zest-3.9.100.zip_id=1
>>>  moved to 
>>> http://download.eclipse.org/tools/gef/downloads/drops/3.9.100/R201405261516/GEF-zest-3.9.100.zip*
> 
> From those logs it appears that whoever setup the HTTP (302) redirects for 
> these downloads at eclipse.org, set it up correctly for gef-sdk to point to 
> archive.eclipse.org whereas for get-zest it has been setup to point to an 
> incorrect URL at download.eclipse.org which just presents a generic 404 page.
> 
> I think for us, at this point, it's a matter of changing our build file to 
> just point directly to the relevant specific links listed on 
> archive.eclipse.org here 
> http://archive.eclipse.org/tools/gef/downloads/drops/3.9.100/R201405261516/
> 
> -Jaikiran
> 


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

Re: Build failed in Jenkins: IvyDE #320

[Nicolas Lalevée]

I don’t understand what is going on. The files are there and then they 
disappear… I have been able to download this file, and now it is gone. It 
happens several times for different files locally… I though I had finally have 
found a stable set of zip to download, but it seems actually not...

Nicolas

> Le 10 juil. 2017 à 23:37, Apache Jenkins Server  a 
> écrit :
> 
> See 
> 
> Changes:
> 
> [nicolas.lalevee] update build dependencies, and reenable the build of the 
> resolve
> 
> --
> [...truncated 29.75 KB...]
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 
>  [get] 

Re: [2/2] ant-ivy git commit: Generate automatically the copyright year in the doc

[Nicolas Lalevée]

Templates updated. I used the same range as the one in the NOTICE file.

Nicolas

> Le 6 juil. 2017 à 12:38, Gintautas Grigelionis  a 
> écrit :
> 
> I put 2007 in javadoc :-)
> 
> Gintas
> 
> 2017-07-06 12:01 GMT+02:00 Matèrne, Jan (RZF, Ref 410) <
> jan.mate...@fv.nrw.de>:
> 
>> Haven't searched for the 'right' year.
>> 2008 was the year from an early 2.0.0-beta-Release.
>> But I think you got my point. ;)
>> 
>> Jan
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>> Gesendet: Donnerstag, 6. Juli 2017 10:15
>> An: Ant Developers List
>> Betreff: Re: [2/2] ant-ivy git commit: Generate automatically the
>> copyright year in the doc
>> 
>> I believe Ivy graduated in 2007?
>> 
>> Gintas
>> 
>> 2017-07-06 8:10 GMT+02:00 Matèrne, Jan (RZF, Ref 410) <
>> jan.mate...@fv.nrw.de
>>> :
>> 
>>> AFAIK in other locations we use a range of time.
>>> Should that be used here too?
>>> 
>>>  | Copyright  2008 -
>>>  = " " + Time.now.year.to_s + " "
>>>  | The Apache Software Foundation, Licensed under the a href="
>>> http://www.apache.org/licenses/; Apache License, Version 2.0.
>>> 
>>> 
>>> Jan
>>> 
>>> -Ursprüngliche Nachricht-
>>> Von: hi...@apache.org [mailto:hi...@apache.org]
>>> Gesendet: Mittwoch, 5. Juli 2017 22:15
>>> An: notificati...@ant.apache.org
>>> Betreff: [2/2] ant-ivy git commit: Generate automatically the copyright
>>> year in the doc
>>> 
>>> Generate automatically the copyright year in the doc
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/a12daf30
>>> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/a12daf30
>>> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/a12daf30
>>> 
>>> Branch: refs/heads/master
>>> Commit: a12daf3088cd295e30e36ce1c48416b3308e0943
>>> Parents: fc6305a
>>> Author: Nicolas Laleve??e 
>>> Authored: Wed Jul 5 22:13:46 2017 +0200
>>> Committer: Nicolas Laleve??e 
>>> Committed: Wed Jul 5 22:13:46 2017 +0200
>>> 
>>> --
>>> asciidoc/templates/book/document.html.slim | 4 +++-
>>> asciidoc/templates/document.html.slim  | 4 +++-
>>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>> --
>>> 
>>> 
>>> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/
>>> a12daf30/asciidoc/templates/book/document.html.slim
>>> --
>>> diff --git a/asciidoc/templates/book/document.html.slim
>>> b/asciidoc/templates/book/document.html.slim
>>> index 126676e..8541fcf 100644
>>> --- a/asciidoc/templates/book/document.html.slim
>>> +++ b/asciidoc/templates/book/document.html.slim
>>> @@ -42,7 +42,9 @@ html lang=(attr :lang, 'en' unless attr? :nolang)
>>>   div id="footer-message" class="footer"
>>> hr/
>>> i
>>> -  | Copyright  2017 The Apache Software Foundation,
>>> Licensed under the
>>> +  | Copyright 
>>> +  = " " + Time.now.year.to_s + " "
>>> +  | The Apache Software Foundation, Licensed under the
>>>   a href="http://www.apache.org/licenses/; Apache License,
>>> Version 2.0
>>>   | .
>>> br/
>>> 
>>> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/
>>> a12daf30/asciidoc/templates/document.html.slim
>>> --
>>> diff --git a/asciidoc/templates/document.html.slim
>>> b/asciidoc/templates/document.html.slim
>>> index 5a8bd92..776221a 100644
>>> --- a/asciidoc/templates/document.html.slim
>>> +++ b/asciidoc/templates/document.html.slim
>>> @@ -79,7 +79,9 @@ html lang=(attr :lang, 'en' unless attr? :nolang)
>>>   div id="footer-message" class="footer"
>>> hr/
>>> i
>>> -  | Copyright  2017 The Apache Software Foundation,
>>> Licensed under the
>>> +  | Copyright 
>>> +  = " " + Time.now.year.to_s + " "
>>> +  | The Apache Software Foundation, Licensed under the
>>>   a href="http://www.apache.org/licenses/; Apache License,
>>> Version 2.0
>>>   | .
>>> br/
>>> 
>>> 
>>> -
>>> 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-ivy git commit: avoid generating the reports in the folder where the html of the documentation is generated

[Nicolas Lalevée]

I have updated the config of the Jenkins jobs accordingly.

Nicolas

> Le 4 juil. 2017 à 23:59, hi...@apache.org a écrit :
> 
> Repository: ant-ivy
> Updated Branches:
>  refs/heads/master cd8f81d0a -> eeb79e100
> 
> 
> avoid generating the reports in the folder where the html of the 
> documentation is generated
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/eeb79e10
> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/eeb79e10
> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/eeb79e10
> 
> Branch: refs/heads/master
> Commit: eeb79e1003e20bba5cf58f1c6435768fd81a8371
> Parents: cd8f81d
> Author: Nicolas Lalevée 
> Authored: Tue Jul 4 23:17:40 2017 +0200
> Committer: Nicolas Lalevée 
> Committed: Tue Jul 4 23:17:40 2017 +0200
> 
> --
> build.properties | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/eeb79e10/build.properties
> --
> diff --git a/build.properties b/build.properties
> index 652d30f..b291a81 100644
> --- a/build.properties
> +++ b/build.properties
> @@ -27,14 +27,14 @@ bootstrap.classes.build.dir=${classes.build.dir}/bootstrap
> ant.classes.build.dir=${classes.build.dir}/ant
> optional.classes.build.dir=${classes.build.dir}/optional
> all.classes.build.dir=${classes.build.dir}/all
> -test.build.dir=${basedir}/build/test
> -artifacts.build.dir=${basedir}/build/artifact
> -distrib.dir=${basedir}/build/distrib
> -doc.build.dir=${basedir}/build/doc
> -reports.dir=${doc.build.dir}/reports
> -test.xml.dir=${build.dir}/test-report
> +test.build.dir=${build.dir}/test
> +artifacts.build.dir=${build.dir}/artifact
> +distrib.dir=${build.dir}/distrib
> +doc.build.dir=${build.dir}/doc
> +reports.dir=${build.dir}/reports
> +test.xml.dir=${reports.dir}/test/xml
> jacoco.log=${build.dir}/jacoco.data
> -test.report.dir=${reports.dir}/test
> +test.report.dir=${reports.dir}/test/html
> coverage.report.dir=${reports.dir}/coverage
> javadoc.build.dir=${reports.dir}/api
> ivy.report.dir=${reports.dir}/ivy
> 


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> 
> I’m now pick up the “Tutorials” section. 
> 
> 

I’ll take care of the last pages, "Reference/Introduction" and "Developper doc".

Nicolas


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 2 juil. 2017 à 07:23, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> 2017-07-01 18:56 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>>:
> 
>> 
>>> Le 1 juil. 2017 à 15:27, Gintautas Grigelionis <g.grigelio...@gmail.com>
>> a écrit :
>>> 
>>>> Probably a thing to improve are all the « since 2.x » annotations. Maybe
>>> we can have a macro for that, which will render everywhere the same, and
>>> which will be placed everywhere the same. Now sometimes it is at the
>>> beginning of the line, sometimes at the end, sometimes above. And I find
>> it
>>> being black bold a little too much.
>>> 
>>> Isn't that what CSS is for? ".ivy2x:before", anyone?
>> 
>> The thing is that we need to put at least some marker in the source. I
>> don’t know if this is possible for a paragraph.
>> 
> 
> [ivy2x]#paragraph# ?
> 
> 
>> And the « since » is used in different situation. Sometimes it is about
>> the whole page, sometimes about a feature in the page, sometimes about an
>> option (rendered as a row in a table). Might be difficult to do in CSS. But
>> if there is a working patch, I would be happy to apply it.
>> 
> 
> For starters, can we decide whether "since 2.x" should be enclosed in
> parentheses everywhere and whether the parentheses should be italicised?

Whatever we decide, if we have an automated way to generate it, then we can 
change it later.

> P.S. I'm planing to work on generics in core, then tackle SVG.
>> Otherwise, I
>>> can just push the new Ivy logo in SVG, so everybody could get used to the
>>> not-so-limbless ant :-)
>> 
>> The doc of the master branch is already using the SVG logo of Ant, and it
>> is shining on my high def screen.
> 
> 
> So you notice the contrast with the adjacent Ivy logo? :-) There are more
> SVGs waiting to be used, and, by the way, how about using SVGs/fonts in the
> navigation column (open/closed/bullet)?

I have no objection.

Nicolas

Re: Jenkins build is back to normal : IvyDE #319

[Nicolas Lalevée]

Finally.

But the build of resolve visualizer has been deactivated, the Zest plugins are 
not properly resolved by the build.

Nicolas

> Le 2 juil. 2017 à 12:01, 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: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 1 juil. 2017 à 15:27, Gintautas Grigelionis  a 
> écrit :
> 
>> Probably a thing to improve are all the « since 2.x » annotations. Maybe
> we can have a macro for that, which will render everywhere the same, and
> which will be placed everywhere the same. Now sometimes it is at the
> beginning of the line, sometimes at the end, sometimes above. And I find it
> being black bold a little too much.
> 
> Isn't that what CSS is for? ".ivy2x:before", anyone?

The thing is that we need to put at least some marker in the source. I don’t 
know if this is possible for a paragraph.

And the « since » is used in different situation. Sometimes it is about the 
whole page, sometimes about a feature in the page, sometimes about an option 
(rendered as a row in a table). Might be difficult to do in CSS. But if there 
is a working patch, I would be happy to apply it.

> P.S. I'm planing to work on generics in core, then tackle SVG. Otherwise, I
> can just push the new Ivy logo in SVG, so everybody could get used to the
> not-so-limbless ant :-)

The doc of the master branch is already using the SVG logo of Ant, and it is 
shining on my high def screen.

Nicolas


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 1 juil. 2017 à 15:31, Jaikiran Pai  a écrit :
> 
> 
> On 29-Jun-2017, at 11:29 AM, Jaikiran Pai  wrote:
> 
> 
>> I’m picking up “OSGi” section next.
> 
> I have completed and pushed the migration of “OSGi” and “Using standalone” 
> sections to upstream (it’s actually live on site since yesterday). For the 
> OSGi pages, I had to reword some of the content to fix the grammar of some of 
> the sections. Also, there were a few outdated links to external projects, 
> that I had to point to new locations. One such link is the “bnd” tool link. 
> Our earlier doc here[1] points to [2] as the “bnd” tool but that link is no 
> longer live. I updated the docs to point it to [3] but I haven’t yet verified 
> that the example being explained in that page works with this tool. In fact, 
> I’m not 100% sure this new bndtools project is the same the bnd tool since 
> the project page says it’s “based” on that older tool. Either way, I’ll have 
> to verify it later that that example works fine.

BndTools is the Eclipse plugin for Bnd. I guess the teams became so close that 
they join. Seems that the new link is this one:
http://bnd.bndtools.org/ 

Nicolas

Re: IVYDE-382 proposed patch

[Nicolas Lalevée]

Hi Alexander,

Yes, it would be really nice if you could create a page documenting the new 
feature.

I have just migrated the documentation of IvyDE to asciidoc, so it will be 
easier to contribute.
I have also squashed and rebased your work on this branch:
https://github.com/apache/ant-ivyde/tree/ivyDECredentials-cleaned 
<https://github.com/apache/ant-ivyde/tree/ivyDECredentials-cleaned>

To contribute you can create a pull request on this branch, we will get 
notified.

Cheers,
Nicolas


> Le 30 juin 2017 à 16:52, alexander.bl...@arctis.at a écrit :
> 
> Good afternoon, 
> 
> sorry for the delay in my reply. The last two weeks I was very busy with
> exams and work. 
> 
> We are glad that our proposed patch found its way back to the main
> development path and that perhaps it will be a part of a following
> release :-) 
> 
> Is there a way we can support you? 
> 
> Should we extend the official IvyDE doc by providing a more
> sophisticated description about the new feature (like you suggested in
> the previous mail)? 
> 
> Many greetings from Austria, 
> 
> Alexander 
> 
> Am 14.06.2017 23:56, schrieb Nicolas Lalevée:
> 
>> Hi,
>> 
>> For some reason git apply was refusing to process the patch and was just 
>> returning an error: corrupt patch at line 1964
>> 
>> So I played with git commands and work with the sources available on github.
>> I have create a branch on the ASF repo, ivyDECredentials, which has one 
>> commit which squash all the forked commit on github.
>> I have then created another branch, ivyDECredentials-cleaned, which rebase 
>> the work, remove unnecessary changes like the readme file, and did some file 
>> formatting.
>> 
>> Now it needs some review and testing in order to be merged. I'll take time 
>> to do it but if somebody else if wants to help, another pair of eyes on this 
>> is very welcomed.
>> 
>> Also would be welcomed some documentation about this new feature. The IvyDE 
>> doc is quite complete, it would be really nice to keep it at this level.
>> 
>> Nicolas
>> 
>>> Le 14 juin 2017 à 05:18, J Pai <jai.forums2...@gmail.com> a écrit :
>>> 
>>> Hi Alexander,
>>> 
>>> I actually just realized that your initial mail actually had a patch file 
>>> attached. I didn't notice that before and only today noticed it while 
>>> looking at the mail list archive. So assuming this applies cleanly on 
>>> latest master branch of IvyDE, I think this should be fine too, instead of 
>>> creating a PR. I am not experienced with Eclipse plugins, so I personally 
>>> won't be able to help much, but hopefully someone from the IvyDE team will 
>>> be able to review and decide about this patch. Thank you again for 
>>> contributing this.
>>> 
>>> -Jaikiran
>>> On 26-May-2017, at 8:28 AM, J Pai <jai.forums2...@gmail.com> wrote:
>>> 
>>> Hi Alexander,
>>> 
>>> Thank you for volunteering to provide this feature patch. I had a look a 
>>> the repo you pointed to and read the README. It does seem to contain a good 
>>> amount of work in that branch in multiple commits. 
>>> 
>>> To make it easier for whoever will decide about merging these to upstream 
>>> ant-ivyde project, would it to be possible for you to do the following:
>>> 
>>> 1. *Fork* the ant-ivyde project (on github) 
>>> https://github.com/apache/ant-ivyde/ into your account. There's a "Fork" 
>>> button on the right corner of the github page for the repo.
>>> 2. Once forked into your account, you can push your enhancement and bug fix 
>>> related commits to either your master branch of your repo or any specific 
>>> branch of your choice.
>>> - If the bug fixes are independent of the feature, then it would be good if 
>>> they are done in separate branches, so that a separate pull request (PR) 
>>> can be issued.
>>> 3. Once you are ready with the commits, you can then issue a pull request 
>>> (PR) from your repo to the "master" branch of the ant-ivyde upstream repo 
>>> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
>>> commits that are all specific to a single feature or for a specific bug fix.
>>> 
>>> Once the PRs are submitted, I'm sure one or more members of the development 
>>> team who have relevant knowledge of Eclipse and the project will review 
>>> this and either merge it or provide inputs.
>>> 
>>> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
&g

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

Thank you very much Gintas.

These PRs are huge, so they will take a little bit of time to process.

Also, in the PR 49 and 50 I can see a lot of commits [1] [2]. For a cleaner git 
history, could you rebase and squash them ? I don’t require to have one commit, 
for instance having the two commits in PR 48 is great. But in these two other 
PR, it seems a little bit noisy.
And does PR 50 depends on PR 49 ? I can see commits from one included in the 
other.

I bet these « noisy » commits are due to the conflicts generated by other 
commits. We can avoid these conflicts, and also avoid the work for you to 
resolve them: just tell us that you have some large commit incoming, and we 
will try to not modify much what you are working on.

Cheers,
Nicolas

[1] https://github.com/apache/ant-ivy/pull/49/commits 
<https://github.com/apache/ant-ivy/pull/49/commits>
[2] https://github.com/apache/ant-ivy/pull/50/commits 
<https://github.com/apache/ant-ivy/pull/50/commits>

> Le 1 juil. 2017 à 08:07, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> I opened a PR (well, actually two :-() to fix spelling and links that still
> point to configuration.
> 
> Gintas
> 
> 2017-06-30 18:44 GMT+02:00 Gintautas Grigelionis <g.grigelio...@gmail.com>:
> 
>> terminology.adoc apparently has an incorrect link on line 150,
>> configuration/statuses.html should be settings/statuses.html
>> (I get a redirect from http://ant.apache.org/ivy/
>> history/master/terminology.html)
>> 
>> Gintas
>> 
>> 2017-06-30 18:18 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:
>> 
>>> I have seen that you have qualified the source blocks, telling it is xml.
>>> Then I have done the same for the 'Ivy File' and 'Ant Tasks’ sections. And
>>> I enabled the highlightjs integration with acsiidoctor. I don’t find the
>>> default theme that cute (too lazy to search another one), but it is nicer
>>> than nothing :)
>>> I also seen some extended use of ‘code’ formatting, using ` in the
>>> asciidoc files. So I have done as well on the sections I have worked on.
>>> And I have put a little gray background color to improve the result. I hope
>>> it is not too invasive.
>>> 
>>> You can see the result on the site.
>>> 
>>> Probably a thing to improve are all the « since 2.x » annotations. Maybe
>>> we can have a macro for that, which will render everywhere the same, and
>>> which will be placed everywhere the same. Now sometimes it is at the
>>> beginning of the line, sometimes at the end, sometimes above. And I find it
>>> being black bold a little too much.
>>> 
>>> Nicolas
>>> 
>>>> Le 29 juin 2017 à 15:16, Jaikiran Pai <jai.forums2...@gmail.com> a
>>> écrit :
>>>> 
>>>> 
>>>> On 29-Jun-2017, at 3:58 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org>
>>> wrote:
>>>> 
>>>>> 
>>>>>> Le 29 juin 2017 à 07:59, Jaikiran Pai <jai.forums2...@gmail.com> a
>>> écrit :
>>>>>> 
>>>>>> A quick update on this one - I finished off the “settings” sections
>>> last week. There is only one pending item that I’m trying to address in
>>> that section. The “Settings” page[1] has a “Settings File Structure”
>>> section which tries to represent the Ivy settings XML file structure as a
>>> tree. We have a similar one, one place else too (in Ivy file page). We use
>>> a source code block to represent it. However, Asciidoc source code blocks
>>> are rendered literally, so it won’t show up the links (as you’ll see in
>>> that page[1] currently). For the Ivy page, I used “lists” to render the
>>> structure and that was “good enough"[2]. However, I can’t use the same here
>>> since Asciidoc (backed by asciidoctor generator) allows a max list depth of
>>> 5 which means that any nested elements that exceed that depth won’t be
>>> rendered correctly as a tree. The settings file structure goes beyond that
>>> depth limit so it doesn’t work out well here.
>>>>>> 
>>>>>> Ultimately, we either have to remove that section (there’s already a
>>> “Child elements” section which _almost_ conveys the same thing) or come up
>>> with a custom asciidoc “tree” kind of block element to render this. Any
>>> thoughts?
>>>>> 
>>>>> If I count correctly, there are 6 levels. So could we just remove the
>>> root element from the tree so we save one level ? The root would be just
>>> printed as some text. Could it then display correctly ?
>>>>> 
>>>> 
>>>> That suggestion actually worked well. I went ahead and did that change
>>> and regenerated the latest “master” site. It looks good
>>> http://ant.apache.org/ivy/history/master/settings.html.
>>>> 
>>>> -Jaikiran
>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>>>> For additional commands, e-mail: dev-h...@ant.apache.org
>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>>> For additional commands, e-mail: dev-h...@ant.apache.org
>>> 
>>> 
>> 

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

I have seen that you have qualified the source blocks, telling it is xml. Then 
I have done the same for the 'Ivy File' and 'Ant Tasks’ sections. And I enabled 
the highlightjs integration with acsiidoctor. I don’t find the default theme 
that cute (too lazy to search another one), but it is nicer than nothing :)
I also seen some extended use of ‘code’ formatting, using ` in the asciidoc 
files. So I have done as well on the sections I have worked on. And I have put 
a little gray background color to improve the result. I hope it is not too 
invasive.

You can see the result on the site.

Probably a thing to improve are all the « since 2.x » annotations. Maybe we can 
have a macro for that, which will render everywhere the same, and which will be 
placed everywhere the same. Now sometimes it is at the beginning of the line, 
sometimes at the end, sometimes above. And I find it being black bold a little 
too much.

Nicolas

> Le 29 juin 2017 à 15:16, Jaikiran Pai <jai.forums2...@gmail.com> a écrit :
> 
> 
> On 29-Jun-2017, at 3:58 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
>> 
>>> Le 29 juin 2017 à 07:59, Jaikiran Pai <jai.forums2...@gmail.com> a écrit :
>>> 
>>> A quick update on this one - I finished off the “settings” sections last 
>>> week. There is only one pending item that I’m trying to address in that 
>>> section. The “Settings” page[1] has a “Settings File Structure” section 
>>> which tries to represent the Ivy settings XML file structure as a tree. We 
>>> have a similar one, one place else too (in Ivy file page). We use a source 
>>> code block to represent it. However, Asciidoc source code blocks are 
>>> rendered literally, so it won’t show up the links (as you’ll see in that 
>>> page[1] currently). For the Ivy page, I used “lists” to render the 
>>> structure and that was “good enough"[2]. However, I can’t use the same here 
>>> since Asciidoc (backed by asciidoctor generator) allows a max list depth of 
>>> 5 which means that any nested elements that exceed that depth won’t be 
>>> rendered correctly as a tree. The settings file structure goes beyond that 
>>> depth limit so it doesn’t work out well here.
>>> 
>>> Ultimately, we either have to remove that section (there’s already a “Child 
>>> elements” section which _almost_ conveys the same thing) or come up with a 
>>> custom asciidoc “tree” kind of block element to render this. Any thoughts?
>> 
>> If I count correctly, there are 6 levels. So could we just remove the root 
>> element from the tree so we save one level ? The root would be just printed 
>> as some text. Could it then display correctly ?
>> 
> 
> That suggestion actually worked well. I went ahead and did that change and 
> regenerated the latest “master” site. It looks good 
> http://ant.apache.org/ivy/history/master/settings.html.
> 
> -Jaikiran
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 29 juin 2017 à 07:59, Jaikiran Pai <jai.forums2...@gmail.com> a écrit :
> 
> A quick update on this one - I finished off the “settings” sections last 
> week. There is only one pending item that I’m trying to address in that 
> section. The “Settings” page[1] has a “Settings File Structure” section which 
> tries to represent the Ivy settings XML file structure as a tree. We have a 
> similar one, one place else too (in Ivy file page). We use a source code 
> block to represent it. However, Asciidoc source code blocks are rendered 
> literally, so it won’t show up the links (as you’ll see in that page[1] 
> currently). For the Ivy page, I used “lists” to render the structure and that 
> was “good enough"[2]. However, I can’t use the same here since Asciidoc 
> (backed by asciidoctor generator) allows a max list depth of 5 which means 
> that any nested elements that exceed that depth won’t be rendered correctly 
> as a tree. The settings file structure goes beyond that depth limit so it 
> doesn’t work out well here.
> 
> Ultimately, we either have to remove that section (there’s already a “Child 
> elements” section which _almost_ conveys the same thing) or come up with a 
> custom asciidoc “tree” kind of block element to render this. Any thoughts?

If I count correctly, there are 6 levels. So could we just remove the root 
element from the tree so we save one level ? The root would be just printed as 
some text. Could it then display correctly ?
If it is too weird, let’s remove that section; the tree is shown in the toc so 
I guess it is OK.

> By the way, I consider the settings section to be “done” in terms of 
> migration. If anyone however notices any discrepancies while doing a quick 
> review of the rendered pages, feel free to drop a mail.
> 
> I’m picking up “OSGi” section next.

And I have done the Ivy files, I’ll review the Ant Tasks section now.

Nicolas

> 
> [1] 
> https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/lastSuccessfulBuild/artifact/build/doc/settings.html
> [2] See “Hierarchical Index” section at 
> https://builds.apache.org/view/A/view/Ant/job/Ivy-NightlyDistribution/lastSuccessfulBuild/artifact/build/doc/ivyfile.html
> 
> -Jaikiran
> 
> On 24-Jun-2017, at 7:18 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
>> 
>>> 
>>> And just an idea: since there are a lot of pages, maybe we could organize a 
>>> review at many, without useless double checks. I see 4 big parts in the 
>>> doc: the ant tasks, the pages related to the ivy file, the pages related to 
>>> the ivysettings, and the other pages. If 4 volunteers can do a quick review 
>>> of each page, I think we can be pretty confident that we didn’t leave any 
>>> ugliness somewhere. The goal wouldn’t to do a fine grain review, but ensure 
>>> that everything is readable. wdyt ?
>>> 
>> 
>> Sounds a good idea. I’ll start off with the “Settings” which relates to the 
>> Ivy settings file.
> 
> Great. I’ll take care of « Ivy Files ».
> 
> 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: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Le 29 juin 2017 à 07:48, Jaikiran Pai <jai.forums2...@gmail.com> a écrit :
> 
> 
> On 25-Jun-2017, at 8:27 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
>> I have made the Ivy Job also build the snapshot-bin, like the nightly. Maybe 
>> now the nightly is redundant.
> 
> 
> I think yes, the nightly job is now probably redundant - which is fine, we 
> can always direct users to this new job for the latest snapshots. The only 
> way this job differs from the nightly one now is that the nightly one 
> currently publishes the latest (site) docs too. I guess that’s not a big 
> thing since we will soon be publishing the latest site docs live on the Ant 
> site (under the “master” section).

I have done that. For some reason it took a very long time to get actually 
published, but it is there now:
http://ant.apache.org/ivy/history/master/index.html 
<http://ant.apache.org/ivy/history/master/index.html>

I have also update the doc about the site:
http://svn.apache.org/repos/asf/ant/site/README.txt 
<http://svn.apache.org/repos/asf/ant/site/README.txt>

Nicolas

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Dropins (or "drops" as they're called in the distributions) is what IvyDE
> builds were based on all the time. I am still confounded why it worked
> before and stopped working now. Yet, reading the documentation I became
> convinced that the dropins must be unpacked in another location. So I just
> wanted to apologize for an erroneous suggestion and share some information
> in order for it to be independently confirmed. I may open a PR, but since
> you're working on this, I assumed that you could move faster than me.

Actually I am not looking into it at the present time. I’ll get into it at some 
point, if it is not fixed before. So if you think you can solve this, I’ll 
welcome your help.

On the side note, I am now an Intellij user, I only start Eclipse to build 
IvyDE. And I haven’t done Eclipse plugin development in years, so I am not 
fast. :)

> There's another issue to be resolved for local builds to work hassle-free
> -- currently, they need an environment variable BUILD_NUMBER set up by
> Jenkins.

Is it required ? This env variable is only needed when calling the jenkins 
target. In a dev environment we shouldn't call them.

I think in this mailing list we told to run some jenkins target to make easier 
the setup of the dev environment. But it as actually to call the targets which 
download and setup Eclipse. That’s why I renamed them, so we should continue to 
make the proper distinction to the tweaks for Jenkins, and the dev targets.

Nicolas

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Le 26 juin 2017 à 07:46, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> If I understand the process correctly, Jenkins executes "ant
> prepare-jenkins" first, which does not work locally any more, because the
> property used to figure out where to get Ivy jar from is set to an empty
> string. I wondered what was the reason for that change. Actually, when I
> look at it again, the change is even more drastic. Previously,
> "hudson-install-ivy" would depend on both "hudson-install-ivy-jar" (setting
> "ivy.jar.url") and "hudson-install-ivy-release" (setting "ivy.version" if
> "hudson.ivy.jar.url" was not available). In addition, "baseLocation" was
> set. The new target "jenkins-install-ivy" does not make sense to me.

This is because of the change in the configuration of Jenkins Job, as I briefly 
explained in the first mail. Now the Ivy artifact is not downloaded via an url, 
there is a Jenkins plugin, a build step, which handle the copy of the 
artifacts. Relying on this internal copy of artifact seems more stable that 
relying on a http/https url. The jenkins-install-ivy target is then calling 
install-ivy with a path rather than an url.

Now the jenkins-* targets are really dedicated to being ran on jenkins and are 
not suited for a local environment. That is why I renamed the targets to 
download and setup an eclipse, removing the jenkins- prefix: these can be used 
in a dev environment.
If you do that: ant prepare-eclipse
And do the install: ant install-ivy 
-Divy.jar.url=https://builds.apache.org/view/A/view/Ant/job/Ivy/lastSuccessfulBuild/artifact/build/artifact/jars/ivy.jar
Then you will be able to reproduce the issue. At least I can.

> In the next step, Jenkins executes "ant dist checkstyle rat" which fails
> because of "missing" Eclipse plugins. That is apparently caused by dropins
> being unpacked in the wrong place in the first build stage
> ("prepare-jenkins"). In my first suggestion, I was obviously wrong about
> what that place should be. I do recall using getting Eclipse to work
> locally with an older IvyDE build.xml, but I did not document whether that
> involved any extra steps. However, Eclipse is able to bootstrap itself
> locally when dropins are unpacked in "dropins" directory, see Eclipse
> documentation [1]. That's what the patch is for.

I don’t have much experience with using dropins, so if you think this will help 
make the build more stable, you’re welcomed to open a PR.

Nicolas

> 
> Gintas
> 
> [1] https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins
> 
> 
> 2017-06-25 22:27 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>:
> 
>> 
>>> I am sorry, my memory of what I was doing back in December is incorrect.
>>> I guess I somehow updated
>>> configuration/org.eclipse.equinox.simpleconfigurator/bundles.info or did
>>> something else.
>>> Luckily, there's a simpler way, the dropins should go into their own
>>> special directory, which needs the following change
>>> 
>>> --- a/build.xml
>>> +++ b/build.xml
>>> @@ -555,11 +555,11 @@ You have to specify the Ivy to install with one of
>>> the following property:
>>>> failonerror="false"
>>> />
>>>>> failonerror="false" />
>>>>> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>>>> tofile="${basedir}/dependencies/${eclipse.download.sdk.name}" />
>>>
>> 
>> I don’t understand what you are suggesting. The issue at hand is resolving
>> the Ivy jar. The suggested patch is about installing eclipse plugins in
>> dropins. But the build is still not finding the ivy plugin.
>> 
>>> I don't understand why "jenkins-prepare" (neé "hudson-prepare") would
>> skip
>>> "download-ivy" (because "jenkins-install-ivy" sets ivy.jar.url to ""
>> rather
>>> than ${hudson.ivy.jar.url}) and fail?
>> 
>> Again, sorry, but I don’t understand what you are talking about. Are you
>> seing the same error as the one Jenkins is showing ? The error is occurring
>> with the eclipse build started, way later.
>> 
>> 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: [1/5] ant-ivy git commit: set copyright to 2017

[Nicolas Lalevée]

> Le 26 juin 2017 à 08:15, Matèrne, Jan (RZF, Ref 410)  
> a écrit :
> 
> Would it be better to insert the actual year to the generation process?

It can certainly be done. There is some ruby code involved, so I guess this is 
doable.

> If I remember right Stefan had changed the site templates regarding the 
> license link (.../ instead of .../LICENSE-2.0.txt).
> Should we use that link here too?

Yep, good idea. Done.

Nicolas

> 
> cheers
> Jan
> 
> -Ursprüngliche Nachricht-
> Von: hi...@apache.org  [mailto:hi...@apache.org 
> ] 
> Gesendet: Sonntag, 25. Juni 2017 01:09
> An: notificati...@ant.apache.org 
> Betreff: [1/5] ant-ivy git commit: set copyright to 2017
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/97c24fdd/asciidoc/templates/document.html.slim
> --
> diff --git a/asciidoc/templates/document.html.slim 
> b/asciidoc/templates/document.html.slim
> index 41d344a..637affb 100644
> --- a/asciidoc/templates/document.html.slim
> +++ b/asciidoc/templates/document.html.slim
> @@ -76,7 +76,7 @@ html lang=(attr :lang, 'en' unless attr? :nolang)
>   div id="footer-message" class="footer"
> hr/
> i
> -  | Copyright  2014 The Apache Software Foundation, Licensed 
> under the
> +  | Copyright  2017 The Apache Software Foundation, Licensed 
> under the
>   a href="http://www.apache.org/licenses/LICENSE-2.0.txt; Apache 
> License, Version 2.0
>   | .
> br/
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org 
> 
> For additional commands, e-mail: dev-h...@ant.apache.org 
> 

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> I am sorry, my memory of what I was doing back in December is incorrect.
> I guess I somehow updated
> configuration/org.eclipse.equinox.simpleconfigurator/bundles.info or did
> something else.
> Luckily, there's a simpler way, the dropins should go into their own
> special directory, which needs the following change
> 
> --- a/build.xml
> +++ b/build.xml
> @@ -555,11 +555,11 @@ You have to specify the Ivy to install with one of
> the following property:
>  />
>  failonerror="false" />
>  dest="${basedir}/dependencies/" />
> - dest="${basedir}/dependencies/" />
> - dest="${basedir}/dependencies/" />
> - dest="${basedir}/dependencies/" />
> - dest="${basedir}/dependencies/" />
> - src="${basedir}/dependencies/${eclipse.download.zest.name}.zip"
> dest="${basedir}/dependencies/" />
> + dest="${basedir}/dependencies/eclipse/dropins" />
> + dest="${basedir}/dependencies/eclipse/dropins" />
> + dest="${basedir}/dependencies/eclipse/dropins" />
> + dest="${basedir}/dependencies/eclipse/dropins" />
> + src="${basedir}/dependencies/${eclipse.download.zest.name}.zip"
> dest="${basedir}/dependencies/eclipse/dropins" />
>  tofile="${basedir}/dependencies/${eclipse.download.sdk.name}" />
> 

I don’t understand what you are suggesting. The issue at hand is resolving the 
Ivy jar. The suggested patch is about installing eclipse plugins in dropins. 
But the build is still not finding the ivy plugin.

> I don't understand why "jenkins-prepare" (neé "hudson-prepare") would skip
> "download-ivy" (because "jenkins-install-ivy" sets ivy.jar.url to "" rather
> than ${hudson.ivy.jar.url}) and fail?

Again, sorry, but I don’t understand what you are talking about. Are you seing 
the same error as the one Jenkins is showing ? The error is occurring with the 
eclipse build started, way later.

Nicolas


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

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Le 25 juin 2017 à 16:57, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
> :
> 
> Hi,
> 
> I worked on the Jenkins jobs to make them work.
> 
> There was some issues with job dependencies. Following the instructions there 
> [1] worked.

Then didn’t worked…
Setting the Authorization to « Run as User who Triggered Build » seems to only 
works when triggered manually, not by the cron. So now I have set « Run as 
Specific User », me, « hibou ». It now works with the cron. Most probably for 
me manually too. But maybe not for anybody else…

Nicolas


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

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Le 25 juin 2017 à 17:50, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> [3]: the path looks wrong, it starts with "\:\:\ »

I have seen that too.

> [2]: please check that unpacking of drops puts files into the correct
> places (the contents should go into "features" and "plugins" directories of
> PDE).

I have done that already. I even checked that the placed in the plugins 
directory have the proper OSGi metadata. It is reproductible locally if you 
wish to debug and suggest a fix.

Nicolas

> 
> Gintas
> 
> 2017-06-25 16:57 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>>:
> 
>> Hi,
>> 
>> I worked on the Jenkins jobs to make them work.
>> 
>> There was some issues with job dependencies. Following the instructions
>> there [1] worked.
>> I have made the Ivy Job also build the snapshot-bin, like the nightly.
>> Maybe now the nightly is redundant.
>> I made the Ivy-checks build work, some https changed in favor of http.
>> The test matrix is now separated into two builds now, since no Ant
>> installation is common for both Windows and Ubuntu. They are both testing
>> JDK7 and JDK8.
>> The IvyDE job is no longer downloading Ivy’s jar via a hard coded http
>> url. It is relying now on a plugin which copies artifacts around.
>> 
>> There are still some error though, most probably not related to the
>> Jenkins configuration:
>> - the Windows build of Ivy is broken, the retrieve doesn’t work [2].
>> - the IvyDE is failing to resolve the OSGi metadata of Ivy [3]. It is
>> reproductible locally.
>> 
>> I’ll look at the IvyDE updatesite job when the build of IvyDE will be
>> fixed.
>> 
>> Nicolas
>> 
>> [1] https://cwiki.apache.org/confluence/display/INFRA/Job+Authorization <
>> https://cwiki.apache.org/confluence/display/INFRA/Job+Authorization 
>> <https://cwiki.apache.org/confluence/display/INFRA/Job+Authorization>>
>> [2] https://builds.apache.org/job/Ivy-tests-Windows/OS=Windows 
>> <https://builds.apache.org/job/Ivy-tests-Windows/OS=Windows>,
>> jdk=JDK%201.7%20(latest)/2/console <https://builds.apache.org/ 
>> <https://builds.apache.org/>
>> job/Ivy-tests-Windows/OS=Windows,jdk=JDK%201.7%20(latest)/2/console>
>> [3] https://builds.apache.org/job/IvyDE/315/console 
>> <https://builds.apache.org/job/IvyDE/315/console> <
>> https://builds.apache.org/job/IvyDE/315/console 
>> <https://builds.apache.org/job/IvyDE/315/console>>

Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

Hi,

I worked on the Jenkins jobs to make them work.

There was some issues with job dependencies. Following the instructions there 
[1] worked.
I have made the Ivy Job also build the snapshot-bin, like the nightly. Maybe 
now the nightly is redundant.
I made the Ivy-checks build work, some https changed in favor of http.
The test matrix is now separated into two builds now, since no Ant installation 
is common for both Windows and Ubuntu. They are both testing JDK7 and JDK8.
The IvyDE job is no longer downloading Ivy’s jar via a hard coded http url. It 
is relying now on a plugin which copies artifacts around.

There are still some error though, most probably not related to the Jenkins 
configuration:
- the Windows build of Ivy is broken, the retrieve doesn’t work [2].
- the IvyDE is failing to resolve the OSGi metadata of Ivy [3]. It is 
reproductible locally.

I’ll look at the IvyDE updatesite job when the build of IvyDE will be fixed.

Nicolas

[1] https://cwiki.apache.org/confluence/display/INFRA/Job+Authorization 

[2] 
https://builds.apache.org/job/Ivy-tests-Windows/OS=Windows,jdk=JDK%201.7%20(latest)/2/console
 

[3] https://builds.apache.org/job/IvyDE/315/console 

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> 
>> 
>> And just an idea: since there are a lot of pages, maybe we could organize a 
>> review at many, without useless double checks. I see 4 big parts in the doc: 
>> the ant tasks, the pages related to the ivy file, the pages related to the 
>> ivysettings, and the other pages. If 4 volunteers can do a quick review of 
>> each page, I think we can be pretty confident that we didn’t leave any 
>> ugliness somewhere. The goal wouldn’t to do a fine grain review, but ensure 
>> that everything is readable. wdyt ?
>> 
> 
> Sounds a good idea. I’ll start off with the “Settings” which relates to the 
> Ivy settings file.

Great. I’ll take care of « Ivy Files ».

Nicolas


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

Re: Ivy jobs on Teamcity need reconfiguring

[Nicolas Lalevée]

> Le 19 juin 2017 à 13:02, Stefan Bodewig  a écrit :
> 
> On 2017-06-19, Jaikiran Pai wrote:
> 
>> I was reading up some docs and happened to find this page
>> http://ant.apache.org/nightlies.html which lists the Ant/Ivy
>> jobs. Turns out we also have Teamcity builds for Ivy and they have
>> been failing since we moved to Java 1.7[1].
> 
> Are we maintaining the job ourselves? Jan, have you got access to the
> credentials?

The credentials have been shared the 23 september 2008 on ant-private.

> Is this job doing anything that we couldn't do with builds.apache.org by
> now?

I don’t think so.

Nicolas


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 19 juin 2017 à 08:30, Jan Matèrne (jhm)  a écrit :
> 
> Doc's mentioning 'how to document' must be updated.
> I found http://ant.apache.org/ivy/write-doc.html Some more?

This is the only page which explain xooki I know.

Nicolas

> 
> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
>> Gesendet: Montag, 19. Juni 2017 04:52
>> An: Ant Developers List
>> Betreff: Ivy - we have now moved to asciidoc for docs
>> 
>> The documentation for ant-ivy project has now been migrated to
>> asciidoc. The migration used a tool developed by Nicolas to migrate the
>> xooki backed HTML docs to asciidoc. This tool auto-generated the
>> asciidoc text and for most part no other changes were needed. However,
>> there are some fixes the generated asciidoc will need which I’m doing
>> and will continue to do in the coming days to fix any issues with the
>> generated doc. Once the fixes are done, soon, we’ll remove the xooki
>> backed documentation completely from our git repo. For now though, any
>> new documentation or changes should go into the asciidoc files.
>> 
>> -Jaikiran
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
>> commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 19 juin 2017 à 04:52, Jaikiran Pai  a écrit :
> 
> The documentation for ant-ivy project has now been migrated to asciidoc. The 
> migration used a tool developed by Nicolas to migrate the xooki backed HTML 
> docs to asciidoc. This tool auto-generated the asciidoc text and for most 
> part no other changes were needed. However, there are some fixes the 
> generated asciidoc will need which I’m doing and will continue to do in the 
> coming days to fix any issues with the generated doc. Once the fixes are 
> done, soon, we’ll remove the xooki backed documentation completely from our 
> git repo. For now though, any new documentation or changes should go into the 
> asciidoc files.

I did a general grep about finding non translated html markup, and I have 
cleaned the ones I have found.
I have pushed the result here: http://people.apache.org/~hibou/doc/ 


Probably we can start pushing it to the site, since there is section dedicated 
to the trunk version of the doc (which should be probably renamed master).
http://ant.apache.org/ivy/history/trunk/index.html 

It would be an opportunity to get an idea of what would it mean when a release 
will happen.

I have noticed one bug in the generation of the toc. There is notion of 
abstract node, which has a title but no link, it shouldn’t be clickable. But 
for instance the node at Reference/Introduction is clickable, and sends to the 
home. This should be fixed. I mentioning it if somebody wants to look at it, 
before me. 

And just an idea: since there are a lot of pages, maybe we could organize a 
review at many, without useless double checks. I see 4 big parts in the doc: 
the ant tasks, the pages related to the ivy file, the pages related to the 
ivysettings, and the other pages. If 4 volunteers can do a quick review of each 
page, I think we can be pretty confident that we didn’t leave any ugliness 
somewhere. The goal wouldn’t to do a fine grain review, but ensure that 
everything is readable. wdyt ?

Nicolas

Re: Process for handling GitHub PRs and closing them

[Nicolas Lalevée]

> Le 19 juin 2017 à 05:14, Jaikiran Pai  a écrit :
> 
> We have (read only) github repos which back our main ASF git repos (consider 
> the github ant-ivy repo which is a read-only mirror of ASF git repo). Users 
> submit pull requests to our github repos and the process I follow for merging 
> such PRs is the “rebase” approach which looks something like this:
> 
> 
> - Fetch the PR locally (git fetch github pull/45/head:pr-45)
> - Checkout to that branch locally (git checkout pr-45)
> - Rebase that PR on top of latest ASF (upstream) repo (git rebase asf/master)
> - Run a short build, verify and push to ASF repo (git push asf pr-45:master)
> 
> (assume 45 is the pull request id).
> 
> So essentially, I rebase the commits from the PR on top of the latest master 
> and then push to the ASF repos. All this works fine and the ASF repos get 
> those changes. However, this doesn’t “close” the pull request on github.
> 
> Apparently, the way to have the pull request closed is doing a actual “merge” 
> of the pull request commits into the ASF repo instead of rebasing the 
> commits. 
> 
> Then the other approach, which isn’t that clean IMO, is to push a commit to 
> the ASF repo with a commit message which includes “This closes #X” where X is 
> the pull request id. The ASF github bot then notices this commit messages and 
> goes and closes the open PR. 
> 
> I usually prefer the rebase approach (the one I outlined above) for dealing 
> with pull requests, since it gives a clean git commit tree. But clearly that 
> doesn’t have a way to close the PR. 
> 
> Is there any preferred approach that we should follow with PRs?

I agree with the approach you have. I have been lazy though, I just use the 
command line suggested in the email notifications, which makes things quite 
straight forward.

I would just insist on trying to get the PR closed. Even if it may pollute the 
commit log, we should put the "This closes #X" message. And it can be viewed as 
a marker, just like we do with Jira. Also, we could make thing more explicit by 
specifying the full path of the github project: « closes apache/ant-ivy#123 ».
See the github documentation about it: 
https://help.github.com/articles/closing-issues-via-commit-messages/ 

> The other thing I had in mind, if we agree upon, is to have an enhancement 
> raised with the ASF infra team to allow adding some specific comment on the 
> open PR by a *committer* which then auto-closes the PR. Some comment like 
> “This PR is merged”.

I don’t think the ASF infra team can do something about it. The « This closes 
#x » is something that is supported by every github repository, this is not 
specific to the mirrored ASF repos.
Probably a simpler and better integration with github would be to make the PR 
tracker editable to ASF committers. And probably both github and asf teams have 
heard about that.

Nicolas

Re: new committer: Jaikiran Pai

[Nicolas Lalevée]

Welcome Jaikiran!

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

Nicolas

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


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

Re: IvyDE JIRA issues and changes for proposed release?

[Nicolas Lalevée]

> Le 14 juin 2017 à 05:22, J Pai  a écrit :
> 
> There’s been some good progress on reviving the Ivy project (thanks Nicolas 
> and Jan for helping out with the reviews and merging PRs) and we seem to be 
> moving towards a state where the release is a possibility. The other project 
> IvyDE (the Eclipse plugin) however needs a bit more push I think. 
> 
> I am not a Eclipse user nor do I have any experience with plugin development, 
> so there’s not much I can contribute on that front. However, there has been 
> an external community member whose team(?) seemed to be interested in 
> contributing to that plugin and in fact seem to have built some features on 
> top of the current state of the plugin, in their own fork. They even proposed 
> the contribution on the mailing list[1]. I suggested they raise a PR (to make 
> it easier for review), but haven’t heard back. Given that and things in 
> general, do we have someone who has experience of the code base plus Eclipse 
> plugins who can help review that code? Furthermore, is there anything else 
> the user has to do (like signing some CLA) for that contribution?

For a patch, due to its form, sending to the community a request for change, it 
is implied that it is a donation to the ASF with proper copyrights, so it is 
OK. I might be an issue if a contribution is only declared to be elsewhere (« 
look at my branch on github»). Sending a patch via email, jira or a PR is 
considered OK.
And the CLA is mainly for the people directly contributing.

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

As for Ivy, I am volunteering to apply patches. For what to release, when, how, 
I am relying on the community to drive it.

There is one topic that I will probably push though, on both Ivy and IvyDE; and 
the site: migrating to asciidoc. The migration I have wrote took me some time 
and is a kind of big hack. So the sooner the migration will be done, the sooner 
contributing documentation will be easier.

Nicolas


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

Re: IVYDE-382 proposed patch

[Nicolas Lalevée]

Hi,

For some reason git apply was refusing to process the patch and was just 
returning an error: corrupt patch at line 1964

So I played with git commands and work with the sources available on github.
I have create a branch on the ASF repo, ivyDECredentials, which has one commit 
which squash all the forked commit on github.
I have then created another branch, ivyDECredentials-cleaned, which rebase the 
work, remove unnecessary changes like the readme file, and did some file 
formatting.

Now it needs some review and testing in order to be merged. I’ll take time to 
do it but if somebody else if wants to help, another pair of eyes on this is 
very welcomed.

Also would be welcomed some documentation about this new feature. The IvyDE doc 
is quite complete, it would be really nice to keep it at this level.

Nicolas

> Le 14 juin 2017 à 05:18, J Pai  a écrit :
> 
> Hi Alexander,
> 
> I actually just realized that your initial mail actually had a patch file 
> attached. I didn’t notice that before and only today noticed it while looking 
> at the mail list archive. So assuming this applies cleanly on latest master 
> branch of IvyDE, I think this should be fine too, instead of creating a PR. I 
> am not experienced with Eclipse plugins, so I personally won’t be able to 
> help much, but hopefully someone from the IvyDE team will be able to review 
> and decide about this patch. Thank you again for contributing this.
> 
> -Jaikiran
> On 26-May-2017, at 8:28 AM, J Pai  wrote:
> 
> Hi Alexander,
> 
> Thank you for volunteering to provide this feature patch. I had a look a the 
> repo you pointed to and read the README. It does seem to contain a good 
> amount of work in that branch in multiple commits. 
> 
> To make it easier for whoever will decide about merging these to upstream 
> ant-ivyde project, would it to be possible for you to do the following:
> 
> 1. *Fork* the ant-ivyde project (on github) 
> https://github.com/apache/ant-ivyde/ into your account. There’s a “Fork” 
> button on the right corner of the github page for the repo.
> 2. Once forked into your account, you can push your enhancement and bug fix 
> related commits to either your master branch of your repo or any specific 
> branch of your choice.
>   - If the bug fixes are independent of the feature, then it would be 
> good if they are done in separate branches, so that a separate pull request 
> (PR) can be issued.
> 3. Once you are ready with the commits, you can then issue a pull request 
> (PR) from your repo to the “master” branch of the ant-ivyde upstream repo 
> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
> commits that are all specific to a single feature or for a specific bug fix.
> 
> Once the PRs are submitted, I’m sure one or more members of the development 
> team who have relevant knowledge of Eclipse and the project will review this 
> and either merge it or provide inputs.
> 
> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
> while and with contributions like these, we should be able to release out a 
> new version soon.
> 
> -Jaikiran
> 
> 
> On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:
> 
> Dear Sir or Madam,
> 
> as it was suggested in 
> https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
>  we are sending you our proposed patch for 
> https://issues.apache.org/jira/browse/IVYDE-382. The corresponding patch-file 
> is attached to this email. The source code is available at 
> https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the branch 
> "ivyDECredentials". 
> 
> Yours sincerely,
> 
> Alexander Blaas
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

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

[Nicolas Lalevée]

LGTM
+1 for this release

Nicolas

> Le 8 juin 2017 à 13:45, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> third attempt :-)
> 
> I've created a new release candidate for Compress Antlib 1.5, this time
> the source distribution should contain everything needed to build.
> 
> git tag: 1_5_RC3
> on commit: 3194691
> tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
>  revision: 19936
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapacheant-1019/org/apache/ant/ant-compress/1.5/
> 
> This Vote will be open at least for 72 hours and close no earlier than
> 2017-06-11 12: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] Release Compress Antlib 1.5 based on RC2

[Nicolas Lalevée]

-1 for me.

The source didn’t build since it was missing two files, the build.properties 
which setup the build to use Java 7, and the ivy.xml which declares the 
dependencies the build is relying on.
I pushed a fix to common. This is the first time use use git submodules, so I 
hope I have done it right.

I have also noticed that for some reason the git-checkouted sources differs 
from the targzed ones, because of some new lines at the end of file. Nothing of 
worry but I push to git a fix.

Nicolas

> Le 1 juin 2017 à 18:55, Stefan Bodewig  a écrit :
> 
> Hi all
> 
> I've created a new release candidate for Compress Antlib 1.5, this time
> with working Ivy coordinates and a release date three days into the
> future.
> 
> git tag: 1_5_RC2
> on commit: f20847d
> tarballs: https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
>  revision: 19857
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapacheant-1018/org/apache/ant/ant-compress/1.5/
> 
> This Vote will be open at least for 72 hours and close no earlier than
> 2017-06-04 17:00UTC.
> 
> Cheers
> 
>Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

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

[Nicolas Lalevée]

> Le 2 juin 2017 à 12:05, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> So that does mean cachefileset has a role to play in at least some cases. In 
> that case, I think the approach we could take is to _not_ deprecate it and 
> instead include this limitation as part of the documentation *and* enhance 
> the code of this task to explicit fail with a proper error when it can’t 
> determine a common base directory.
> 

Sounds good to me.

Nicolas


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


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

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

[Nicolas Lalevée]

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

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

Nicolas

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


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

Re: Release notes for IVY-1528

[Nicolas Lalevée]

done.

Thanks
Nicolas

> Le 1 juin 2017 à 13:46, J Pai  a écrit :
> 
> The PR for this issue https://issues.apache.org/jira/browse/IVY-1528 was 
> merged a few days back, but I think we forgot to resolve the JIRA and include 
> this in the release notes. Can someone with the access rights please do so?
> 
> -Jaikiran
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 19:47, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> I looked at the documentation: both
> http://ant.apache.org/ivy/history/trunk/tutorial/start.html 
> <http://ant.apache.org/ivy/history/trunk/tutorial/start.html> and
> https://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html 
> <https://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html>
> have black rectangles.

There should be the logs generated automatically there. These logs are 
generated by the task generate-tutorial-output in the build-release.xml in the 
sources of Ivy.

I think the way we generate the website is incorrect regarding these logs, 
because building the site is only about calling xooki, not generate the 
tutorial logs. Hence the empty black rectangles. This need to be reviewed.
Probably while migrating to asciidoc, we should do like Matt suggested. When 
releasing, also do a build of the doc, which will include the generation of the 
logs of the tutorial, and then push manually the doc into the svn of the site.

> Also, external links must be pruned and/or directed to Internet Archive :-(
> The tutorial of yEd must be revised, version 3 has many more controls. I
> converted the odg diagrams to svg, and started looking at Ivy report/yEd
> screenshots. The original Ivy logo is unfortunately too low resolution for
> simple tracing :-( Is this all there is?

The only version of the logo we have is in the svn.

Nicolas

> 
> Gintas
> 
> 2017-05-31 18:20 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>>:
> 
>> 
>>> Le 31 mai 2017 à 17:53, J Pai <jai.forums2...@gmail.com 
>>> <mailto:jai.forums2...@gmail.com>> a écrit :
>>> 
>>> 
>>> On 31-May-2017, at 9:02 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org 
>>> <mailto:nicolas.lale...@hibnet.org>
>> <mailto:nicolas.lale...@hibnet.org <mailto:nicolas.lale...@hibnet.org>>> 
>> wrote:
>>> 
>>> 
>>>> Le 31 mai 2017 à 15:34, J Pai <jai.forums2...@gmail.com> a écrit :
>>>> 
>>>> One thing I just noticed in the generated adoc files is that “external”
>> links that are part of the original xooki backed .html files are not being
>> generated as links in the converted adoc. To see a couple of example, take
>> a look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache
>> License” in this sentence:
>>>> 
>>>>> Ivy is open source and released under a very permissive Apache License.
>>>>> 
>>>> 
>>>> 
>>>> and the “features” in :
>>>> 
>>>>> Ivy has a lot of powerful features
>>>> 
>>>> are actually link references in the original xooki backed docs of the
>> form [[license Apache License]] and [[features]].
>>> 
>>>> It seems that xooki doesn’t generate links either:
>>>> http://ant.apache.org/ivy/history/trunk/index.html 
>>>> <http://ant.apache.org/ivy/history/trunk/index.html> <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> <http://ant.apache.org/ivy/history/trunk/index.html>> <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> <http://ant.apache.org/ivy/history/trunk/index.html> <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> <http://ant.apache.org/ivy/history/trunk/index.html>>>
>>>> 
>>>> Probably the pointed pages have been deleted or moved and these links
>> have not been updated.
>>> 
>>> 
>>> I suspect it has to do with how/where those HTMLs got generated. Because
>> in the latest-milestone live ones, I see them as links on this page
>> https://ant.apache.org/ivy/history/latest-milestone/index.html 
>> <https://ant.apache.org/ivy/history/latest-milestone/index.html> <
>> https://ant.apache.org/ivy/history/latest-milestone/index.html 
>> <https://ant.apache.org/ivy/history/latest-milestone/index.html>>
>> 
>> Good catch.
>> Then the links should be absolute since they are not referencing something
>> within the doc.
>> 
>> Nicolas

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 17:53, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> 
> On 31-May-2017, at 9:02 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org 
> <mailto:nicolas.lale...@hibnet.org>> wrote:
> 
> 
>> Le 31 mai 2017 à 15:34, J Pai <jai.forums2...@gmail.com> a écrit :
>> 
>> One thing I just noticed in the generated adoc files is that “external” 
>> links that are part of the original xooki backed .html files are not being 
>> generated as links in the converted adoc. To see a couple of example, take a 
>> look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache 
>> License” in this sentence:
>> 
>>> Ivy is open source and released under a very permissive Apache License.
>>> 
>> 
>> 
>> and the “features” in :
>> 
>>> Ivy has a lot of powerful features
>> 
>> are actually link references in the original xooki backed docs of the form 
>> [[license Apache License]] and [[features]].
> 
>> It seems that xooki doesn’t generate links either:
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> <http://ant.apache.org/ivy/history/trunk/index.html> 
>> <http://ant.apache.org/ivy/history/trunk/index.html 
>> <http://ant.apache.org/ivy/history/trunk/index.html>>
>> 
>> Probably the pointed pages have been deleted or moved and these links have 
>> not been updated.
> 
> 
> I suspect it has to do with how/where those HTMLs got generated. Because in 
> the latest-milestone live ones, I see them as links on this page 
> https://ant.apache.org/ivy/history/latest-milestone/index.html 
> <https://ant.apache.org/ivy/history/latest-milestone/index.html>

Good catch.
Then the links should be absolute since they are not referencing something 
within the doc.

Nicolas

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 15:34, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> One thing I just noticed in the generated adoc files is that “external” links 
> that are part of the original xooki backed .html files are not being 
> generated as links in the converted adoc. To see a couple of example, take a 
> look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache 
> License” in this sentence:
> 
>> Ivy is open source and released under a very permissive Apache License.
>> 
> 
> 
> and the “features” in :
> 
>> Ivy has a lot of powerful features
> 
> are actually link references in the original xooki backed docs of the form 
> [[license Apache License]] and [[features]].

It seems that xooki doesn’t generate links either:
http://ant.apache.org/ivy/history/trunk/index.html 
<http://ant.apache.org/ivy/history/trunk/index.html>

Probably the pointed pages have been deleted or moved and these links have not 
been updated.

Nicolas

> 
> -Jaikiran
> 
> On 31-May-2017, at 6:50 PM, J Pai <jai.forums2...@gmail.com> wrote:
> 
> I had some time today and decided to test this branch out locally. I was able 
> to generate the docs without any hassle. The conversion works fine which is a 
> great thing.
> 
> There are certain warning about the heading/section level we use in the 
> generated adoc files, for top level heading:
> 
>> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
>> title out of sequence: expected level 1, got level 2
> 
> 
> but that’s pretty much it in terms of build time warnings/errors.
> 
> In one of my other mails I had noted that if not in this release then maybe 
> in next release we can focus on this xooki to asciidoc conversion. But at 
> that time I wasn’t aware that Nicolas had already done the bulk of this job 
> by implementing this tool. 
> 
> So IMO, after fixing/finalizing some of those WARN related issues, we can 
> probably just go ahead and use this tool to convert our current docs to adoc 
> as a one time thing in our master branch. Till we are comfortable and are 
> sure that the conversion is done fully, we can keep the old xooki backed docs 
> as-is but just not update/add any new stuff in them. Given how nicely this 
> tool works and the fact that it isn’t breaking anything, I don’t think we 
> will have to maintain a separate branch to deal with this migration.
> 
> Any thoughts?
> 
> -Jaikiran
> 
> On 25-May-2017, at 7:55 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
> 
>> Le 25 mai 2017 à 16:17, Matt Sicker <boa...@gmail.com> a écrit :
>> 
>> Merge commits always spam the commits list which, while annoying, I've
>> learned to mass-delete whenever it happens. ;)
>> 
>> I looked at some random changes and found a couple markup typos, but
>> otherwise it looks like it converted well enough.
> 
> Yes, I have stopped one too. Some things will need to be manually fixed after 
> the automatic conversion.
> 
>> I'm more familiar with the maven plugins for site management, so I'm not
>> sure about the integration aspects, but worst case scenario, can't you just
>> commit the parts to svnpubsub on release?
> 
> If you look at the menu on the left, it is present on each page, so it means 
> that for any new file or deleted file, every page has to be regenerated. The 
> consequence it that generating a page of the site has to be aware of the list 
> of all the pages of the documentation.
> 
> But we can imagine that we uncouple the documentation, like it is being done 
> for the old versions of the documentation, in the « history » section, by 
> just having a link. So yes we could some manual copy and publish to svnpubsub 
> on release.
> 
> Nicolas
> 
>> 
>> On 25 May 2017 at 09:00, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:
>> 
>>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>>> which I still find weird, I would expect just one mail about the commit of
>>> the merge.
>>> 
>>> I can see the current status of the transformation of the xooki source
>>> into asciidoc source and then the generated html from that here:
>>> http://hibnet.org/tmp/ivy-asciidoc/index.html <http://hibnet.org/tmp/ivy-
>>> asciidoc/index.html>
>>> 
>>> It seems pretty good, but I didn’t looked to most of the pages.
>>> 
>>> Before going further, we need to figure out how it would be integrated to
>>> the website since it is also managed by xooki. The site and the
>>> documentation are tidily coupled by the toc which is managed by xooki.
>>> 
>>> Nicolas
>>> 
>>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 15:20, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> I had some time today and decided to test this branch out locally. I was able 
> to generate the docs without any hassle. The conversion works fine which is a 
> great thing.
> 
> There are certain warning about the heading/section level we use in the 
> generated adoc files, for top level heading:
> 
>> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
>> title out of sequence: expected level 1, got level 2
> 
> 
> but that’s pretty much it in terms of build time warnings/errors.
> 
> In one of my other mails I had noted that if not in this release then maybe 
> in next release we can focus on this xooki to asciidoc conversion. But at 
> that time I wasn’t aware that Nicolas had already done the bulk of this job 
> by implementing this tool. 
> 
> So IMO, after fixing/finalizing some of those WARN related issues, we can 
> probably just go ahead and use this tool to convert our current docs to adoc 
> as a one time thing in our master branch. Till we are comfortable and are 
> sure that the conversion is done fully, we can keep the old xooki backed docs 
> as-is but just not update/add any new stuff in them. Given how nicely this 
> tool works and the fact that it isn’t breaking anything, I don’t think we 
> will have to maintain a separate branch to deal with this migration.

The goal of this tool is not to generate completely asciidoc compatible source, 
just do most of the stuff automatically. For instance, fixing the issue with 
the title level automatically will be hard I think, at least harder than fixing 
it manually afterward.
So the question about it being ready or not, is more about if we are ready to 
fix manually what is not being correctly converted.

About keeping the old xooki sources: I don’t think this will be necessary, we 
have git for that. But probably just before migrating, we could generate the 
doc one last time with xooki and keep it somewhere so we can compare the final 
result while fixing manually the asciidoc sources.

Then about when to do it: I have no objection to when, as long as people are 
motivated to do it.

Nicolas


> Any thoughts?
> 
> -Jaikiran
> 
> On 25-May-2017, at 7:55 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
> 
>> Le 25 mai 2017 à 16:17, Matt Sicker <boa...@gmail.com> a écrit :
>> 
>> Merge commits always spam the commits list which, while annoying, I've
>> learned to mass-delete whenever it happens. ;)
>> 
>> I looked at some random changes and found a couple markup typos, but
>> otherwise it looks like it converted well enough.
> 
> Yes, I have stopped one too. Some things will need to be manually fixed after 
> the automatic conversion.
> 
>> I'm more familiar with the maven plugins for site management, so I'm not
>> sure about the integration aspects, but worst case scenario, can't you just
>> commit the parts to svnpubsub on release?
> 
> If you look at the menu on the left, it is present on each page, so it means 
> that for any new file or deleted file, every page has to be regenerated. The 
> consequence it that generating a page of the site has to be aware of the list 
> of all the pages of the documentation.
> 
> But we can imagine that we uncouple the documentation, like it is being done 
> for the old versions of the documentation, in the « history » section, by 
> just having a link. So yes we could some manual copy and publish to svnpubsub 
> on release.
> 
> Nicolas
> 
>> 
>> On 25 May 2017 at 09:00, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:
>> 
>>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>>> which I still find weird, I would expect just one mail about the commit of
>>> the merge.
>>> 
>>> I can see the current status of the transformation of the xooki source
>>> into asciidoc source and then the generated html from that here:
>>> http://hibnet.org/tmp/ivy-asciidoc/index.html <http://hibnet.org/tmp/ivy-
>>> asciidoc/index.html>
>>> 
>>> It seems pretty good, but I didn’t looked to most of the pages.
>>> 
>>> Before going further, we need to figure out how it would be integrated to
>>> the website since it is also managed by xooki. The site and the
>>> documentation are tidily coupled by the toc which is managed by xooki.
>>> 
>>> Nicolas
>>> 
>>> 
>> 
>> 
>> -- 
>> Matt Sicker <boa...@gmail.com>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Replace emma with jacoco?

[Nicolas Lalevée]

FYI, here are the post build actions available on the Jenkins at the ASF:
https://www.dropbox.com/s/zwpersrv4ydzdp5/Capture%20d%27%C3%A9cran%202017-05-29%2017.36.49.png?dl=0
 


It would be nice if the tool we choose is integrated in our CI.

Nicolas

> Le 29 mai 2017 à 17:29, Matt Sicker  a écrit :
> 
> I've used pitest  before which is a bit more useful
> than typical code coverage plugins.
> 
> On 29 May 2017 at 08:55, Martin Gainty  wrote:
> 
>> 
>> 
>> 
>> 
>> From: Gintautas Grigelionis 
>> Sent: Monday, May 29, 2017 9:50 AM
>> To: Ant Developers List
>> Subject: Re: Replace emma with jacoco?
>> 
>> Talk about timing, again :-) -- Clover has been open source since April.
>> BTW, the documentation has moved to https://atlassian-docs.bitbucket.io/,
>> Atlassian documentation
>> atlassian-docs.bitbucket.io
>> The documentation in this repository is for products that are no longer
>> supported by Atlassian. This documentation is not maintained by Atlassian,
>> but is open source ...
>> 
>> 
>> 
>> so confluence.atlassian.com links do not work any more.
>> 
>> I can try adding both Jacoco and Clover and make instrumentation selectable
>> through a property.
>> I am inclined to start with Jacoco due to personal experience and keep it a
>> default choice.
>> 
>> The bigger change would be that "ant test" would run both instrumentation
>> and unit tests, and likewise "ant test-report" would produce both reports.
>> MG>an excellent idea..my personal request is which code-coverage tool
>> detects orphaned class ?
>> MG>a second request is which code coverage detects orphaned inner-classes?
>> MG>i look forward to receiving your analysis
>> 
>> Gintas
>> 
>> 2017-05-29 0:58 GMT+02:00 Martin Gainty :
>> 
>>> Hi Gintautas
>>> 
>>> 
>>> clover code-coverage has been around for 15 years..atlassian just
>>> contributed clover to Open Source this year
>>> 
>>> https://www.atlassian.com/blog/announcements/atlassian-
>> clover-open-source
>> Atlassian Clover is now open source - Atlassian Blog<
>> https://www.atlassian.com/blog/announcements/atlassian-clover-open-source>
>> www.atlassian.com
>> All of this has lead to our decision to open source Clover, what we
>> believe is the best way to give Clover the focus and attention it deserves.
>> 
>> 
>> 
>>> 
>>> Atlassian Clover is now open source - Atlassian Blog<
>>> https://www.atlassian.com/blog/announcements/atlassian-
>> clover-open-source>
>> Atlassian Clover is now open source - Atlassian Blog<
>> https://www.atlassian.com/blog/announcements/atlassian-clover-open-source>
>> www.atlassian.com
>> All of this has lead to our decision to open source Clover, what we
>> believe is the best way to give Clover the focus and attention it deserves.
>> 
>> 
>> 
>>> www.atlassian.com
>> [https://wac-cdn-a.atlassian.com/dam/jcr:c20cf6d1-9568-
>> 4aba-9a16-dba24e1495de/atlassian-software.png]
>> 
>> Atlassian | Software Development and Collaboration Tools<
>> http://www.atlassian.com/>
>> www.atlassian.com
>> Millions of users globally rely on Atlassian products every day for
>> improving software development, project management, collaboration, and code
>> quality.
>> 
>> 
>> 
>>> All of this has lead to our decision to open source Clover, what we
>>> believe is the best way to give Clover the focus and attention it
>> deserves.
>>> 
>>> Atlassian published an ant taskdef here
>>> 
>>> https://confluence.atlassian.com/clover/6-ant-task-
>> reference-71600066.html
>> 6. Ant Task Reference - Atlassian Documentation> confluence.atlassian.com/clover/6-ant-task-reference-71600066.html>
>> confluence.atlassian.com
>> Can I create a Clover Report on Server A if I have the clover.db which I
>> generated on Server B? Does Clover depend on JUnit? Does Clover integrate
>> with Maven?
>> 
>> 
>> 
>>> 
>>> 6. Ant Task Reference - Atlassian Documentation>> confluence.atlassian.com/clover/6-ant-task-reference-71600066.html>
>>> confluence.atlassian.com
>>> Can I create a Clover Report on Server A if I have the clover.db which I
>>> generated on Server B? Does Clover depend on JUnit? Does Clover integrate
>>> with Maven?
>>> 
>>> emma hasnt been touched in 12 years so it seems to be retired?
>>> 
>>> http://emma.sourceforge.net/
>> EMMA: a free Java code coverage tool
>> emma.sourceforge.net
>> EMMA can instrument classes for coverage either offline (before they are
>> loaded) or on the fly (using an instrumenting application classloader).
>> 
>> 
>> 
>>> 
>>> EMMA: a free Java code coverage tool
>> EMMA: a free Java code coverage tool
>> emma.sourceforge.net
>> 

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

[Nicolas Lalevée]

+1

Nicolas


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


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

Re: PR-33: problems

[Nicolas Lalevée]

> Le 29 mai 2017 à 11:46, Jan Matèrne (jhm)  a écrit :
> 
> Sounds like I would do ;)
> I'll merge the PR locally and insert the delegates.
> 
> Open is
> "src/java/org/apache/ivy/osgi/util/Version.java: 
>  the constructor removes the (IMO unneccessary) ParseException. 
>  But because it is a checked Exception we break BC."
> 
> https://wiki.eclipse.org/Evolving_Java-based_APIs_2 defines the removal of a 
> checked exception:
> "Breaks compatibility"
> "Adding and deleting checked exceptions declared as thrown by an API method 
>  does not break binary compatibility; however, 
>  it breaks contract compatibility (and source code compatibility)."
> 
> What do we want?

Thanks for the link, I’ll bookmark it.

Then I am OK with that. The Ivy jar can still be a upgraded without worries, 
and if somebody compile against it, then he has the source so he can modify 
them.

I am OK with that also because having stricter compatibility rules will be 
painful considering the wide API Ivy is exposing.

Nicolas

> 
> 
> 
> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>> Gesendet: Montag, 29. Mai 2017 10:26
>> An: Ant Developers List
>> Betreff: Re: PR-33: problems
>> 
>> IMO, for each of these public classes/methods/fields that we are fixing
>> for typos, we should mark them @Deprecated (and add a @deprecated
>> javadoc too and point to the new field/method/class) and introduce the
>> rightly named class/method/field. For methods it’s straightforward, the
>> deprecated method internally calls the new method. For fields too it’s
>> straightforward. The deprecated field uses the value of the new field.
>> For classes, I think we can copy over the existing class into the new
>> one and leave around the existing one just for possible external
>> references (that we can’t control off) and migrate all internal
>> references to the new one.
>> 
>> At some point, in some future version of Ivy, we remove/delete these
>> deprecated method/field/class.
>> 
>> 
>> -Jaikiran
>> 
>> 
>> On 29-May-2017, at 1:43 PM, Jan Matèrne  wrote:
>> 
>> I did a review of  
>> https://github.com/apache/ant-ivy/pull/33
>> 
>> Here are the points I have problems with, so I want to discuss them
>> here.
>> 
>> Basically it's about breaking BC. So how to deal with that?
>> 
>> 
>> 
>> 
>> 
>> Jan
>> 
>> 
>> 
>> 
>> 
>> Fixing the spell error in DelegateHandler$ChildElementHandler
>> (s/childHanlded/childHandled/) means breaking beakward compatiblity.
>> 
>> We could introduce a delegetate for that:
>> 
>> /** for BC */
>> 
>> @Deprecated
>> 
>> public void childHanlded(DH child) throws SAXParseException {
>> 
>>   childHandled(DH child);
>> 
>> }
>> 
>> While refactoring you have renamed all occurences in the Ivy codebase.
>> 
>> On the other hand I don't know the impact (maybe outside of Ivy). I'll
>> bring that to the dev-list.
>> 
>> 
>> 
>> 
>> 
>> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the
>> public constant DEFAULT_BUNLDE_FILTER also means breaking BC.
>> 
>> 
>> 
>> 
>> 
>> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes
>> the (IMO unneccessary) ParseException. But because it is a checked
>> Exception we break BC.
>> 
>> 
>> 
>> 
>> 
>> renaming EncrytedProperties to EncryptedProperties means breaking BC.
>> If required we could introduce a delegating class or a subclass.
>> 
>> 
>> 
>> 
>> 
>> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If
>> required we could introduce a delegating method.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
>> commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: PR-33: problems

[Nicolas Lalevée]

> Le 29 mai 2017 à 11:35, Jan Matèrne (jhm)  a écrit :
> 
> Thanks, but I already have it done ;)
> 
> But one point is open:
> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes the 
> (IMO unneccessary) ParseException. But because it is a checked Exception we 
> break BC.

It breaks compile time BC but the not binary one, isn’t it ? If it is the case, 
I have no objection to break it there.

Nicolas


> 
> 
> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
>> Gesendet: Montag, 29. Mai 2017 11:00
>> An: Ant Developers List
>> Betreff: Re: PR-33: problems
>> 
>> If it's acceptable I'll complement the PR addressing all the points.
>> 
>> Gintas
>> 
>> Den 29 maj 2017 10:13 skrev "Jan Matèrne" :
>> 
>> I did a review of  
>> https://github.com/apache/ant-ivy/pull/33
>> 
>> Here are the points I have problems with, so I want to discuss them
>> here.
>> 
>> Basically it's about breaking BC. So how to deal with that?
>> 
>> 
>> 
>> 
>> 
>> Jan
>> 
>> 
>> 
>> 
>> 
>> Fixing the spell error in DelegateHandler$ChildElementHandler
>> (s/childHanlded/childHandled/) means breaking beakward compatiblity.
>> 
>> We could introduce a delegetate for that:
>> 
>>  /** for BC */
>> 
>>  @Deprecated
>> 
>>  public void childHanlded(DH child) throws SAXParseException {
>> 
>>childHandled(DH child);
>> 
>>  }
>> 
>> While refactoring you have renamed all occurences in the Ivy codebase.
>> 
>> On the other hand I don't know the impact (maybe outside of Ivy). I'll
>> bring that to the dev-list.
>> 
>> 
>> 
>> 
>> 
>> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the
>> public constant DEFAULT_BUNLDE_FILTER also means breaking BC.
>> 
>> 
>> 
>> 
>> 
>> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes
>> the (IMO unneccessary) ParseException. But because it is a checked
>> Exception we break BC.
>> 
>> 
>> 
>> 
>> 
>> renaming EncrytedProperties to EncryptedProperties means breaking BC.
>> If required we could introduce a delegating class or a subclass.
>> 
>> 
>> 
>> 
>> 
>> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If
>> required we could introduce a delegating method.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


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

Re: Ivy website - fixing a Quickstart documentation live

[Nicolas Lalevée]

There are some Ant task for asciidoctor, and it is used in the branch where 
there is the experiment about migrating from xooki to asciidoc:
https://github.com/apache/ant-ivy/blob/xooki2asciidoc/build-release.xml#L168 
<https://github.com/apache/ant-ivy/blob/xooki2asciidoc/build-release.xml#L168>

And it is nice because we can plug things into asciidoctor, like the management 
of the toc, just like xooki is currently doing:
https://github.com/apache/ant-ivy/blob/xooki2asciidoc/asciidoc/templates/helpers.rb
 
<https://github.com/apache/ant-ivy/blob/xooki2asciidoc/asciidoc/templates/helpers.rb>

Nicolas
 
> Le 26 mai 2017 à 17:54, Gintautas Grigelionis <g.grigelio...@gmail.com> a 
> écrit :
> 
> Thanks for heads up: asciidoctorj
> <https://github.com/asciidoctor/asciidoctorj>, then :-) There are no Ant
> tasks, but maybe a javascript wrapper would do?
> 
> Gintas
> 
> 2017-05-26 17:26 GMT+02:00 Matt Sicker <boa...@gmail.com>:
> 
>> Can't you run the original Ruby asciidoc parser via JRuby, too?
>> 
>> On 26 May 2017 at 02:06, J Pai <jai.forums2...@gmail.com> wrote:
>> 
>>> So I got this site generation working locally (had to fix a xooki script
>>> to make it work with Nashorn. The attached patch includes the fix).
>>> 
>>> At this point, I need help to commit the newly generated doc fixes to the
>>> SVN. I’ve attached a patch file for it and will explain what it is doing.
>>> 
>>> The changes/patch relates to _one_ of the more important issues noted in
>>> the JIRA https://issues.apache.org/jira/browse/IVY-1542. That JIRA lists
>>> more than one issue with the latest docs. However, the missing .png and
>>> .css don’t directly contribute to anything noticeable, so I haven’t
>>> included it in this patch (and probably will look into it separately).
>> The
>>> issue that this patch fixes is the more important one:
>>> 
>>>> Code examples are missing. About 2/3 of the way down the page are two
>>> code examples that are rendering as just a black rectangle for me. The
>>> underlying html looks like it has  tags with no content.
>>> 
>>> 
>>> The way these tutorial docs are generated, during the build, it triggers
>>> the build of quickstart examples and dumps the logs into files. The log
>>> files are then referred to via xooki references and the contents of those
>>> log files are inlined within the div tags. So I went ahead and built
>> these
>>> tutorials on 2.4.0 tag of Ivy project, generated those logs and then
>>> regenerated the site with these logs in the relevant folder. The
>> generated
>>> documentation now has these output inlined correctly in the quickstart
>> and
>>> various other docs.
>>> 
>>> The attached patch was generated with https://svn.apache.org/repos/
>>> asf/ant/site/ as the root of the SVN checkout. So whoever is applying the
>>> patch will have to cd to that directory and then apply it. Let me know if
>>> you run into issues or if any changes are necessary in this patch.
>>> 
>>> As for the other two issues noted in that JIRA, I’m planning to remove
>>> references to the non-existent .css and .png files and submit that as a
>>> separate patch.
>>> 
>>> -Jaikiran
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 26-May-2017, at 10:39 AM, J Pai <jai.forums2...@gmail.com> wrote:
>>> 
>>> Thanks everyone for the inputs.
>>> 
>>> I’m trying to get a proper build going locally for the site generation
>>> (and running into issues). Once I get a proper build and the fixes to the
>>> issues noted in that JIRA, I’ll send out an update. Hopefully soon.
>>> 
>>> -Jaikiran
>>> On 25-May-2017, at 5:26 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org>
>>> wrote:
>>> 
>>> The entire Ant site is in svn:
>>> https://svn.apache.org/repos/asf/ant/site
>>> 
>>> There is a Readme.txt explaining a little bit stuff, but seems outdated
>>> since the migration to git. For Ivy and IvyDE, part of the site is built
>>> from the source for the projects. It used to be managed via
>> svn:externals.
>>> Now there are ant tasks to run to the fetch of the sources. I have found
>> an
>>> old discussion [1] we had about it which should help you.
>>> 
>>> By the way, the Ivy documentation is managed by an hand crafted html
>>> editor, xooki, just is good but quite slow. I did some work som

Re: build IvyDE

[Nicolas Lalevée]

It has been ages since I have done a build of Eclipse, but like Gintas wrote, 
there is something wrong with your Eclipse install you are building against, it 
is missing zest.
I don’t know if you have seen but there is a piece of documentation about 
building IvyDE there:
http://ant.apache.org/ivy/ivyde/history/latest-milestone/dev/build.html 


The hudson-prepare ant task is about what is described in that doc: download 
stuff and setup the baseLocation property.

Nicolas

> Le 26 mai 2017 à 16:50, Gintautas Grigelionis  a 
> écrit :
> 
> Did you try to run "ant hudson-prepare"? That's supposed to set up the
> entire environment, that is, download PDE and all dependencies (WTP, XSD,
> EMF, GEF and Zest) as drops, then unpack the PDE and all drops on top of
> that, if my understanding is correct. It also should pick up the latest Ivy
> build and update build properties.
> 
> Gintas
> 
> 2017-05-26 14:53 GMT+02:00 Jan Matèrne :
> 
>> I tried to get the IvyDE build working.
>> 
>> Finally I am getting a
>> 
>> 
>> 
>> [eclipse.buildScript] Some inter-plug-in dependencies have not been
>> satisfied.
>> 
>> [eclipse.buildScript] Bundle org.apache.ivyde.eclipse.resolvevisualizer:
>> 
>> [eclipse.buildScript]   Missing required plug-in
>> org.eclipse.zest.core_[1.2.0,2.0.0).
>> 
>> [eclipse.buildScript]   Missing required plug-in
>> org.eclipse.zest.layouts_[1.1.0,2.0.0).
>> 
>> 
>> 
>> I could download zest via "ant hudson-get-zest"
>> 
>> 
>> 
>> hudson-get-zest:
>> 
>>  [get] Getting:
>> http://www.eclipse.org/downloads/download.php?file=/
>> tools/gef/downloads/drop
>> s/3.6.2/R201102251600/GEF-zest-3.6.2.zip=http://
>> carroll.aset.psu.edu/pub
>> /eclipse/tools/gef/downloads/drops/3.6.2/R201102251600/GEF-
>> zest-3.6.2.zip
>> rror_id=546
>> 
>>  [get] To:
>> C:\projekte\apache-ant\ivy-ivyde\dependencies\GEF-zest-3.6.2.zip
>> 
>>  [get]
>> http://www.eclipse.org/downloads/download.php?file=/
>> tools/gef/downloads/drop
>> s/3.6.2/R201102251600/GEF-zest-3.6.2.zip=http://
>> carroll.aset.psu.edu/pub
>> /eclipse/tools/gef/downloads/drops/3.6.2/R201102251600/GEF-
>> zest-3.6.2.zip
>> rror_id=546 moved to
>> http://archive.eclipse.org/tools/gef/downloads/drops/3.6.
>> 2/R201102251600/GEF
>> -zest-3.6.2.zip
>> 
>>  [get] ...
>> 
>> 
>> 
>> BUILD SUCCESSFUL
>> 
>> Total time: 5 seconds
>> 
>> 
>> 
>> 
>> 
>> Some ideas?
>> 
>> 
>> 
>> 
>> 
>> Jan
>> 
>> 

Re: IVY-1485, resolve report and resolved versions

[Nicolas Lalevée]

> Le 26 mai 2017 à 13:23, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> Thank you very much Nicolas for digging more into this and getting hold of 
> these details. What you explain, backed by the details, makes clear sense.
> 
> I will attempt to go with this option that you suggest:
> 
>> - drop this property file, make the xml report always produced, and make the 
>> deliver read the report rather than the property file.
> 
> From looking at the code and documentation, the option that decides whether 
> to create the XML report seems to be an internal only option (in Ivy 2.x 
> world) i.e. not exposed or documented as something that the user can fiddle 
> with. That’s a good thing since removing it or fiddling with its semantics, 
> won’t affect the users.

ha, ok. good then.

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

Please, be my guest.

Nicolas

> 
> -Jaikiran
> 
> 
> On 26-May-2017, at 2:20 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> 
> wrote:
> 
> After some digging, I found out that the resolved revisions property file is 
> very old (git is awesome, even better within sourcetree). It is so old that 
> at that time the xml resolve report didn’t exist. And this property file 
> seems to have been created just in order to make the deliver task work [1]. 
> And a comment still state this too [2]. And the purpose of the lines from 248 
> to 326 are about to compute these versions and write them down, it can be 
> extracted in a function without side effect.
> 
> So most probably this property file is redundant with the xml resolve report. 
> But the thing is the resolve may not be produced, it is an option [3], 
> defaulting to true [4].
> 
> Two options:
> - continue to support the property file and correctly produce it to fix 
> IVY-1485 [5].
> - drop this property file, make the xml report always produced, and make the 
> deliver read the report rather than the property file.
> 
> Makes sense ?
> 
> Nicolas
> 
> [1] 
> https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325
>  
> <https://github.com/apache/ant-ivy/commit/3081a1b16a2fcb13b7a13bf761d6a625598d0325>
> [2] 
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247
>  
> <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L247>
> [3] 
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338
>  
> <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveEngine.java#L338>
> [4] 
> https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99
>  
> <https://github.com/apache/ant-ivy/blob/master/src/java/org/apache/ivy/core/resolve/ResolveOptions.java#L99>
> [5] https://issues.apache.org/jira/browse/IVY-1485 
> <https://issues.apache.org/jira/browse/IVY-1485>
>> Le 25 mai 2017 à 12:11, Nicolas Lalevée <nicolas.lale...@hibnet.org> a écrit 
>> :
>> 
>> Thank you very much Jaikiran for your detailed explanation.
>> 
>> I have to admit that I don’t know the answer to which is the source of truth 
>> about the resolution report. I have also wondered why the resolve report 
>> should have to be always wrote and then read from file. I’ll try to get an 
>> answer myself too while reading the code.
>> 
>> Nicolas
>> 
>>> Le 22 mai 2017 à 07:37, J Pai <jai.forums2...@gmail.com> a écrit :
>>> 
>>> One other thing about this issue - this is reproducible (as shown in the 
>>> test case) with static revisions too and isn’t specific to any dynamic 
>>> revision resolution.
>>> 
>>> -Jaikiran
>>> On 22-May-2017, at 11:02 AM, J Pai <jai.forums2...@gmail.com> wrote:
>>> 
>>> I have had a look at that issue, this last week and I have been able to 
>>> reproduce it in a simple test case[1]. I kind of understand what the issue 
>>> is in there, but given my lack of knowledge of the Ivy codebase, I haven’t 
>>> been able to figure how to fix this correctly. In fact, this issue is what 
>>> prompted me to ask this question [2] in the dev list a day or so back, 
>>> since basically comes down to those files. Here’s my understanding of the 
>>> problem (backed by that test case[1] which reproduces it).
>>> 
>>> Imagine you have a module org:hello-world and imagine it has 2 
>>> configurations conf1 and conf

IVY-1485, resolve report and resolved versions

[Nicolas Lalevée]

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

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

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

Makes sense ?

Nicolas

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

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

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

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

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

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

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

Nicolas

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


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

Ivy documentation with asciidoc

[Nicolas Lalevée]

I have updated the branch xooki2asciidoc. The merge generated 50 emails, which 
I still find weird, I would expect just one mail about the commit of the merge.

I can see the current status of the transformation of the xooki source into 
asciidoc source and then the generated html from that here:
http://hibnet.org/tmp/ivy-asciidoc/index.html 


It seems pretty good, but I didn’t looked to most of the pages.

Before going further, we need to figure out how it would be integrated to the 
website since it is also managed by xooki. The site and the documentation are 
tidily coupled by the toc which is managed by xooki.

Nicolas

Re: Ivy website - fixing a Quickstart documentation live

[Nicolas Lalevée]

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

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

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

Nicolas

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

[2] https://github.com/apache/ant-ivy/tree/xooki2asciidoc 



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

Re: Versioning scheme in Ivy

[Nicolas Lalevée]

Almost everything in Ivy is configurable, like the version matchers [1].

Ivy provide some sane default, but if some has a weird use case, he will be 
able to tweak thing to make it work.

Nicolas

[1] 
https://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html
 



> Le 24 mai 2017 à 10:22, Gintautas Grigelionis  a 
> écrit :
> 
> Sorry, I meant to ask what may happen if special characters from range
> specification are used randomly in a version string?
> 
> Gintas
> 
> 2017-05-24 10:15 GMT+02:00 Gintautas Grigelionis :
> 
>> I was thinking about the discussion which touched upon restricted
>> characters in version strings. While Ivy does not place any restrictions on
>> those strings, Ivy does support versions ranges as specified by OSGi. So,
>> what happens if version range is used as a version string?
>> 
>> Gintas
>> 

Re: Ivy - Goals for the upcoming release?

[Nicolas Lalevée]

Thank you very much Jaikiran for your detailed explanation.

I have to admit that I don’t know the answer to which is the source of truth 
about the resolution report. I have also wondered why the resolve report should 
have to be always wrote and then read from file. I’ll try to get an answer 
myself too while reading the code.

Nicolas

> Le 22 mai 2017 à 07:37, J Pai <jai.forums2...@gmail.com> a écrit :
> 
> One other thing about this issue - this is reproducible (as shown in the test 
> case) with static revisions too and isn’t specific to any dynamic revision 
> resolution.
> 
> -Jaikiran
> On 22-May-2017, at 11:02 AM, J Pai <jai.forums2...@gmail.com> wrote:
> 
> I have had a look at that issue, this last week and I have been able to 
> reproduce it in a simple test case[1]. I kind of understand what the issue is 
> in there, but given my lack of knowledge of the Ivy codebase, I haven’t been 
> able to figure how to fix this correctly. In fact, this issue is what 
> prompted me to ask this question [2] in the dev list a day or so back, since 
> basically comes down to those files. Here’s my understanding of the problem 
> (backed by that test case[1] which reproduces it).
> 
> Imagine you have a module org:hello-world and imagine it has 2 configurations 
> conf1 and conf2. Now consider the case where this hello-world module depends 
> on org:module1:1.0 in conf1 (a direct dependency) and on org:module2:1.0 in 
> conf2 (a direct dependency). That translates to a module descriptor like:
> 
> 
>module="hello-world"
> revision="1.2.3"
> 
>   />
>   
>   
>   
>   
>   
>   
>   
>   
> 
> 
> Now take this one step further and consider that org:module2:1.0 (that 
> hello-world depends on, in conf2) has a dependency of its own on 
> org:module1:2.0. So module2’s module descriptor looks like:
> 
> 
> module="module2"
>revision="1.0"
> />
>   
>   
>   
> 
>   
> 
> 
> 
> So ultimately, when you resolve the hello-world module, you expect it to have 
> org:module1:1.0 as an dependency in conf1 and org:module1:2.0 as an 
> dependency in conf2 (transitively via org:module2:1.0).
> 
> Does the resolve work as expected for this use case? Yes it does and the 
> resolution pulls in the right set of dependencies in the right 
> configurations. Internally it creates resolution report (as an xml) plus a 
> resolution properties file for this resolution. No (obvious/apparent) issues 
> at this point. 
> 
> Now, let’s say a “deliver” is triggered against this resolution, for conf1. 
> What I would expect is, that it would deliver a file for hello-world which 
> then has a dependency on org:module1:1.0 in conf1 (because that’s what it was 
> correctly resolved to previously). However, the delivered file instead has a 
> dependency on org:module1:2.0 in conf1 and I believe that’s the issue being 
> reported in that JIRA.
> 
> So is this a bug in the deliver task itself? I don’t think so. So far what I 
> have narrowed it down to is that the resolve task that happened previously 
> creates more than one representation of that resolution (one a resolution 
> report xml and one a resolution properties file). The resolution report XML 
> has all the necessary and correct information about which dependency (either 
> direct or transitive) belongs to which configuration. However, the resolution 
> properties file contains the “wrong” dependency for module1 - it stores the 
> dependency as org:module1:2.0. I am not even sure if the properties file is 
> capable enough of supporting/understanding dependencies per configuration. 
> The deliver task then uses this properties file (instead of the resolution 
> report XML) to decide what dependencies to write out. I’m guessing some other 
> (post-resolve) tasks too use this properties file for their decision making, 
> so this really boils down to a potential bug in what gets written out to this 
> resolution properties file, during resolve.
> 
> Unfortunately, my reading of the code so far hasn’t given me answers on what 
> role this file plays and why can’t it be just skipped and the resolution 
> report XML instead be considered the single source of truth. Hence that 
> question [2] in the dev list. I can’t really think of a solution/fix for this 
> issue, without reading more of the current Ivy code to understand what role 
> these files play.
> 
> [1] 
> https://github.com/jaikiran/ant-ivy/commit/529a3fa05ed5dd115bdf8046d0cf0ffe034905e0#diff-6ed8218b6bb9460014cf3558ff227172R571
> [2] https://www.mail-archive.com/dev@ant.apache.org/msg45402.html
> 
> -Jaikiran
> 
> On 21

Re: Ivy - Buildjobs/PreCommit

[Nicolas Lalevée]

> Le 24 mai 2017 à 13:13, Jan Matèrne (jhm)  a écrit :
> 
> Not sure about this expertise because my sources were old, but I think the 
> github-plugin does not support matrix jobs.
> https://github.com/KostyaSha/github-integration-plugin/issues/53
> 
> Maybe a newer plugin version would do, but I could not see the version stamp.
> I'll ask on builds@a.o for help.
> 
> For the meanwhile I deactivated the matrix-PR-job and reactivated the 'old' 
> plain-PR-job.
> 
> If we can't get matrix support we should be to create our own 'matrix' by 
> copying that job and sticking to certain configurations.
> While a matrix would scale this approach won't. So we should define only 2-4 
> most interesting configs like
> - Java7@Unix
> - Java7@Windows
> - Java8@Unix

I think we can even stick to only two configs. Testing on two different OS is 
the real pain and I don’t remember having big issues with jvm versions.

We could even for now stick to Windows if most committers are on Unix machines. 
At least I am.

And in the end we still have the more exhaustive matrix build which runs after 
the commit being merged into the asf repo.

Nicolas

> 
> 
> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: J Pai [mailto:jai.forums2...@gmail.com]
>> Gesendet: Montag, 22. Mai 2017 14:45
>> An: Ant Developers List
>> Betreff: Re: Ivy - Buildjobs/PreCommit
>> 
>> It looks like there might be some issue with the matrix job(s)
>> https://builds.apache.org/job/Ivy-GithubPR-Matrix/2/console
>> 
>> From what I understand of that log, it seems like the parent matrix job
>> (the one above) is correctly checking out the commit from the submitted
>> PR:
>> 
>>> Checking out Revision c1765c71ba4394597409de790bf4529ff97e866e
>> (master)  > git config core.sparsecheckout # timeout=10  > git checkout
>> -f c1765c71ba4394597409de790bf4529ff97e866e
>>> git rev-parse origin/master^{commit} # timeout=10  > git rev-list
>> 239bc0b04a95d6c0f82e59c513de36d68c033c6a # timeout=10
>> 
>> However, it then hands off the job execution to individual
>> Windows/Linux jobs and those jobs https://builds.apache.org/job/Ivy-
>> GithubPR-Matrix/jdk=JDK%201.7%20(latest),os=ubuntu/2/console don’t seem
>> to be able to checkout the commit(s) from the PR and fail with error
>> like:
>> 
>>> Fetching upstream changes from https://github.com/apache/ant-ivy/
>> 
>>> git --version # timeout=10
>>> git fetch --tags --progress
>> https://github.com/apache/ant-ivy/
>> +refs/heads/*:refs/remotes/origin/*
>> Checking out Revision c1765c71ba4394597409de790bf4529ff97e866e (master)
>>> git config core.sparsecheckout # timeout=10  > git checkout -f
>> c1765c71ba4394597409de790bf4529ff97e866e
>> FATAL: Could not checkout c1765c71ba4394597409de790bf4529ff97e866e
>> 
>> hudson.plugins.git.GitException
>> : Command "git checkout -f c1765c71ba4394597409de790bf4529ff97e866e"
>> returned status code 128:
>> stdout:
>> stderr: fatal: reference is not a tree:
>> c1765c71ba4394597409de790bf4529ff97e866e
>> 
>>  at
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPI
>> Impl.java:1866)
>> 
>> 
>> -Jaikiran
>> 
>> On 22-May-2017, at 12:25 PM, Jan Matèrne (jhm) 
>> wrote:
>> 
 On a related note, while we are at this - does Apache infra allow
>> the
>>> jobs to be run against Windows OS Jenkins agents as well? There are a
>>> few issues specifically reported against Windows OS and having the
>> job
>>> run against linux and Windows OS should give a decent coverage for
>> the
>>> upstream code.
>>> 
>>> In Jenkins there is the concept of « Matrix » job.
>>> Here is the ones for Ant:
>>> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
>>> Windows/ >> Matrix-1.9.x-Windows/>
>>> https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
>>> Linux/
>>> >> 1.9.x-Linux/>
>>> AFAIR, it used to be able to do on several different OS. I don’t know
>>> why they are split.
>>> 
>>> And I don’t know if it is possible to do it while pulling a PR from
>>> github.
>> 
>> 
>> New buildjob "Ivy-GithubPR-Matrix". I deactivated the old (so we could
>> easily switch back).
>> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR-Matrix/
>> Basically a copy of the old job:
>> * discard old build jobs (keep 10)
>> * git merge support: fail the build if push fails
>> * github project: git://github.com/apache/ant-ivy.git
>> * git
>> -- repository: git://github.com/apache/ant-ivy.git
>> -- branches: */master (= default)
>> -- clean before checkout
>> -- recursively update submodules
>> -- build commits submitted for validated merge (= PR support)
>> * start build: build pull request to the repository (= PR support)
>> * configuration matrix
>> -- JDK: JDK 1.7 (latest), JDK 1.8 (latest), JDK 9 b156 with jigsaw
>> -- os: label expression = ["ubuntu", "Windows"]
>> * abort the build if it's 

Re: Ivy - Goals for the upcoming release?

[Nicolas Lalevée]

One thing though.

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

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

Nicolas

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