AW: Next plans for Ivy

[jhm]

Sounds good. Similar to Ant, on branch for maintaining the version for the old 
Java version and master for the new(er) one.
And as suggested we shoundn't go farer than Ant itself, so Java8 is fine with 
me (no Java 13).

So: +1

Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Mittwoch, 30. Oktober 2019 15:54
> An: Ant Developers List
> Betreff: Next plans for Ivy
> 
> Now that Ivy 2.5.0 has been released, I would like to propose the
> following ideas for the next goals for the project:
> 
> 1. I would like to wait and watch for any bug reports for 2.5.0 and do
> some relatively frequent bug fix releases for that version. So
> essentially 2.5.x versions which are solely bug fixes. To accommodate
> that, I would like to create a 2.5 branch in the Ivy project. Ivy 2.5.x
> will continue to have minimum Java 7 as a requirement. Once we are
> confident that the 2.5.x series is stable enough, we can stop releases
> off that branch.
> 
> 2. In the master branch, I would like to move Ivy to minimum Java 8
> version (right now we are on minimum Java 7). I would like to mention
> that, just because we move to Java 8, the goal isn't large/medium scale
> refactoring of existing code. This is especially important given the
> nature of the project - the code base is complex plus we don't have
> enough knowledge of it. It literally took me months to be able to read
> the code and understand what I'm dealing with to be able to confidently
> do a change that could fix some of the recent bugs (especially IVY-
> 1580). So even though we will move to Java 8, any refactoring, just for
> the sake of it, of existing code will be discouraged. Of course, if new
> code is being added, Java 8 constructs/API are welcome. Also if a bug
> fix requires Java 8 construct/API that's welcome too. We will do 2.6.x
> releases (whenever we decide to do so) off master branch.
> 
> Any objections to these plans?
> 
> -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

AW: Script task specification

[jhm]

The AntXMLContext stores the id-object pair in the project instance via 
public void configureId(Object element, Attributes attr) {
String id = attr.getValue("id");
if (id != null) {
project.addIdReference(id, element);
}
}

In the Projct class this is stored in a HashMap

/** Map of id references - used for indicating broken build files */
private final HashMap idReferences = new HashMap<>();

public void addIdReference(final String id, final Object value) {
idReferences.put(id, value);
}

But I haven't found a place where this private field is read...


Jan



> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Dienstag, 29. Oktober 2019 08:48
> An: 'Ant Developers List'
> Betreff: AW: Script task specification
> 
> I placed some system-outs in the parsing code.
> The parsing is done by ProjectHelper2. Id is stored via AntXMLContext to
> the "UnknownElement".
> 
> C:\projekte\apache-ant-svn\sandbox\script>ant
> Buildfile: C:\projekte\apache-ant-svn\sandbox\script\build.xml
> PH2.ElemeentHandler.onStartElement  tag=echo  taskname=echo
> AntXMLContext.configureId
> element=org.apache.tools.ant.UnknownElement@1f89ab83  id=foo
> PH2.ElemeentHandler.onStartElement  tag=script  taskname=script
> AntXMLContext.configureId
> element=org.apache.tools.ant.UnknownElement@383534aa  id=null
> 
> 
> main:
>[script] PH2.ElemeentHandler.onStartElement  tag=antlib
> taskname=antlib
>[script] AntXMLContext.configureId
> element=org.apache.tools.ant.UnknownElement@50cbc42f  id=null
>[script] PH2.ElemeentHandler.onStartElement  tag=componentdef
> taskname=componentdef
> ... more element definitions ...
> 
> BUILD FAILED
> C:\projekte\apache-ant-svn\sandbox\script\build.xml:9:
> org.mozilla.javascript.EcmaError: ReferenceError: "foo" is not defined.
> 
> 
> 
> Jan
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> > Gesendet: Dienstag, 29. Oktober 2019 08:03
> > An: 'Ant Developers List'
> > Betreff: AW: Script task specification
> >
> > It seems that the task must be executed before.
> > If you add a >depends="sub"< on the main target, that works.
> >
> > So the question is: when are id's stored?
> > The parsing is done via ProjectHelper's and their SAX-Parser-Handlers.
> > On the first view I would say, that the id is stored while parsing -
> > so before exucution.
> >
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > > Gesendet: Montag, 28. Oktober 2019 14:25
> > > An: Ant Developers List
> > > Betreff: Script task specification
> > >
> > > The documentation of the script task states:
> > >
> > > "All items (tasks, targets, etc) of the running project are
> > > accessible from the script, using either their name or id attributes
> > > (as long as their names are considered valid Java identifiers, that
> is). "
> > >
> > > However, the following fails:
> > >
> > > 
> > > 
> > >   
> > > Executing a task
> > >   
> > >
> > >   
> > >   
> > > <![CDATA[
> > > foo.setMessage("I'm a foo!")
> > > sub.execute()
> > > ]]>
> > >   
> > > 
> > >
> > > Surely there are more limitations? Besides, failure modes are
> > > different in Rhino (unable to create engine) and Nashorn (reference
> > not defined).
> > >
> > > Regards,
> > > 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



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

AW: Script task specification

[jhm]

I placed some system-outs in the parsing code.
The parsing is done by ProjectHelper2. Id is stored via AntXMLContext to the 
"UnknownElement".

C:\projekte\apache-ant-svn\sandbox\script>ant
Buildfile: C:\projekte\apache-ant-svn\sandbox\script\build.xml
PH2.ElemeentHandler.onStartElement  tag=echo  taskname=echo
AntXMLContext.configureId  element=org.apache.tools.ant.UnknownElement@1f89ab83 
 id=foo
PH2.ElemeentHandler.onStartElement  tag=script  taskname=script
AntXMLContext.configureId  element=org.apache.tools.ant.UnknownElement@383534aa 
 id=null


main:
   [script] PH2.ElemeentHandler.onStartElement  tag=antlib  taskname=antlib
   [script] AntXMLContext.configureId  
element=org.apache.tools.ant.UnknownElement@50cbc42f  id=null
   [script] PH2.ElemeentHandler.onStartElement  tag=componentdef  
taskname=componentdef
... more element definitions ...

BUILD FAILED
C:\projekte\apache-ant-svn\sandbox\script\build.xml:9: 
org.mozilla.javascript.EcmaError: ReferenceError: "foo" is not defined.



Jan


> -Ursprüngliche Nachricht-----
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Dienstag, 29. Oktober 2019 08:03
> An: 'Ant Developers List'
> Betreff: AW: Script task specification
> 
> It seems that the task must be executed before.
> If you add a >depends="sub"< on the main target, that works.
> 
> So the question is: when are id's stored?
> The parsing is done via ProjectHelper's and their SAX-Parser-Handlers.
> On the first view I would say, that the id is stored while parsing - so
> before exucution.
> 
> 
> Jan
> 
> > -Ursprüngliche Nachricht-
> > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > Gesendet: Montag, 28. Oktober 2019 14:25
> > An: Ant Developers List
> > Betreff: Script task specification
> >
> > The documentation of the script task states:
> >
> > "All items (tasks, targets, etc) of the running project are accessible
> > from the script, using either their name or id attributes (as long as
> > their names are considered valid Java identifiers, that is). "
> >
> > However, the following fails:
> >
> > 
> > 
> >   
> > Executing a task
> >   
> >
> >   
> >   
> > <![CDATA[
> > foo.setMessage("I'm a foo!")
> > sub.execute()
> > ]]>
> >   
> > 
> >
> > Surely there are more limitations? Besides, failure modes are
> > different in Rhino (unable to create engine) and Nashorn (reference
> not defined).
> >
> > Regards,
> > 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

AW: Script task specification

[jhm]

It seems that the task must be executed before.
If you add a >depends="sub"< on the main target, that works.

So the question is: when are id's stored?
The parsing is done via ProjectHelper's and their SAX-Parser-Handlers.
On the first view I would say, that the id is stored while parsing - so before 
exucution.


Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Montag, 28. Oktober 2019 14:25
> An: Ant Developers List
> Betreff: Script task specification
> 
> The documentation of the script task states:
> 
> "All items (tasks, targets, etc) of the running project are accessible
> from the script, using either their name or id attributes (as long as
> their names are considered valid Java identifiers, that is). "
> 
> However, the following fails:
> 
> 
> 
>   
> Executing a task
>   
> 
>   
>   
>  foo.setMessage("I'm a foo!")
> sub.execute()
> ]]>
>   
> 
> 
> Surely there are more limitations? Besides, failure modes are different
> in Rhino (unable to create engine) and Nashorn (reference not defined).
> 
> Regards,
> Gintas


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

AW: AW: [VOTE] Release Ivy 2.5.0 based on RC1

[jhm]

> > Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which
> seems to be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?
> Yes, looks like it.
> https://github.com/apache/ant-ivy/blob/master/build.xml#L263. It was
> done way back in 2007 and I don't think anyone uses that reference
> anymore. After this release, maybe we can stop copying and releasing
> that file.


Done


> >
> > Hello-Ivy-Example:
> > - run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
> > --> Ivy starts
> > --> Ivy vesion 2.5.0
> > --> Problems with downloading the dependencies:
> >
> > [ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
> > [ivy:retrieve] You probably access the destination server through a proxy 
> > server that is not well configured.
> > Another try:
> >   ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run and that worked.
> 
> I gave this example a try with this released version and it went fine
> without those warnings or errors. I suspect your Ivy cache probably had
> already downloaded the metadata/resources previously using some other
> "resolver"?

Deleted %userprofile%/.ivy2 and it worked without the -autoproxy.


Jan



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

AW: Need help releasing IVY project in JIRA

[jhm]

done

Jan

> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Donnerstag, 24. Oktober 2019 13:42
> An: Ant Developers List
> Betreff: Need help releasing IVY project in JIRA
> 
> It looks like I don't have relevant permissions in JIRA to release the
> IVY project. Can someone with appropriate permissions at
> https://issues.apache.org/jira/browse/IVY please rename the "master"
> release https://issues.apache.org/jira/projects/IVY/versions/12343084
> to "2.5.0" and officially release it in JIRA?
> 
> Once done, please also create a new "master" release so that newer
> fixes can be tracked against it.
> 
> -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

AW: [VOTE] Release Ivy 2.5.0 based on RC1

[jhm]

Checked the bin.zip.
Seems to be ok.

Just a question: there is a file fr\jayasoft\ivy\ant\antlib.xml which seems to 
be a copy of org\apache\ivy\ant\antlib.xml. Is it for BWC?

Hello-Ivy-Example:
- run with "ant -lib ..\..\..\ivy-2.5.0.jar run"
--> Ivy starts
--> Ivy vesion 2.5.0
--> Problems with downloading the dependencies:

[ivy:retrieve]  found commons-lang#commons-lang;2.6 in public
[ivy:retrieve] You probably access the destination server through a proxy 
server that is not well configured.

[ivy:retrieve] :: problems summary ::
[ivy:retrieve]  WARNINGS
[ivy:retrieve]  Host repo1.maven.org not found. 
url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
[ivy:retrieve]  Host repo1.maven.org not found. 
url=https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar
[ivy:retrieve]  module not found: commons-cli#commons-cli;1.4
[ivy:retrieve]   local: tried
[ivy:retrieve]
C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\ivys\ivy.xml
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
C:\Users\Jan\.ivy2\local\commons-cli\commons-cli\1.4\jars\commons-cli.jar
[ivy:retrieve]   shared: tried
[ivy:retrieve]
C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\ivys\ivy.xml
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
C:\Users\Jan\.ivy2\shared\commons-cli\commons-cli\1.4\jars\commons-cli.jar
[ivy:retrieve]   public: tried
[ivy:retrieve]
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.pom
[ivy:retrieve]-- artifact commons-cli#commons-cli;1.4!commons-cli.jar:
[ivy:retrieve]
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar

I dont have a proxy server I am aware of.
I could access the url 
https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar 
via browser.

Added a 'get' target which works:

https://repo1.maven.org/maven2/commons-cli/commons-cli/1.4/commons-cli-1.4.jar;
 dest="."/>


Another try:
  ant -lib ..\..\..\ivy-2.5.0.jar -autoproxy run
and that worked.


So a +1 from me.
Thanks for getting the release done.



Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Sonntag, 20. Oktober 2019 13:13
> An: Ant Developers List; ivy-u...@ant.apache.org; u...@ant.apache.org
> Betreff: [VOTE] Release Ivy 2.5.0 based on RC1
> 
> Hello everyone,
> 
> I have built a candidate release for Ivy 2.5.0.
> 
> It's been a long time since we have done a release of Ivy. 2.4.0 was
> released on December 26, 2014 after which it took a while to release
> the next version. We revived the project a few years later and many bug
> fixes and some enhancements were done. Thanks to Nicolas, 2.5.0-rc1 was
> released on Apr 19, 2018. We intentionally called it 2.5.0-rc1 because
> of the long delay we had between these releases and also the amount of
> changes that went it. We wanted to quickly release 2.5.0 after that,
> but various different reasons (some of them being newly reported bugs),
> it got delayed. However, its now time to officially release 2.5.0. This
> is my first release of Ivy project, so please do check out the release
> artifacts and vote accordingly and if you find anything amiss, please
> report. The complete set of changes that are part of this release
> (since
> 2.4.0) is listed here
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0-site-docs/release-
> notes.html.
> 
> The git tag for this release is:
> 
> https://gitbox.apache.org/repos/asf?p=ant-
> ivy.git;a=tag;h=refs/tags/2.5.0_Vote_RC1
> with SHA for this tag being 48234fc5ede85a865eb874a96c08472ce1751fd1
> 
> The artifacts has been published to:
> https://dist.apache.org/repos/dist/dev/ant/ivy/2.5.0/ at SVN
> revision 36396
> 
> The staging Maven repository is available at:
> 
> https://repository.apache.org/content/repositories/orgapacheant-
> 1043/org/apache/ivy/ivy/2.5.0/
> 
> The Eclipse updatesite is available here:
> 
> https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-
> 2.5.0.final_20191020104435/
> 
> 
> This vote will be open for at least 72 hours and will not close before
> 23rd October 2019 12:00 UTC.
> 
> - Jaikiran, Ivy 2.5.0 release manager, on behalf of Ivy team



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

AW: Windows declares a zip file as dangerous

[jhm]

It's more a Windows related question than an Ant one.
This message occurs with nearly every zip.

Solution seems to be registering your IPs as "secure".

https://superuser.com/questions/1231191/how-to-disable-zip-file-security-warning
https://superuser.com/questions/149056/disable-these-files-might-be-harmful-to-your-computer-warning


Jan

> -Ursprüngliche Nachricht-
> Von: Jochen Wiedmann [mailto:jochen.wiedm...@gmail.com]
> Gesendet: Dienstag, 9. Juli 2019 08:32
> An: dev@ant.apache.org
> Betreff: Windows declares a zip file as dangerous
> 
> Hi,
> 
> I've got a zip file, which has been created by Ant's Zip task:
> 
> 
> 
> 
> 
> Now, when I transfer this file from my Windows 7 build host to the test
> servers (Windows 7, or Windows 10) using basic Copy, and do a
> right click on the file, I get a message
> 
> "Opening these files might be harmful."
> 
> AFAICT, this is the same message, that I would get for opening a file,
> which has been downloaded via browser.
> 
> Question: Can I suppress this somehow?
> 
> Thanks,
> 
> Jochen
> 
> -
> 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

AW: New release?

[jhm]

> > It's been some months now since our last 1.9.x and 1.10.x Ant
> releases.
> > During that period, we have added some good number of fixes and
> > enhancements to both these versions upstream. Some of the users (in
> > bugzilla discussions) have asked if we can do a release sooner to get
> > these fixes. As far as I know, there isn't anything pending that
> needs
> > to go into this release. Is there any?
> 
> None I was aware of.

dito

> > Should we do a new release in the upcoming weeks?
> 
> Might be a good idea, yes.

+1


Jan


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

AW: [VOTE] Retire Antlib SVN

[jhm]

+1, as I think there aren't many users; and we could reactivate it on demand

Jan

> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Samstag, 22. Dezember 2018 03:16
> An: Ant Developers List
> Betreff: Re: [VOTE] Retire Antlib SVN
> 
> An implicit +1.
> 
> -Jaikiran
> 
> 
> On 22/12/18 7:39 AM, Jaikiran Pai wrote:
> > This is a proposal to retire the "Antlib SVN" library[1]. The project
> > hasn't seen any new development for many years now[2]. Retiring this
> > will reduce the work necessary to maintain it[3] (Jekins jobs
> etc...).
> >
> > More about retiring a project or a project component can be found
> here[4].
> >
> >
> > [1] http://ant.apache.org/antlibs/svn/
> >
> > [2] https://github.com/apache/ant-antlibs-svn/commits/master
> >
> > [3]
> > https://mail-archives.apache.org/mod_mbox/ant-
> dev/201812.mbox/%3c87k1k
> > 5wg7a@v45346.1blu.de%3e
> >
> > [4] http://ant.apache.org/processes.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

AW: Antlib SVN and antunit Java versions

[jhm]

Retiring a part of a top level project is much easier than retiring the TLP 
itself.
We have created a "process" while archiving EasyAnt & Co:
http://ant.apache.org/processes.html#Retire%20a%20subproject%20or%20component
Basically
* PMC vote for retiring the thing
* make resources read-only (code, mailinglists, issue tracker)
* clear all resources (build jobs)
* make it public (homepage, announcement)


Jan

> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Donnerstag, 20. Dezember 2018 14:52
> An: dev@ant.apache.org
> Betreff: Re: Antlib SVN and antunit Java versions
> 
> 
> On 19/12/18 11:29 PM, Stefan Bodewig wrote:
> > On 2018-12-18, Jaikiran Pai wrote:
> >
> >> One option in similar cases that we have employed in other jobs is
> to
> >> configure the Java system property -Dhttps.protocols to "TLSv1.2".
> >> But this version of TLS is only supported in a Java release after
> Java 1.5.
> > I'd be in favor of updating the jobs. Nobody would build releases
> > using Java 1.5 either, I guess.
> Done. I have updated the jobs of antlib svn and antunit to use Java 8
> to build it.
> 
> >
> >> At a more higher level, I think it's probably time to decide whether
> >> we want to change the minimum required Java versions for these
> libraries?
> >> Should we now mandate Java 1.8 at least?
> > In the case of antlib svn we could simply decide to call it dead or
> > dormant or whatever (like almost all other antlibs, I guess). Unless
> > I'm overlooking something, the svn antlib is neither listed on
> > http://ant.apache.org/antlibs/proper.html nor
> > http://ant.apache.org/antlibs/sandbox.html - so it doesn't even exist
> > from out user's point of view.
> I found this (live) page http://ant.apache.org/antlibs/svn/ the other
> day while looking at the Jenkins failure. But now that you mention it,
> I don't remember how I landed up on that page. I don't see it linked in
> the Jenkins job or some other place. But yes, I don't see it linked
> anywhere in the Ant website. I'll start a new VOTE thread to retire
> this project. I might need Jan's help here if/after the VOTE passes to
> actually do some of the process involved in retiring projects.
> 
> -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

AW: [VOTE] move over to gitbox.apache.org

[jhm]

+1 We are neither the first nor the only project which should migrate, so it 
should work smoothly. ;-) TODOs: change local remote urls, update Jenkins jobs, 
update homepage

Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Samstag, 8. Dezember 2018 02:13
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] move over to gitbox.apache.org
> 
> +1 for the move.
> 
> -Jaikiran
> 
> 
> On 07/12/18 10:29 PM, Stefan Bodewig wrote:
> > Hi all
> >
> > as indicated by Daniel we'll have to mover over sooner rather than
> > later anyway. So we may better do so now with no release in sight.
> >
> > Any objections or do we want to go ahead?
> >
> > 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

AW: Command line argument files

[jhm]

Thank you for your suggestion.
But I think we shouldn’t add a new dependency for replacing code, that works 
and was touched last time 8 months ago ('just' introducing some Java8 stuff), 
then 2 years ago (no FileInput/OutputStream::new) then 4 years ago ...

So maintenance is no real point here.

Jan

https://github.com/apache/ant/blame/master/src/main/org/apache/tools/ant/Main.java


> -Ursprüngliche Nachricht-
> Von: Remko Popma [mailto:remko.po...@gmail.com]
> Gesendet: Donnerstag, 15. November 2018 11:14
> An: dev@ant.apache.org
> Betreff: Command line argument files
> 
> Would there be any interest in using picocli (
> https://github.com/remkop/picocli) as the command line parser in
> `org.apache.tools.ant.Main`?
> 
> Picocli has support for @-files (https://picocli.info/#AtFiles ) to
> handle cases where the length of the command line exceeds the OS
> limitations. (I believe there was a recent request for this feature on
> the user list.)
> 
> The Main class will likely become shorter and easier to maintain.
> 
> As a bonus, picocli generates nice-looking help with ANSI colors and
> can generate completion scripts to get command line completion on bash
> and zsh shells.
> 
> The trade-off is the additional external dependency.
> 
> Picocli is relatively new (1.0 released in Aug 2017) but has growing
> adoption and is used in Groovy, Micronaut, JUnit 5 and CheckStyle.
> 
> I’d be happy to provide a PR if there’s interest.
> 
> Remko Popma


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

AW: Java 11 Compatibility Problem

[jhm]

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

AW: Jenkins-Builds failing

[jhm]

The jobs should be fixed now (regarding security settings).

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Sonntag, 2. September 2018 10:52
> An: Ant Developers List
> Betreff: Re: Jenkins-Builds failing
> 
> I see that Ant 1.9.13 is available as a choice, but Ivy Check job is
> still owned by hibou, and thus it is not possible to change the
> configuration.
> Is there a case about changing the ownership of all Ivy jobs? Or is it
> so that dependencies between Jenkins jobs are still an issue?
> 
> Gintas
> 
> On Mon, 13 Aug 2018 at 12:26, Jaikiran Pai  wrote:
> 
> > Noted. Just waiting for the infra team to sort out the access issue.
> >
> > -Jaikiran
> >
> >
> > On 12/08/18 2:28 AM, Gintautas Grigelionis wrote:
> > > Hi Jan and Jaikiran,
> > >
> > > looks like IvyDE trunk build needs attention, too (SSL protocol
> > > failure when resolving Checkstyle).
> > >
> > > Thanks, Gintas
> > >
> > > On Wed, 8 Aug 2018 at 13:23, Jan Matèrne (jhm) 
> > wrote:
> > >
> > >> Tried to change from "Ant 1.9.9" to "Ant (latest)".
> > >> An "Ant 1.10.1" or an "Ant 1.9.9" are the latest available named
> > versions.
> > >>
> > >> Got an
> > >>   Access denied
> > >>   This job's current authorization strategy does not permit jhm to
> > modify
> > >> the job configuration
> > >>
> > >> Asked in https://issues.apache.org/jira/browse/INFRA-16799 for
> > >> checking+fixing all of our jobs.
> > >>
> > >>
> > >> Jan
> > >>
> > >>> -Ursprüngliche Nachricht-
> > >>> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> > >>> Gesendet: Montag, 6. August 2018 06:45
> > >>> An: dev@ant.apache.org
> > >>> Betreff: Re: Jenkins-Builds failing
> > >>>
> > >>> Sure, will fix it this week. Right now, I don't have necessary
> > >>> permissions to edit it.
> > >>>
> > >>> -Jaikiran
> > >>>
> > >>>
> > >>> On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
> > >>>> There's one more Jenkins job failing due to outdated Ant, Ivy
> > >>>> Check ( https://builds.apache.org/view/All/job/Ivy-check/).
> > >>>> Could you please check it, Jaikiran?
> > >>>>
> > >>>> Thanks, Gintas
> > >>>>
> > >>>> On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai 
> > >>> wrote:
> > >>>>> I would like to test/import a few more projects (that Nicolas
> > >>>>> mentioned in one the mails) locally into the latest upstream
> > >>>>> version of the IDE, before starting a release. I have only
> > >>>>> tested a few so
> > >>> far.
> > >>>>> -Jaikiran
> > >>>>>
> > >>>>> On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> > >>>>>> Thanks, Jaikiran. Would you be willing to restart the release
> > >>>>>> process for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43,
> > >>> Jaikiran
> > >>>>>> Pai  wrote:
> > >>>>>>> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> > >>>>>>>> Almost all jobs that I know of have been taken care of now.
> > >>>>>>>> There's a "Ivy-tests-Windows" job which is pending, but for
> > >>>>>>>> that
> > >>> I
> > >>>>>>>> need some help from infra team. I am discussing it with them
> > >>>>>>>> separately and I expect it to be resolved soon. I'll fix
> that
> > >>>>>>>> job
> > >>> tomorrow.
> > >>>>>>> This is now done too. -Jaikiran
> > >>>>>>> -
> -
> > >>>>>>> 
> > >>> -
> > >>>>>>> -- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> > >>>>>>> additional commands, e-mail: dev-h...@ant.apache.org
> > >>>>> ---
> -
> > >>>>> 
> > >>> -
> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> > >>> additional
> > >>>>> commands, e-mail: dev-h...@ant.apache.org
> > >>>>>
> > >>>>>
> > >>>
> > >>> -
> -
> > >>> --- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> > >>> additional commands, e-mail: dev-h...@ant.apache.org
> > >>
> > >>
> > >> --
> -
> > >> -- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> > >> additional commands, e-mail: dev-h...@ant.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> >
> >


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

AW: IVYDE-379

[jhm]

https://projects.apache.org/project.html?ant-ivy now reflects the DOAP from 
git, showing last version of 2.4.0.

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Mittwoch, 8. August 2018 22:07
> An: Ant Developers List
> Betreff: Re: IVYDE-379
> 
> Thanks, Jan, most locations look good, though Ivy still refers to
> Subversion. I'll check again tomorrow.
> 
> Gintas
> 
> On Wed, 8 Aug 2018 at 12:57, Jan Matèrne (jhm) 
> wrote:
> 
> > Changed in SVN.
> > 'Our' locations are now:
> >
> >   https://ant.apache.org/doap_Ant.rdf
> >   https://ant.apache.org/antlibs/antunit/doap_AntUnit.rdf
> > 
> >   
> >
> https://ant.apache.org/antlibs/compress/doap_CompressAntlib.rdf on>
> >
> > https://ant.apache.org/antlibs/dotnet/doap_DotnetAntlib.rdf
> > 
> >   https://ant.apache.org/antlibs/props/doap_PropsAntlib.rdf
> > 
> >   https://ant.apache.org/antlibs/vss/doap_VSSAntlib.rdf
> > 
> >   
> > https://git-wip-us.apache.org/repos/asf?p=ant-
> ivy.git;a=blob_plain;f=d
> > oap_Ivy.rdf;hb=HEAD
> > 
> >   
> > https://git-wip-us.apache.org/repos/asf?p=ant-
> ivyde.git;a=blob_plain;f
> > =doap_IvyDE.rdf;hb=HEAD
> > 
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> > > Gesendet: Dienstag, 7. August 2018 19:46
> > > An: Ant Developers List
> > > Betreff: IVYDE-379
> > >
> > > https://projects.apache.org still refers to DOAP files of Ant
> > > project in Subversion.
> > > Any idea of how
> > >
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/da
> > > ta/
> > > projects.xml
> > > is changed?
> > >
> > > 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

AW: Jenkins-Builds failing

[jhm]

Tried to change from "Ant 1.9.9" to "Ant (latest)".
An "Ant 1.10.1" or an "Ant 1.9.9" are the latest available named versions.

Got an 
  Access denied
  This job's current authorization strategy does not permit jhm to modify the 
job configuration

Asked in https://issues.apache.org/jira/browse/INFRA-16799 for checking+fixing 
all of our jobs.


Jan

> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jaiki...@apache.org]
> Gesendet: Montag, 6. August 2018 06:45
> An: dev@ant.apache.org
> Betreff: Re: Jenkins-Builds failing
> 
> Sure, will fix it this week. Right now, I don't have necessary
> permissions to edit it.
> 
> -Jaikiran
> 
> 
> On 05/08/18 8:58 PM, Gintautas Grigelionis wrote:
> > There's one more Jenkins job failing due to outdated Ant, Ivy Check (
> > https://builds.apache.org/view/All/job/Ivy-check/).
> > Could you please check it, Jaikiran?
> >
> > Thanks, Gintas
> >
> > On Sun, 29 Jul 2018 at 15:13, Jaikiran Pai 
> wrote:
> >
> >> I would like to test/import a few more projects (that Nicolas
> >> mentioned in one the mails) locally into the latest upstream version
> >> of the IDE, before starting a release. I have only tested a few so
> far.
> >>
> >> -Jaikiran
> >>
> >> On 28/07/18 2:28 PM, Gintautas Grigelionis wrote:
> >>> Thanks, Jaikiran. Would you be willing to restart the release
> >>> process for IvyDE now? Gintas On Fri, 27 Jul 2018 at 15:43,
> Jaikiran
> >>> Pai  wrote:
> >>>> On 25/07/18 6:45 PM, Jaikiran Pai wrote:
> >>>>> Almost all jobs that I know of have been taken care of now.
> >>>>> There's a "Ivy-tests-Windows" job which is pending, but for that
> I
> >>>>> need some help from infra team. I am discussing it with them
> >>>>> separately and I expect it to be resolved soon. I'll fix that job
> tomorrow.
> >>>> This is now done too. -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

AW: IVYDE-379

[jhm]

Changed in SVN.
'Our' locations are now:

  https://ant.apache.org/doap_Ant.rdf
  https://ant.apache.org/antlibs/antunit/doap_AntUnit.rdf
  
https://ant.apache.org/antlibs/compress/doap_CompressAntlib.rdf
  
https://ant.apache.org/antlibs/dotnet/doap_DotnetAntlib.rdf
  https://ant.apache.org/antlibs/props/doap_PropsAntlib.rdf
  https://ant.apache.org/antlibs/vss/doap_VSSAntlib.rdf
  
https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob_plain;f=doap_Ivy.rdf;hb=HEAD
  
https://git-wip-us.apache.org/repos/asf?p=ant-ivyde.git;a=blob_plain;f=doap_IvyDE.rdf;hb=HEAD

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Dienstag, 7. August 2018 19:46
> An: Ant Developers List
> Betreff: IVYDE-379
> 
> https://projects.apache.org still refers to DOAP files of Ant project
> in Subversion.
> Any idea of how
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/
> projects.xml
> is changed?
> 
> Gintas


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

AW: Jenkins-Builds failing

[jhm]

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


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

AW: Jenkins-Builds failing

[jhm]

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

AW: Jenkins-Builds failing

[jhm]

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-2018-
> 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
> >
> >
> >> https://repo1.maven.org/maven2/org/apache/ant/ant-
> testutil/1.8.1/ant-
> >> testuti
> > l-1.8.1.pom
> > <
> >> https://repo1.maven.org/maven2/org/apache/ant/ant-
> testutil/1.8.1/ant-
> >> testutil-1.8.1.pom
> > (javax.net.ssl.SSLException: Received fatal alert:
> > protocol_version)
> >
> >
> >
> >
> >
> > AntLib - SVN
> >
> > same problem as for AU
> >
> >
> >
> >
> >
> > Ivy
> >
> > https://builds.apache.org/view/A/view/Ant/job/Ivy/
> >
> >
> https://builds.apache.org/view/A/view/Ant/job/Ivy/lastBuild/consol
> > e
> >
> > same problem as for AU
> >
> >
> >
> >
> >
> > Ant Nightly
> >
> > https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/
> >
> >
> >
> >>
> https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/lastBuild/c
> >> onsole
> > all runs fine, but "Archiving artifacts" requires lt of time
> …
> >
> >
> >
> >
> >
> > Ideas?
> >
> >
> >
> > Jan
> >
> >
> >>
> >> 
> -
> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> additional
> >> commands, e-mail: dev-h...@ant.apache.org
> >>
> >>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: ant task mail fails on jdk10

[jhm]

Did my own test:

 
 
 
Ant-Version:  ${ant.version}
Java-Version: ${java.version}
 
 

Running with Java8 + Java10, and I got my two mails:

Ant-Version:  Apache Ant(TM) version 1.10.1 compiled on February
2 2017
Java-Version: 1.8.0_171

respectively

Ant-Version:  Apache Ant(TM) version 1.10.1 compiled on February
2 2017
Java-Version: 10.0.1


I contrast to my last mail, I could install activation via fetch.xml.
I had run "ant -f fetch -Ddest=system" before.


Jan



> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Dienstag, 3. Juli 2018 07:43
> An: 'Ant Developers List'
> Betreff: AW: ant task mail fails on jdk10
> 
> We already have something:
> mail: "This task may depend on external libraries that are not included
> in the Ant distribution. See Library Dependencies for more
> information."
> dependencies:
> "mail.jar Mail task with Mime encoding, and the MimeMail task
> http://www.oracle.com/technetwork/java/index-138643.html
>  activation.jar   Mail task with Mime encoding, and the MimeMail task
> http://www.oracle.com/technetwork/java/javase/jaf-135115.html;
> 
> mail.jar could be downloaded via "ant -f fetch.xml javamail", but
> activation has to be installed.
> 
> 
> So what changed with Java10?
> 
> 
> Jan
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: Stefan Bodewig [mailto:bode...@apache.org]
> > Gesendet: Montag, 2. Juli 2018 18:00
> > An: dev@ant.apache.org; Simon IJskes - QCG
> > Betreff: Re: ant task mail fails on jdk10
> >
> > Thank you, Simon
> >
> > On 2018-07-02, Simon IJskes - QCG wrote:
> >
> > > As bugzilla is unreachable for now:
> >
> > > 
> > >  > > subject="Testemail"  >
> > > 
> > > 
> > > 
> >
> > > $ JAVA_HOME=/usr/lib/jvm/java-8-oracle/
> > > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> >
> > > runs ok.
> >
> > > _testmail:
> > >  [mail] Sending email: Testemail
> > >  [mail] Sent email with 0 attachments
> >
> >
> > > $ JAVA_HOME=/usr/lib/jvm/java-10-oracle/
> > > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> >
> > > _testmail:
> > >  [mail] Failed to send email: javax.activation.DataHandler
> >
> > JAF has been removed from Java 10, so now you need to provide its
> > replacement https://github.com/javaee/activation when starting Ant.
> >
> > I don't really think we need to change anything inside of Ant but
> > should document the fact and likely add something to the FAQ in
> > addition to the mail task's manual page.
> >
> > 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

AW: ant task mail fails on jdk10

[jhm]

We already have something:
mail: "This task may depend on external libraries that are not included in
the Ant distribution. See Library Dependencies for more information."
dependencies: 
"mail.jar   Mail task with Mime encoding, and the MimeMail task
http://www.oracle.com/technetwork/java/index-138643.html
 activation.jar Mail task with Mime encoding, and the MimeMail task
http://www.oracle.com/technetwork/java/javase/jaf-135115.html;

mail.jar could be downloaded via "ant -f fetch.xml javamail", but activation
has to be installed.


So what changed with Java10?


Jan


> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Montag, 2. Juli 2018 18:00
> An: dev@ant.apache.org; Simon IJskes - QCG
> Betreff: Re: ant task mail fails on jdk10
> 
> Thank you, Simon
> 
> On 2018-07-02, Simon IJskes - QCG wrote:
> 
> > As bugzilla is unreachable for now:
> 
> > 
> >  > subject="Testemail"  >
> > 
> > 
> > 
> 
> > $ JAVA_HOME=/usr/lib/jvm/java-8-oracle/
> > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> 
> > runs ok.
> 
> > _testmail:
> >  [mail] Sending email: Testemail
> >  [mail] Sent email with 0 attachments
> 
> 
> > $ JAVA_HOME=/usr/lib/jvm/java-10-oracle/
> > ~/opt/apache-ant-1.10.4/bin/ant _testmail
> 
> > _testmail:
> >  [mail] Failed to send email: javax.activation.DataHandler
> 
> JAF has been removed from Java 10, so now you need to provide its
> replacement https://github.com/javaee/activation when starting Ant.
> 
> I don't really think we need to change anything inside of Ant but
> should document the fact and likely add something to the FAQ in
> addition to the mail task's manual page.
> 
> 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

AW: Testing IvyDE

[jhm]

Due the update the permission for cancelling a job is gone.
https://jenkins.io/changelog-stable/
Notable changes since 2.107.3:
* It is no longer possible to rename jobs from their configuration page. Jobs 
now have a link in the side panel titled "Rename" that links to a page 
specifically dedicated to renaming jobs.
* The Job/Build permission no longer implies the Job/Cancel permission. The 
latter needs to be granted explicitly to users who previously got it via this 
relationship.
...

I'll check how we get that permission back (global grant by admin, posting a 
list via mail, jira...)


Jan

> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Sonntag, 1. Juli 2018 21:30
> An: 'Ant Developers List'
> Betreff: AW: Testing IvyDE
> 
> > It looks like Ant nightly is stuck (possibly due to plugin update in
> > Jenkins) and it's blocking all other builds.
> >
> > Gintas
> 
> I can't do it myself so I'll ask for killing the job.
> 
> Jan
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: Testing IvyDE

[jhm]

> It looks like Ant nightly is stuck (possibly due to plugin update in
> Jenkins) and it's blocking all other builds.
> 
> Gintas

I can't do it myself so I'll ask for killing the job.

Jan


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

AW: [Bug 33169] KIndly update the date feature

[jhm]

Thanks, will have a look tomorrow.
Sounds like we should keep BZ as it is.

Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Donnerstag, 28. Juni 2018 13:27
> An: dev@ant.apache.org
> Betreff: Re: [Bug 33169] KIndly update the date feature
> 
> On 2018-06-28, Stefan Bodewig wrote:
> 
> > The ASF installations allow everybody to create accounts and
> everybody
> > to create new issues. This is a deliberate choice and is the same for
> > JIRA and Bugzilla - and is the best choice for an open source project
> > IMHO.
> 
> > I'm not sure whether JIRA allows arbitrary users to modify existing
> > issues ither people have created. Of course you want everybody to be
> > able to comment, not so sure about the issue's title.
> 
> https://www.youtube.com/watch?v=MO_AVjSPuBw=PLq-odUc2x7i-
> 1f8XW3aYwGRc7YoWcCIxA=19
> 
> around minute 18 Mark explains why our Bugzilla is configured the way
> it is.
> 
> 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

AW: [Bug 33169] KIndly update the date feature

[jhm]

> > Just curious about our bugzilla infrastructure - do random users get
> > to change the content of these bugs, even if they aren't the ones who
> > reported the issue?
> 
> Yes.
> 
> Back when Bugzilla was introduced the developers and admins falsely
> assumed only sensible people would be using the tool.
> 
> Stefan

Do you know if JIRA is more secure?
Also against spam attacks?
If yes, we could about thinking to migrate ...

Jan


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

AW: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)

[jhm]

Changing Ants own test to use JUnit5 does not mean we have to change Ant itself 
and don't have to cut a release.

What do you want to move to "ant-legacy"?

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Donnerstag, 3. Mai 2018 20:46
> An: Ant Developers List
> Betreff: Re: Parameterized Tests (was Re: ant git commit: Inline
> buildfile names, make search easier)
> 
> IMHO that would mean putting parts of Ant core into ant-legacy.jar
> 
> Gintas
> 
> 2018-05-03 19:03 GMT+02:00 Matt Sicker :
> 
> > Yes, I'm definitely suggesting/hyping JUnit 5. :)
> >


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

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

[jhm]

> > In my eyes most of the committers don't like these "code style"
> changes.
> > So please stop these changes and invest your energy more productive.
> >
> > I don't think it would be helpful if another committer starts
> > reverting the changes because of a different preference ...
> 
> 
> With all due respect, please let me know what do you prefer: for
> instance, is test parametrization good, bad or annoying?


For that single point I think parametrization is 'good'.
If I count right, it impacted three test classes.
Why change all the others?

Starting a discussion before such big changes would also be helpful.

Jan





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

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

[jhm]

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


In my eyes most of the committers don't like these "code style" changes.
So please stop these changes and invest your energy more productive.

I don't think it would be helpful if another committer starts reverting the
changes because of a different preference ...


Jan




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

AW: Ant JUnit tests

[jhm]

Why not an assert with a meaningful message to test if the property is set?

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Freitag, 20. April 2018 10:42
> An: Ant Developers List
> Betreff: Re: Ant JUnit tests
> 
> Assumption is a "friendly reminder" -- the test is does not run unless
> the assumption is valid; the assumption provides an explanation of what
> is missing. My question was about how friendly we should be.
> 
> Gintas
> 
> 2018-04-20 7:14 GMT+02:00 Jaikiran Pai :
> 
> > Like discussed in the other thread, I don't understand what's wrong
> > with setting the expected properties in the IDE itself (like the
> "ant.home").
> > IDEs provide these configurations/settings for reasons like these.
> > What would it achieve by virtually disabling these tests, in IDE, by
> > adding those assumptions?
> >
> > -Jaikiran
> >
> >
> >
> > On 20/04/18 10:39 AM, Gintautas Grigelionis wrote:
> >
> >> 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?
> >>
> >> Thanks, 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

AW: Snapshot access to regular users of Ant

[jhm]

I dont see the automatic snapshots as a problem.
We should not ask "all" users to use them, but for single users that may be ok. 
They are "testing" (means DEV) the current/upcoming version against their 
(problematic) scenario.


Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Samstag, 17. März 2018 22:49
> An: Ant Developers List
> Betreff: Re: Snapshot access to regular users of Ant
> 
> Thanks for pointing this out. To me, it means one thing: release more
> often.
> The way I read it, publishing is not forbidden per se, but rather
> advertising.
> That's consistent with GitHub repo clones being available, but without
> "clone me at GitHub" ribbons.
> 
> On the other hand, I rewrote the manual (which was still talking about
> CVS), suggesting that the proper way to propose code changes would be a
> GitHub PR rather than an archive uploaded to Bugzilla, so please
> correct me if I'm wrong before Ant 1.10.3 gets released...
> 
> Gintas
> 
> 2018-03-17 13:07 GMT+01:00 Jaikiran Pai :
> 
> > I was about to send a mail to the user mailing list about the Ant
> > nightly job which publishes the daily snapshots, so that they can
> test
> > some bug fixes and new features (JUnit 5 in particular). However, I
> > happened to read the Apache release policy[1] which states regular
> > users aren't even meant to know about such snapshots.
> >
> > That seems a bit too restrictive, especially for open source
> projects.
> > Is that documentation being followed and if it is, then I guess I
> > shouldn't be letting the user@ mailing list know about these
> snapshots
> > nor ask them to test out the new feature?
> >
> > After reading that policy, I'm starting to wonder if the Jenkins job
> > should even publish these snapshots.
> >
> > [1] http://www.apache.org/legal/release-policy.html#publication
> >
> > -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

AW: Ivy old docs removed - documentation now resides under asciidoc

[jhm]

May /docs-to-convert ;)

A directory /doc makes the expectation to find (actual) documentation.


Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Dienstag, 13. März 2018 10:14
> An: Ant Developers List
> Betreff: Re: Ivy old docs removed - documentation now resides under
> asciidoc
> 
> There is some documentation that has not been converted to asciidoc (eg
> ideas.txt or conflict-solving-algo.html).
> I will put them into dev, or does anyone have a better idea?
> 
> Gintas
> 
> 2018-03-07 11:49 GMT+01:00 Jaikiran Pai :
> 
> > A while back we moved Ivy's documentation to Asciidoc. That automated
> > migration, thanks mainly to Nicolas, went off fine and we fixed
> > whatever issues we discovered in the migrated docs over a period of
> > time. At this point, the previous HTML and xooki based documentation
> is no longer needed.
> > So I went ahead and pushed a commit which removes that directory from
> > our repo. I don't expect it to be needed any more, but if we do need
> > it for reference, we can always go back to this commit and check it
> out.
> >
> > Going forward, the asciidoc based docs in the "asciidoc" directory of
> > the repo, is the place where documentation for the project resides.
> >
> > -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

AW: [GitHub] ant-ivy pull request #:

[jhm]

If the /doc directory is not maintained any more and all sources are now in
/asciidoc, it should be deleted.
If the /asciidoc/dev/makerelease.adoc is uptodate, feel free to change the
/ReleaseInstrutions to point there.

Jan

> -Ursprüngliche Nachricht-
> Von: twogee [mailto:g...@git.apache.org]
> Gesendet: Dienstag, 6. März 2018 18:24
> An: dev@ant.apache.org
> Betreff: [GitHub] ant-ivy pull request #:
> 
> Github user twogee commented on the pull request:
> 
> https://github.com/apache/ant-
> ivy/commit/8ed4a9bea706320d97ce2fd3e6545d7ebdf8a49b#commitcomment-
> 27956300
> 
> I believe we're using asciidoc now?
> 
> 
> ---
> 
> -
> 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

AW: Ant documentation

[jhm]

> > > > I made an attempt to convert the manual to HTML 5, the rationale
> > > being
> > > > that HTML 5 deprecates tt tag and recommends to replace it with
> > > > tags like code, kbd, samp and var, which could be used in a more
> > > consistent
> > > > way to achieve something closer to a semantic markup.
> > > >
> > > > I tried then to use the replacement tags as consistently as
> > > > possible in such a large body of text, but I realised that we
> > > > perhaps need a kind of a style guide. Would you like to discuss
> > > > it? Where would it best fit in the source code tree?
> > > >
> > >
> > > Isn't the HTML manual generated? Sure it's checked-in, but I
> thought
> > > there was a generation process.
> > > If that's the case (I may have dreamed it) then it's likely the
> > > generator that needs fixing, not the build product. --DD
> >
> > No. There were some experiments and maybe some pages were generated
> > during that experiment.
> > But the manual is a manual work. (double manual ;)
> > https://svn.apache.org/repos/asf/ant/sandbox/historical/xdocs/
> >
> 
> One may use xdoc and generate html with Doxia by calling its CLI.
> However, Ant sorely lacks a site generator on par with Maven site
> plugin.

All generation requires a model to generate from.
AFAIK the site-plugin uses the pom for this purpose.
We don't have such a model in Ant. 
Also I can't remember a wish for that.
Additionally I don't know any project (in my company) that uses these sites. 
Maybe
they are useful for open source projects.

I don’t think that we should spend any effort into that.
But Ant is an OS project - if you want to do a prototype you're welcome.


Jan


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

AW: Ant documentation

[jhm]

> > I made an attempt to convert the manual to HTML 5, the rationale
> being
> > that HTML 5 deprecates tt tag and recommends to replace it with tags
> > like code, kbd, samp and var, which could be used in a more
> consistent
> > way to achieve something closer to a semantic markup.
> >
> > I tried then to use the replacement tags as consistently as possible
> > in such a large body of text, but I realised that we perhaps need a
> > kind of a style guide. Would you like to discuss it? Where would it
> > best fit in the source code tree?
> >
> 
> Isn't the HTML manual generated? Sure it's checked-in, but I thought
> there was a generation process.
> If that's the case (I may have dreamed it) then it's likely the
> generator that needs fixing, not the build product. --DD

No. There were some experiments and maybe some pages were generated during that 
experiment.
But the manual is a manual work. (double manual ;)
https://svn.apache.org/repos/asf/ant/sandbox/historical/xdocs/


Jan


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

AW: svn commit: r1825596 - /ant/site/ant/build.xml

[jhm]

@Stefan: You added the 1.9 manual. Do you think we could upate the manuals this 
way?

Jan

> -Ursprüngliche Nachricht-
> Log:
> new target for updating the (online)manual from Ant's git-repo
> 
> Modified: ant/site/ant/build.xml
> URL:
> http://svn.apache.org/viewvc/ant/site/ant/build.xml?rev=1825596=1825
> 595=1825596=diff
> ==
> --- ant/site/ant/build.xml (original)
> +++ ant/site/ant/build.xml Wed Feb 28 19:40:02 2018
> @@ -84,6 +84,37 @@
>   encoding="iso-8859-1" outputencoding="utf-8"/>
>  
> 
> +
> +
> +https://git-wip-
> us.apache.org/repos/asf/ant.git"/>
> +
> +
> +
> +
> +
> + taskname="git">
> +
> +
> +
> +
> +
> +Copying manual from 1.9.x branch
> +
> +
> +
> +
> +
> +
> +
> +Copying manual from master branch
> +
> +
> +
> +
> +
> +
> +
> +
>   depends="anakia,fixcrlf" description="Create XDocs.">
>  
> 
> 



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

AW: Future of SVN repos

[jhm]

Thanks for the reminder, Matt. So we could stay on ASF infrastructure.
https://selfserve.apache.org/ 
but for git repos https://gitbox.apache.org/

Both forms require PMC-name, repo-name, repo-description, 
commit-notification-list and github-notification list.
But while (for me) the selfserve-form seems to be fully functional, the 
gitbox-form had no entries for the PMC listbox.


Jan

> -Ursprüngliche Nachricht-
> Von: Matt Sicker [mailto:boa...@gmail.com]
> Gesendet: Mittwoch, 28. Februar 2018 19:50
> An: Ant Developers List
> Betreff: Re: Future of SVN repos
> 
> Creating new git repos on apache is self-serve, so it's just as easy as
> GitHub really (though you need to be a PMC member I think).
> 
> On 28 February 2018 at 12:48, Jan Matèrne (jhm) <apa...@materne.de>
> wrote:
> 
> > > > If we want to migrate the site repo, we should also think about
> > > > handling the sandbox.
> > >
> > > I think we just never migrated it because it simply wasn't used.
> > > Using a single git repository for several unrelated experiments
> > > doesn't sound very git-like.
> >
> > Yep.
> > We could migrate site to git and then close all svn repos (make them
> > read-only).
> > If required someone could create a local git repo for new "sandbox
> > experiments". Shareable via github and later moving to ASF
> > infrastructure if it changes to be more than an experiment.
> >
> > What do you think?
> >
> >
> > Jan
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> >
> >
> 
> 
> --
> Matt Sicker <boa...@gmail.com>


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

Future of SVN repos

[jhm]

> > If we want to migrate the site repo, we should also think about
> > handling the sandbox.
> 
> I think we just never migrated it because it simply wasn't used. Using
> a single git repository for several unrelated experiments doesn't sound
> very git-like.

Yep.
We could migrate site to git and then close all svn repos (make them read-only).
If required someone could create a local git repo for new "sandbox 
experiments". Shareable via github and later moving to ASF infrastructure if it 
changes to be more than an experiment.

What do you think?


Jan


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

AW: committer += gintas

[jhm]

It seems that having the site in git is possible [1]:
- have your site in a git repo
- open a INFRA Jira-Ticket
- branch "asf-site" will be published

We have 7 svn repos [2], most inactive (migrated to git), 1 active and 1 not 
used for a longer time:
- antlibs, inactive repo, last change 2015, all migrated to git
- build, inactive repo, last change 2007, not used any more (I think)
- core, inactive repo, last change 2015, migrated to git
- easyant, inactive project
- ivy, inactive repo, last change 2015, migrated to git
? sandbox, unknown status, last change 2015, playground for ideas
+ site, active, last change 2weeks ago, website hosting

If we want to migrate the site repo, we should also think about handling the 
sandbox.

For the meantime I could add your name to the site.
Do you have some text I should add?


Jan


[1] https://blogs.apache.org/infra/entry/git_based_websites_available
[2] https://svn.apache.org/viewvc/ant/




> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Montag, 26. Februar 2018 09:46
> An: Ant Developers List
> Betreff: Re: committer += gintas
> 
> I was deferring that on purpose :-) see my previous e-mails regarding
> FishEye links or "Related Projects".
> Any chance of splitting of site sources to Git and using SVN for
> publication only?
> 
> Gintas
> 
> 2018-02-26 8:10 GMT+01:00 Jan Matèrne (jhm) <apa...@materne.de>:
> 
> > I recognize that the contributor [1] page is not listing Gintas.
> >
> > @Gintas: Could you add yourself to the source file [2] in the SVN
> repo
> > for the website [3], run the build and commit it back, please?
> >
> >
> >
> > Jan
> >
> >
> >
> >
> >
> > [1] http://ant.apache.org/contributors.html
> >
> > [2]
> >
> https://svn.apache.org/repos/asf/ant/site/ant/sources/contributors.xml
> >
> > //section[name="Committers"]/subsection[name="Active Committers"]
> >
> > [3] https://svn.apache.org/repos/asf/ant/site/
> >
> >
> >
> >


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

AW: ant-ivy git commit: initial WIP version of release instructions to follow for releasing Ivy

[jhm]

Have you seen doc/dev/makerelease.html ?
But updating (and maybe automating) is a good idea. ;)

Jan

> -Ursprüngliche Nachricht-
> Von: jaiki...@apache.org [mailto:jaiki...@apache.org]
> Gesendet: Dienstag, 27. Februar 2018 13:59
> An: notificati...@ant.apache.org
> Betreff: ant-ivy git commit: initial WIP version of release
> instructions to follow for releasing Ivy
> 
> Repository: ant-ivy
> Updated Branches:
>   refs/heads/master 86eacb6b5 -> 1a19f2f83
> 
> 
> initial WIP version of release instructions to follow for releasing Ivy
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/1a19f2f8
> Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/1a19f2f8
> Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/1a19f2f8
> 
> Branch: refs/heads/master
> Commit: 1a19f2f836cd33a25d458ed8ba9bbb3c7ce4ff96
> Parents: 86eacb6
> Author: Jaikiran Pai 
> Authored: Tue Feb 27 18:28:16 2018 +0530
> Committer: Jaikiran Pai 
> Committed: Tue Feb 27 18:28:16 2018 +0530
> 
> --
>  release-instructions.adoc | 186
> +
>  1 file changed, 186 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/1a19f2f8/release-
> instructions.adoc
> --
> diff --git a/release-instructions.adoc b/release-instructions.adoc new
> file mode 100644 index 000..ba8bd5d
> --- /dev/null
> +++ b/release-instructions.adoc
> @@ -0,0 +1,186 @@
> += Instructions for releasing Apache Ivy
> +
> +
> +NOTE: This document is adapted from the Ant release process.
> +
> +== Propose a release plan
> +
> +This should set out the timetable for the release under ideal
> circumstances. In reality, you send a note to the list that you intend
> to cut the release and wait for a few days whether anybody objects.
> +
> +We don't create extra branches for release and the release will be
> done from the `master` branch.
> +
> +This document assumes you are familiar with `git` http://git-
> scm.com/book/en/v2/ may be a good guide if you are not.
> +
> +== Checkout the repo
> +
> +We don't want tags for failed votes to end up on out branches so the
> release is first created from a detached head.
> +
> +Checkout the `HEAD` of the `master` branch as a detached head:
> +
> +[source]
> +
> +git checkout master^0
> +
> +
> +
> +Make sure that your directory tree is clean by running `git status`.
> +
> +== Update the version number
> +
> +The `version.properties` contains the version number of the Ivy
> project being released. Update the following properties to the right
> values (which is decided based on what version number and qualifier you
> want to associate with the release):
> +
> +[source]
> +
> +target.ivy.version=2.5.0
> +# Following OSGi spec: have to be 3 numbers separated by dots
> +target.ivy.bundle.version=2.5.0 # in case we want to add a qualifier
> +such as alpha, beta, etc...
> +# if non empty, add a '_' at the end of the qualifier, so the version
> +would look like 1.2.3.alpha_200901011200
> +target.ivy.bundle.version.qualifier=alpha_
> +
> +
> +== Trigger the release build
> +
> +Trigger the release by running the `build-release.xml`'s `release`
> target. This compiles the project, runs the tests, generates the
> documentation and tutorials and finally creates the distribution
> artifacts.
> +
> +[source]
> +
> +ant -f build-release.xml release
> +
> +
> +
> +Upon successful completion, the distribution artifacts will be
> generated in the `build/distrib` directory of the checked out project,
> locally.
> +
> +== Sign the distribution artifacts
> +
> +TODO: This section needs more details about setting up KEYS and making
> +them available to the public (similar to the Ant project's KEYS file
> in
> +the repo)
> +
> +The `build-release.xml` has a `sign` target which can be used to sign
> the generated distribution artifacts. Run the following command to sign
> these artifacts:
> +
> +[source]
> +
> +ant -f build-release.xml sign
> +
> +
> +== Commit the changes and create a RC tag for the release
> +
> +At this point the distribution artifacts have been generated and have
> been successfully signed too. We can now commit the changes (which most
> likely will just be the version file changes) and create a RC tag for
> the release.
> +
> +If we are releasing `2.5.0` and if this is the first RC for it, then
> we create a `2.5.0-RC1` tag for it.
> +
> +Be sure to replace the version number appropriately in the following
> command:
> +
> +[source]
> +
> +git tag -m "Release " 
> +
> +
> +The commit and the tag can now be pushed to the asf hosted repo:
> +
> +[source]
> +
> +git push --tags  

AW: Include user mailing list for RC release?

[jhm]

> We used to do so, even cut beta releases so people could test them
> years ago. Back then nobody tried the betas so we stopped doing them.
> I'm not saying we shouldn't include the user mailing list, let's just
> do that. I'm just a bit pessimistic this would have caught the problem.

Ok, but sending the mail to users@ doesn’t require much effort, but users
get the chance to react.

Jan




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

AW: Include user mailing list for RC release?

[jhm]

+1
We could post this info to users@ too and ask for feedback.
(Have to update the ReleaseInstructions on #14 ;)

Jan

> Our recent release of Ant showed up a major issue[1] which impact Ant
> users. The issue was found almost as soon as Ant was released, thanks
> to the user upgrading to this newer version. I think this is an issue
> which could have been caught before the release, in the RC, if more
> people tested the RC on their projects. I noticed that we send the VOTE
> mail, for RCs, just to the Ant dev list. I'm wondering if we should
> even include our Ant user mailing list for such RC votes, just to get
> some attention from a bit more wider audience who might be willing to
> run their projects against the RC, so that issues like these can
> hopefully be caught before we actually do a release.
> 
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62086
> 
> -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

AW: Mapped resources NPEs - Potential fix causes a failure in one specific test

[jhm]

> What this specific test failure shows, though, is that we now no longer
> are able to distinguish between a resource that we could copy but can't
> because it doesn't provide a name and the case of "all resources have
> been stripped out by mappers as "I don't know how to handle it".

 * @return an array of strings if the rule applies to the source file,
or
 * null if it does not.
 */
String[] mapFileName(String sourceFileName);

That means for me:
- can't handle:  return null
- no result: return new String[]{}


Jan



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

[SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability

[jhm]

CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security
vulnerability

 

Severity: low

Vendor: The Apache Software Foundation

Versions Affected:

  Apache Ant 1.9.0 - 1.9.9

  Apache Ant 1.10.0 - 1.10.1

  The unsupported Apache Ant 1.8 and lower versions are also affected.

Description:

  When using Apache Ants Log4jListener there could be a security issue with
the

  underlying Apache Log4j library in version 1.x. 

  Please note that Log4j 1.x has reached its end of life and is no longer
maintained. 

  For details about migrating away from Log4j 1.x please consult with the
Apache Log4j team.

Mitigation:

  Users should not use the Log4JListener or use the log4j2-bridge.

  (Using the bridge requires Ant 1.9.10+ or Ant 1.10.2+.)

Credit: 

  This issue was discovered by Wade Schwarz of Oracle.

 

 

-Jan Matèrne

on behalf of the Apache Ant PMC

AW: [VOTE] Release Apache Ant 1.10.2 based on RC1

[jhm]

+1
Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Samstag, 3. Februar 2018 18:07
> An: dev@ant.apache.org
> Betreff: [VOTE] Release Apache Ant 1.10.2 based on RC1
> 
> Hi all
> 
> I've created a release candidate for 1.10.2:
> 
> git tag: ANT_1.10.2_RC1
>  on commit: 0eba7eb
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>   revision: 24668
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-
> 1021/org/apache/ant/
> 
> This Vote will be open at least for 72 hours and close no earlier than
> 2018-02-06 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

AW: [VOTE] Release Ant 1.9.10 based on RC1

[jhm]

+1

Jan



https://dist.apache.org/repos/dist/dev/ant/manual/ does not contain the manual 
for 1.10.2, only 1.9.10.

Try apache-ant-1.9.10 on Java7
- ant -f fetch.xml all -Ddest=system
  ==> works, but downloading JAI fails:
Downloading: javax/media/jai-core/1.1.3/jai-core-1.1.3.pom from repository 
central at http://repo1.maven.org/maven2
Unable to locate resource in repository  
- license file present
- manual present, version correct
- "...1.9.10\...\bin\ant clean dist" on Ant's trunk (Java8)
  build.xml:904: Problem: failed to create task or type setpermissions
  ==> ok,  is Ant 1.10+, so that buildfile requires Ant 1.10+.


Try apache-ant-1.10.2 on Java8
- ant -f fetch.xml all -Ddest=system
  ==> works, but downloading JAI fails: 
- license file present
- manual present, version correct
- "...1.10.2\...\bin\ant clean dist" on Ant's trunk (Java8)
  ok


apache-ant-1.9.10-src
- try "build dist" with Java7 on Win7
  ==> ok


apache-ant-1.10.2-src
- try "build dist" with Java8 on Win7
  -- javadoc failes due 23 errors (missing libs)
 try "build dist -Djavadoc.notrequired=true" with Java8 on Win7
 -- 4 AntUnit tests are failing
setpermissions-test_xml:testRequiresNestedResources
Expected build failure with message 'At least one resource-collection 
is required' 
but was 'Problem: failed to create task or type setpermissions Cause: 
The name is undefined. ... 
tstamp-test_xml:testMagicPropertyIso
Expected property 'DSTAMP' to have value '19720417' but was '20180205'
tstamp-test_xml:testMagicPropertyBoth
Expected property 'DSTAMP' to have value '19720417' but was '19700102'
ownedby-test_xml:testRequiresOwner
Expected build failure with message 'the owner attribute is required' 
but was 'isfileselected doesn't support the nested "ownedBy" element.'
  ==> ok






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

AW: Java 9 test failures

[jhm]

> Well, the task wil not work with any future Java releases since the
> internal APIs are not comming back.
> 
> Meanwhile, a quick search shows that while there is quite a lot
> activity with image io, there is no equivalent of JAI.create() for
> image transformations (on which the image task is based). Maybe
> something to pitch to Sanselan/Commons Imaging?

I would prefer Apache Commons in a new antlib.
But on the other hand: do we know if the task is used?


Jan


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

AW: Cutting new releases?

[jhm]

> We should probably mention the deprecation of the log4j logger and the
> changes required to support the log4j2 bridge in WHATSNEW as well.

Done. Marked as "breaking BWC".

Jan


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

AW: Ant Nightly Build Job in Jenkins

[jhm]

https://builds.apache.org/view/A/view/Ant/job/Ant_Nightly/configure means:
ant -f launch-build.xml -Ddistribution
ant -f check.xml rat dumphtml simiancheck
where dumphtml=checkstyle+htmlreport


Haven't done a deep check what the SonarQube checks.
I think similarity checks could be included, but RAT checks are missing.
I don't think that RAT could be included in the SonarQube at the moment.


Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Sonntag, 28. Januar 2018 13:03
> An: dev@ant.apache.org
> Betreff: Re: Ant Nightly Build Job in Jenkins
> 
> On 2018-01-28, Stefan Bodewig wrote:
> 
> > On 2018-01-28, Jan Matèrne (jhm) wrote:
> 
> >> Updated the target to use actual 2.5.8.  But there is still a
> problem
> >> when using two formatters, so I commented the txt-formatter out.
> 
> BTW, does this build run any tools that are not also part of the
> SonarQube build?
> 
> 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

AW: Ant Nightly Build Job in Jenkins

[jhm]

Updated the target to use actual 2.5.8.
But there is still a problem when using two formatters, so I commented the 
txt-formatter out.

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Samstag, 27. Januar 2018 19:16
> An: Ant Developers List
> Betreff: Re: Ant Nightly Build Job in Jenkins
> 
> Simian stands for "similarity analysis" and is supposed to check for
> copy-paste code duplications.
> 
> I guess the older versions of simian disapper from the site as new
> versions are released. Currently, 2.5.8 is the latest version.
> There should be no harm updating to the latest version, ditto for
> checkstyle (Ivy project uses version 7, since version 8 as resolved by
> Ivy fails, and I did not have time to investigate what causes that yet)
> and findbugs.
> 
> Gintas
> 
> 
> 
> 2018-01-27 18:53 GMT+01:00 Stefan Bodewig :
> 
> > Hi all
> >
> > is anybody familiar with the things we try to do with the job called
> > "Ant Nightly"? It has been failing for months now and the reason is
> > not Ant but the build process which tries to download a
> > "simian-2.4.0.tar.gz" that simply doesn't exist at the expected URI.
> >
> > 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

AW: Cutting new releases?

[jhm]

Cool. ;)
Have committed my hint to the manual.
Nothing more in my pipeline ...

Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Freitag, 26. Januar 2018 18:45
> An: dev@ant.apache.org
> Betreff: Cutting new releases?
> 
> Hi all
> 
> while merging the latest changes I've saw master is now more than 200
> commits ahead of the 1.10.1 tag, maybe it is time for a release. :-)
> 
> I propose to cut 1.9.10 and 1.10.2 in parallel.
> 
> Does anybody feel either of the two branches isn't stable enough or is
> anybody currently working on/looking into soemthing that should delay
> releases?
> 
> 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

AW: Ivy-2.5.0

[jhm]

> What must be done to complete the work on SVG (IVY-922/IVY-450 or resp
> PR-55/PR-60)? If you fine with merging (eventually adjusting the
> contents of SVG), let's do it.

I added a comment on the PR.
For short:
- license header is missed on two files
- improve two JavaDocs
- test: does the fresh built Ivy use the SVG graphics?



> Changes to alleviate IVY-1315/IVY-1419/IVY-1420/IVY-1437 should be
> evaluated by reporters, but nobody responded because the issues are so
> old.
> I would rather close the issues and a open a new issue if needed. I

No. It's just a matter of prioritization by us.



> added test cases for every issue highlighting the specific parts of the
> problem and I can write up separately on the design problem with
> permitting the same attributes on different elements with recursive
> inheritance or using the same attribute name with different semantics
> depending on the element (perhaps in Confluence? or Github wiki?).

Can't understand the problem (haven't that knowledge of Ivy).
IVY-1315 "is related to" IVY-1420, which is resolved.
Is IVY-1315 also resolved? Then just close that issue.



> My opinion on PR-57 is that it addresses another design problem in a
> similarly good-enough fashion. We can handle this like Ant and have a
> Java
> 7 branch (2.5.x) and a Java 8+ branch with further API changes (2.6.x).
> The question is, whether that makes 2.5.x more interesting and is worth
> the extra work?

I wouldn't create an extra branch just for that.
I am more a fan of moving to a newer Java version after that release.

I recap the PR-57:
- multiple changes array->collection
- all are fine expect one
- one central public interface added one new method 
  -- no changes in semantics, but only in method declaration 
(array->collection, generics)
  -- technically one new method and deprecating the old
- this means breaking backwards compatibility
- proposal is adding a 2nd interface extending the original interface and 
adding that new method
  (could be 'inlined' in later Ivy version).

I followed the mail thread 
https://www.mail-archive.com/dev@ant.apache.org/msg46002.html and found another 
problem
- ModuleRules breaks BWC due the same reason (as you pointed it out).

Maybe we should not include this PR into an Ivy-2.5.0 release but instead move 
Ivy-2.6.0 to Java8 and change these parts in a (IMO) right but backwards 
incompatible way.



Jan


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

Ivy-2.5.0

[jhm]

I took my old TODO list for Ivy-2.5.0.

Most of them are still open, how to deal with that?

In my opinion we should try to get a release out and postpone these to a
2.5.1 (means reducing stopper->later).

We have lots of changes we could deliver in this way. We also show a sign of
life in that way.

 

 

Jan

 

 

 

- https://issues.apache.org/jira/browse/IVY-1485

  Incorrect revision of dependencies put in to delivered Ivy files

  Status:

11.09.2017: Jaikiran wanted to focus on that

  prio: stopper ("but it was IVY-1485 which reanimated the community")

 

- SVG-graphics

  Status:

08.01.2018: unknown

  prio: should be included, as it seems to be nearly finished (for me)

 

- https://github.com/apache/ant-ivy/pull/60

  use Unicode glyphs or SVG data URLs instead of bitmaps

  Status: 

11.09.2017: review required

08.01.2018: not sure what to do or what impact this have

  prio: should be included (as part of the "svg-bulk")

 

- https://github.com/apache/ant-ivy/pull/57

  fix the last inconsistencies in generics

  Status: 

11.09.2017: This includes a change which breaks BC

08.01.2018: no consense on the API change

  prio: solve that or delay (this PR should not delay the new version in my
opinion)

 

- https://github.com/apache/ant-ivy/pull/55

  use the vectorised logo

  Status: 

11.09.2017: nearly finished (missing header)

08.01.2018: no changes (license header missing)

  prio: include that as is nearly finished

 

- https://issues.apache.org/jira/browse/IVY-1420

  defaultconfmapping on  element is not written to
delivered ivy file

  Status: 

11.09.2017: "I need about a week"

08.01.2018: done (27.09.2017)

  prio: should be included

 

- upgrading BouncyCastle

  Status: done

 

- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride
attributes

  "according to ivy.xsd, all three attributes can be used on both
dependencies and configurations. 

  So, it's the documentation that must be adjusted accordingly"

  Status: 

11.09.2017: open

08.01.2018: done

  prio: maybe delay (and open a Jira ticket)

 

 

AW: Unit tests in Ivy and Ant

[jhm]

IMO catching an exception only makes sense if you check that exception against 
certain assumptions or you expect that.
Otherwise the test runner will catch that (not excepted) and mark the test as 
failed.

If the current codebase differs from that, I would agree with simplifying that.


Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Montag, 4. Dezember 2017 17:23
> An: Ant Developers List
> Betreff: Unit tests in Ivy and Ant
> 
> Hello,
> 
> I decided to spend some time on unit tests in Ivy and Ant; I did some
> work on Ivy tests this summer and I feel that work is unfinished.
> 
> In particular, there was a conversation about the use of fail(); my
> feeling is that it is somewhat superfluous: there are assumptions for
> (de)activating tests, assertions and expected exceptions, and that
> should suffice for defining a test.
> 
> The way fail() is used in Ivy now mostly looks like a rethrow of
> unexpected exceptions to AssertionErrors (why?).
> 
> So, in a nutshell: I would like to minimize try/catch and if/else in
> unit tests and make them work without fail(). What do you think?
> 
> Gintas


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

(IVY-1502) Be a nice freedesktop citizen, move the ~/.ivy to the appropriate location

[jhm]

While I like the idea of having a common place for configuration (have to be 
backup-ed), caches (no need for backup), etc. I am not a fan of dealing with 
too many platform specific stuff. 
So I want to hear some more voices here ...

Has someone heard from that XDG-specification before?
Are there other "usually used directories" for other platforms than FreeDesktop?

If we decide to support this, I think I haven't found the right place, but 
IvySettings was my last location I had a view.
I could think about a mechanism that sets default values here according to 
their priority. *1 So the defaults for FreeDesktop would overwrite global Ivy 
defaults but not the values defined by the user (ivysettings.xml, system 
properties). And the FD defaults would also be available only on FD (damn, 
testability ...).


Jan

*1: Reminds me to Apache Deltaspike Config with its DataSources. ;)


-Ursprüngliche Nachricht-
Von: Simon Ochsenreither (JIRA) [mailto:j...@apache.org] 
Gesendet: Sonntag, 29. Oktober 2017 14:23
An: notificati...@ant.apache.org
Betreff: [jira] [Commented] (IVY-1502) Be a nice freedesktop citizen, move the 
~/.ivy to the appropriate location


[ 
https://issues.apache.org/jira/browse/IVY-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223993#comment-16223993
 ] 

Simon Ochsenreither commented on IVY-1502:
------

Hi [~jhm], I have reviewed the code that implements the existing functionality, 
but no checks for the standard dirs happen there.

Of course it can be configured, but that's not the issue: The reason why people 
want applications and libraries to follow standards is that they don't want to 
configure each and every one of them manually.

>  Be a nice freedesktop citizen, move the ~/.ivy to the appropriate 
> location
> --
> --
>
> Key: IVY-1502
> URL: https://issues.apache.org/jira/browse/IVY-1502
> Project: Ivy
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3.0
> Environment: linux
>Reporter: PerfectCarl
>Priority: Minor
>
> According to the XDG specification [1], there is a better way to store the 
> user specific data of an application by dumping in new hidden folder in ~/.
> More information about it can be found [2] The specification defines 
> places to store the data so that the user profile can be updated and moved 
> properly while reducing some weird bugs.
> Those places would be ~/.local/ivy or ~/.cache/ivy and other 
> (depending on the data stored)
> [1]: 
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
> [2]: https://ploum.net/207-modify-your-application-to-use-xdg-folders/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


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

AW: Ivy upcoming release - where we stand

[jhm]

> I'm closing in on IVY-1420; it's Willem's patch + writeInheritedItems
> for entire inherited configurations/dependencies blocks (and another
> test case for that).

good.


> PR-57 breaks BC but mitigates that except for a special case. Anyway,
> why must every release be a drop-in replacement for the previous one?

It does not have to.
With a drop-in replacement it is easier to update for the users. ;-)
And with the upcoming 2.5.0 I would it make as easy as possible, because it is 
the first release after a long time.

We could discuss major or BC-breaking changes after that. Maybe call the next 
release 3.x ... 


Jan


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

AW: Ivy upcoming release - where we stand

[jhm]

I recap the todo list before a 2.5.0 release:

- https://issues.apache.org/jira/browse/IVY-1485
  Incorrect revision of dependencies put in to delivered Ivy files
  Status: Jaikiran wanted to focus on that (11.09.2017)
  prio: stopper ("but it was IVY-1485 which reanimated the community")

- https://issues.apache.org/jira/browse/IVY-1420
  defaultconfmapping on  element is not written to delivered 
ivy file
  Status: "I need about a week"
  prio: should be included

- SVG-graphics
  Status:
  prio: should be included, as it seems to be nearly finished (for me)

- upgrading BouncyCastle
  Status: done

- IVY-1420/IVY-1437, defaultconf/defaultconfmapping/confmappingoverride 
attributes
  "according to ivy.xsd, all three attributes can be used on both dependencies 
and configurations. 
  So, it's the documentation that must be adjusted accordingly"
  Status: open
  prio: maybe delay (and open a Jira ticket)

- https://github.com/apache/ant-ivy/pull/60
  use Unicode glyphs or SVG data URLs instead of bitmaps
  Status: review required
  prio: should be included (as part of the "svg-bulk")

- https://github.com/apache/ant-ivy/pull/57
  fix the last inconsistencies in generics
  Status: This includes a change which breaks BC
  prio: solve that or delay (this PR should not delay the new version in my 
opinion)

- https://github.com/apache/ant-ivy/pull/55
  use the vectorised logo
  Status: nearly finished (missing header)
  prio: include that as is nearly finished


Some comments/updates?


Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 25. September 2017 07:16
> An: dev@ant.apache.org
> Betreff: Re: Ivy upcoming release - where we stand
> 
> Since the latest released version of that library is 1.58, I think we
> should use that version, unless there's a specific reason to not use
> it.
> A quick compilation of Ivy with this library and checking their docs
> for JDK compatibility suggested no issues with 1.58.
> 
> -Jaikiran
> 
> 
> On 19/09/17 10:07 AM, Gintautas Grigelionis wrote:
> > I would like to propose upgrading BouncyCastle to at least 1.57 [1]
> to
> > include all security and PGP/GPG related fixes.
> >
> > 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

AW: IVY-450

[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

AW: Ivy - Move to symlink creation standard Java API?

[jhm]

If the new Java version supports the symlink creation and it's an 
implementation detail 
of Ivy (so not part of an API other could use) I am in favour of getting rid of 
the old 
implementation.
Getting rid of that means being more standard compliant and having less to 
maintain. ;)

Jan



> -Ursprüngliche Nachricht-
> Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> Gesendet: Mittwoch, 26. Juli 2017 18:19
> An: Ant Developers List
> Betreff: Re: Ivy - Move to symlink creation standard Java API?
> 
> 
> > Le 26 juil. 2017 à 15:25, Jaikiran Pai  a
> écrit :
> >
> > I was looking into a JIRA related to symlinking in Ivy and realized
> that (for reasons noted in the docs and the implementation)
> ourimplementation of symlinking relies on launching a process from
> within the JVM to invoke a shell command to create the symlinks.
> "retrieve" task is the only one that deals with symlink creation, from
> what I can see. Furthermore, knowing that this operation is expensive,
> we even had to introduce an additional optionfor that task to allow
> "mass symlinking"[1] so that we launch a single process to create N
> symlinks instead of N processes.
> >
> > In short, the current implementation of symlinking in Ivy is
> expensive for reasons that have been known. Now that we have moved to
> Java 7, which has a standard APIfor symlink creation[2], I think we
> should just change our internal implementation to use this new standard
> API.Of course, we continue to fail to create symlinks on systems that
> don't support it, just like we do now, except that we let the Java API
> implementation handle those details.
> >
> > Furthermore, once we move to thisstandard API, I don't think we need
> the "symlinkmass" option onthe retrieve task anymore since the whole
> purpose of it was to avoid launching N processes. So I think we can
> deprecate that option in the upcoming release.
> >
> > Any thoughts?
> 
> Sounds good to me.
> 
> 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

AW: Ivy - No more support for commons-httpclient 2.x in runtime classpath?

[jhm]

While it's fine to have such a dynamic behaviour it's hard to maintain.
On this special location - is it really required or could we use a fixed 
version 
(like current HttpComponents Client)
  https://hc.apache.org/:
  "HttpComponents Client is a successor of and replacement for Commons 
HttpClient 3.x. 
  Users of Commons HttpClient are strongly encouraged to upgrade."


So I'm +1 in dropping commons-http-2 support.
What about dropping commons-http-3 too? Here I can't see the requirement for 
having this 
dynamic loading (but maybe someone else).


Jan


> -Ursprüngliche Nachricht-
> Von: Jaikiran Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 24. Juli 2017 07:25
> An: dev@ant.apache.org
> Betreff: Ivy - No more support for commons-httpclient 2.x in runtime
> classpath?
> 
> 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_ [1].
> 
> At compile time, we use 3.x version of the library[2]. This leaves us
> in a bit of a problem in that if we use the recommended APIs in 3.x (at
> compile time) instead of the deprecated 2.x APIs or any 3.x API for
> that matter in our code, unless we mandate 3.x version of the library
> at runtime, users can run into classloading/library issues. Plus the
> fact that we can't easily support this 2.x vs 3.x usage in the same Ivy
> codebase.
> 
> So what I would like to propose is that for the upcoming release, we
> mandate 3.x as the version that we support and expect users to have
> that version of their library in the runtime classpath. In other words,
> we no longer support 2.x of commons-httpclient in the upcoming release.
> That will make it much more easier to manage the internal
> implementation details without having to juggle with versions of the
> library.
> 
> Any thoughts?
> 
> [1]
> https://github.com/apache/ant-
> ivy/blob/master/src/java/org/apache/ivy/util/url/HttpClientHandler.java
> #L224
> 
> [2] https://github.com/apache/ant-ivy/blob/master/ivy.xml#L47
> 
> 
> -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

AW: Proposed changes for IVY-735 - Ability to specify timeouts

[jhm]

Maybe you could set the timeout strategy globally:
/ivysettings/resolvers/@timeout-constraint


   
  
  ...
   
 
   
  
   



Jan


> -Ursprüngliche Nachricht-
> Von: jai.forums2...@gmail.com [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 17. Juli 2017 06:56
> An: dev@ant.apache.org
> Betreff: Re: Proposed changes for IVY-735 - Ability to specify timeouts
> 
> I think, that's actually a good idea. Defining the timeout constraints
> separately as named constraints and then referencing them would allow
> reusing these values on whichever resolvers want to:
> 
> 
> 
>   
> 
>   read-timeout="">
> 
>  ...
> 
>   
> 
>   
> 
>  
> 
>   
> 
> 
> 
> 
> -Jaikiran
> 
> 
> On 14/07/17 10:33 PM, Gintautas Grigelionis wrote:
> > my €.02 : currently, all resolvers only have artifact patterns as
> > child elements, so I'd rather have the timeouts as attributes that
> > might use references, similarly to cache managers or latest
> > strategies. That would imply a global default that may be overridden
> individually.
> >
> > Gintas
> >
> > 2017-07-14 13:34 GMT+02:00 :
> >
> >> https://issues.apache.org/jira/browse/IVY-735 is a feature request
> >> where the users have asked for relevant timeouts while dealing with
> >> downloads. A few weeks back we had a very brief discussion in an
> >> unrelated mail where it was proposed that we allow configuring these
> >> timeout all the way from ivy settings.
> >>
> >> I have an initial proposal/attempt to implement this feature. The
> >> initial changes are here in my personal repo[1]. It's a work in
> >> progress commit which sets up the necessary interfaces and the flow
> >> to show what I have in mind. Before proceeding further, I would like
> >> some inputs on whether this looks fine. Here's a summary of what the
> changes are going to be:
> >>
> >> - Each (dependency) resolver will have the ability to specify
> >> "timeout constraints"[2].
> >>
> >> - These timeout constraints will be specified while defining the
> >> resolver in the ivy settings file. Imagine something like:
> >>
> >>  
> >>
> >>  
> >>
> >>  
> >>
> >>   >> read-timeout=""/>
> >>
> >>  
> >>
> >>  
> >>
> >> - Each of the resolver will then use these timeout constraints (if
> >> specified) while resolving the module descriptor and downloading the
> >> artifacts and dealing with those resources.
> >>
> >> - The absence of the timeout constraints will let the resolvers
> >> behave the way they do currently
> >>
> >> The changes in the linked commit deprecate some APIs which weren't
> >> using timeouts and are replaced by APIs which pass along (an
> >> optional) TimeoutConstraints[2].
> >>
> >> In summary, the change being proposed is that (dependency) resolvers
> >> have the ability to specify these timeout constraints and then use
> >> them while dealing with module descriptors and artifacts. One thing
> I
> >> have (to some extent intentionally) left out is the ability to
> define
> >> a global Ivy settings level or "all resolvers" level
> >> timeout-constraints. That's because I'm not too sure if it adds much
> >> value instead of defining it at individual resolver level. I'm
> however open to adding that support as well.
> >>
> >> The linked commit currently doesn't have the necessary support for
> >> parsing these additional XML elements, but if this whole approach
> >> looks fine, I will take this further and make sure things work as
> expected.
> >>
> >> [1] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8
> >>
> >> [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb
> >>
> >>
> >> -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

AW: [VOTE] IvyDE requirements

[jhm]

summa summarum +2 ;-)

Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Dienstag, 11. Juli 2017 23:24
> An: Ant Developers List
> Betreff: Re: [VOTE] IvyDE requirements
> 
> +1 on both (having suggested it previously).
> 
> Gintas
> 
> 2017-07-11 23:07 GMT+02:00 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 <
> > 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

AW: Ivy jobs on Teamcity need reconfiguring

[jhm]

> >>> 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].
>
> Then I'd suggest migrating them to our own infrastructure.

+1, the TC jobs are out of our scope, the credentials always get lost ;) and 
ASF now has a powerful build environment.

Jan


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

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

[jhm]

Doc's mentioning 'how to document' must be updated.
I found http://ant.apache.org/ivy/write-doc.html Some more?

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

new committer: Jaikiran Pai

[jhm]

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

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

[jhm]

My first thought was 'I want to have all the stuff inside the distro.' That 
means also the ASC.
But having the ASC inside the distro means letting the key on the lock ...

So the 2nd thought was: how to verify the download?
- download
- hashvalue checksum
- pgp check
We could provide a howto file in the distro, but we also could provide a build 
snippet for automating that.
a) provide the snippet via website and define an Ant property which artifact to 
get
b) provide the snippet inside the distro and will only do the two checks 
(getting the checksums directly from the ASF server)


Jan


> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Mittwoch, 14. Juni 2017 09:17
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC3
> 
> On 2017-06-13, Jan Matèrne (jhm) wrote:
> 
> >> Should we include the PGP [e.g. 1] signature in the future?
> 
> > Answer myself: should be only on ASF server, so people could trust
> > that ;) Maybe place a note (next time) how to check that (do we have
> a
> > build snippet for that?)
> 
> I'm not exactly sure what you mean.
> 
> Should I have included the PGP signature of any of the artifacts inside
> of the vote email?
> 
> The vote email I've sent may have been a bit terse and I'm happy to
> improve on it.
> 
> 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

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

[jhm]

> Should we include the PGP [e.g. 1] signature in the future?

Answer myself: should be only on ASF server, so people could trust that ;)
Maybe place a note (next time) how to check that (do we have a build snippet
for that?)

Jan


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

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

[jhm]

+1
Should we include the PGP [e.g. 1] signature in the future?

Jan

[1]
https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/binaries/apache-
ant-compress-1.5-bin.zip.asc

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Samstag, 10. Juni 2017 22:39
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC3
> 
> On 2017-06-08, Stefan Bodewig wrote:
> 
> > 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.
> 
> +1
> 
> 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

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

[jhm]

+1
Jan

> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Dienstag, 6. Juni 2017 10:47
> An: Ant Developers List; Maarten Coene
> Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC2
> 
> +1 FWIW
> 
> Gintas
> 
> 2017-06-06 9:13 GMT+02:00 Maarten Coene
> :
> 
> > +1
> > Maarten
> >
> >
> >   Van: Stefan Bodewig 
> >  Aan: dev@ant.apache.org
> >  Verzonden: dinsdag 6 juni 6:26 2017
> >  Onderwerp: Re: [VOTE] Release Compress Antlib 1.5 based on RC2
> >
> > On 2017-06-01, Stefan Bodewig wrote:
> >
> > > I've created a new release candidate for Compress Antlib 1.5, this
> time
> > > with working Ivy coordinates and a release date three days into the
> > > future.
> >
> > > git tag: 1_5_RC2
> > >  on commit: f20847d
> > > tarballs:
> https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
> > >  revision: 19857
> > > Maven artifacts:
> > >  https://repository.apache.org/content/repositories/
> > orgapacheant-1018/org/apache/ant/ant-compress/1.5/
> >
> > > This Vote will be open at least for 72 hours and close no earlier
> than
> > > 2017-06-04 17:00UTC.
> >
> > Making my own vote explicit
> >
> > +1
> >
> > Actually, time seems to be up. Any other votes?
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
> >
> >
> >


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

AW: Ant Contrib

[jhm]

Some years ago there were a discussion about having ant-contrib a part of Ant.
Result was that it wasn't possible due IP (and therefore legal) reasons.

Having a look at the tasklist [1] there are some I would use:
* antcallback: maybe enhance  
* antfetch: maybe (same base idea as antcallback)
* assert: not required, you could use antunit
* foreach: no in favour of 'for'
* for: yep
* if: not required since xmlns:if is available
* outofdate: no idea
* runtarget: no: use  or  or 
* switch: maybe, but would be in contra to , you could use 
* throw: no, maybe enhance 
* timetstampselector: no; nice idea but I would investigate more in using 
resource collections and all existing selectors, not only the tstamp one
* trycatch: maybe
* httppost: yep
* antserver: no
* performancemonitor: no, use ProfileLogger [2]
* stopwatch: no, use [2]
* osfamily: use  condition
* shellscript: use 

PR-41: use of fonts

[jhm]

https://github.com/apache/ant-ivy/pull/41
  
I found a comment in hibgraph.svg: "Helvetica is a registered trademark
of Linotype AG".
I am not sure about using that in an Apache project ...
I'll forward this to the dev llist. Maybe to legal@a.o later ...

Does someone know if we are allowed to use helvetica font?

Jan


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

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

[jhm]

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

Jan

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



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

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

[jhm]

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


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


Jan


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

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

[jhm]

+1
Jan

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



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

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

[jhm]

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


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

AW: Ivy logo as SVG

[jhm]

The attachment didnt come thru.

I think EZMLM is configured not to send attachments ;)

 

Please open a JIRA ticket or a PR and we can discuss.

 

 

Jan

 

Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com] 
Gesendet: Freitag, 2. Juni 2017 06:46
An: Ant Developers List
Betreff: Re: Ivy logo as SVG

 

We may not be artists, but we can be aesthetes :-)

Please see an attached mockup of an Ivy report with proposed SVG icons and let 
me know what you think.

Gintas

 

2017-06-01 16:19 GMT+02:00 Gintautas Grigelionis :

Logo is important, especially when it ends up in every Ivy report.

Still, if there are no other way, I'm willing to give it a try :-)

 

Gintas

 

2017-06-01 15:44 GMT+02:00 Stefan Bodewig :

On 2017-06-01, Gintautas Grigelionis wrote:

> I noticed that ASF apparently has converted a bunch of project logos to
> SVG. In particular, Ant has an SVG logo.

That's not been done "by the ASF" but rather by some kind soul who did
the work. I'm afraid we are better coders than artists around here :-)

Stefan


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

 

 

Ivy buildjobs

[jhm]

I changed the Ivy build jobs to use Java7 instead of Java6.

 

Jan

[RESULT] [VOTE] Increase minimum Java version for Ivy to Java7

[jhm]

[RESULT] [VOTE] Increase minimum Java version for Ivy to Java7

Here is the result of the vote to increase the minimum Java
version from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0):

+1:
  Jan (binding)
  Jaikiran (non-binding)
  Gintautas (non-binding)
  Nicolas (binding)
  Dominique (binding)

-0:
  Maarten (binding)


So the vote passed and we can use Java7 from now.


Jan


> As discussed on this mailing list [1] we should increase the minimum
> Java version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
> Decisions whether to increase to Java8 after that release should be
> make after that release.
> According to the bylaws [3] this vote is open for one week (until
> 26.05.2017).
> 
> 
> [1]
http://mail-archives.apache.org/mod_mbox/ant-dev/201705.mbox/ajax/%3C87415C1
F-5EFF-4C81-8078-0276CC21A8ED%40gmail.com%3E 
> [2] http://ant.apache.org/ivy/history/latest-milestone/compatibility.html
> [3] http://ant.apache.org/bylaws.html 


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

AW: PR-33: problems

[jhm]

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?



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

AW: PR-33: problems

[jhm]

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.


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

AW: Replace emma with jacoco?

[jhm]

The task is having a code coverage.
The chosen tool should:
- do that ;)
- be free for OSS
- maintained
- useable by the project community (we have to use that ;)
- runnable in a CI environment

If a chosen tool (EMMA) does its job, you dont have to change this until
you'll get problems not to solve with that.
Then start an 'evaluation' ...

https://en.wikipedia.org/wiki/Java_Code_Coverage_Tools lists some tools.
EclEmma uses JaCoCo (as a replacement for EMMA). I think that some
developers are using that so using JaCoCo would be a fit to their toolset.


Jan

> -Ursprüngliche Nachricht-
> Von: Martin Gainty [mailto:mgai...@hotmail.com]
> Gesendet: Montag, 29. Mai 2017 00:58
> An: Ant Developers List
> Betreff: Re: Replace emma with jacoco?
> 
> 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 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 published an ant taskdef here
> 
> https://confluence.atlassian.com/clover/6-ant-task-reference-
> 71600066.html
> 
> 6. Ant Task Reference - Atlassian
> Documentation 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).
> 
> Emmas feature requests number 103 which nobody has addressed
> 
> https://sourceforge.net/p/emma/feature-requests/
> 
> EMMA code coverage / Feature Requests -
> sourceforge.net
> sourceforge.net
> I agree to receive quotes, newsletters and other information from
> sourceforge.net and its partners regarding IT services and products. I
> understand that I can ...
> 
> 
> WDYT of Clover?
> 
> Martin
> __
> 
> 
> 
> 
> From: Gintautas Grigelionis 
> Sent: Sunday, May 28, 2017 9:59 AM
> To: Ant Developers List
> Subject: Replace emma with jacoco?
> 
> As you could understand by now, I set a goal of getting all targets in
> build.xml to do what they are supposed to do. Which brings us to emma,
> which appears no longer being developed. Do we need a vote about a
> replacement?
> 
> Gintas


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

AW: build IvyDE

[jhm]

Nope, haven't read that.
My first contact to a build is always executing the build without any 
parameters. ;)

I'll have a look, thanks.


Jan

> -Ursprüngliche Nachricht-
> Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> Gesendet: Freitag, 26. Mai 2017 17:21
> An: Ant Developers List
> Betreff: Re: build IvyDE
> 
> 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
>  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
> >>
> >>



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

AW: Ivy website - fixing a Quickstart documentation live

[jhm]

+1 for asciidoc.
Using xooki means using a tool only few people know ...

Jan

> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Donnerstag, 25. Mai 2017 14:03
> An: Ant Developers List
> Betreff: Re: Ivy website - fixing a Quickstart documentation live
> 
> 
> On 25-May-2017, at 5:26 PM, Nicolas Lalevée
>  wrote:
> 
> 
> 
> > By the way, the Ivy documentation is managed by an hand crafted html
> editor, xooki, just is good but quite slow. I did some work some time
> ago (2 years ago, time flies!) to try to migrate to asciidoc [2]. I can
> even see that locally I have a commit which for some reason I didn’t
> pushed. If we are still interested, I can revive this.
> >
> 
> I’m very much interested in having the docs moved to asciidoc. I use it
> in almost every other project I deal with and it’s a big motivation to
> continue to write documentation and is definitely a big improvement on
> what we currently have. It doesn’t have to be something that we
> push/force in this release, but if we can transition to this
> documentation system, it’s going to be great.
> 
> -Jaikiran
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: Ivy website - fixing a Quickstart documentation live

[jhm]

The whole site is in svn and a server process (svnpubsub i think) is getting
the 'publish' files and pushing them to the webserver which brings them online.

We havent thought about a migrating that to git in the last few years ;)

If these files are really required, I could upload them.


Jan



> -Ursprüngliche Nachricht-
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Donnerstag, 25. Mai 2017 06:29
> An: Ant Developers List
> Betreff: Re: Ivy website - fixing a Quickstart documentation live
> 
> Is the documentation still in SVN? IVY-1542 is about site/sources/style
> which is shared by Ivy and IvyDE. Are there any plans about migrating
> this to Git and separating the source repo from publication repo?
> 
> Gintas
> 
> 2017-05-25 6:12 GMT+02:00 J Pai :
> 
> > What would be the process of having the live docs of Ivy project
> > updated to fix/update an issue in the documentation[1]?
> >
> > The quickstart documentation refers to certain log files that get
> > auto-generated during the doc build process. It looks like those log
> > files weren’t uploaded and are resulting in a blank text area showing
> > up. I can run the doc generation target locally (on 2.4.0 tag) and
> > have someone upload those files and see if shows up fine.
> >
> > [1] https://issues.apache.org/jira/browse/IVY-1542
> >
> > -Jaikiran
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> >
> >


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

AW: Ivy - Buildjobs/PreCommit

[jhm]

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


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) <apa...@materne.de>
> 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/ <https://builds.apache.org/view/A/view/Ant/job/Ant-Build-
> > Matrix-1.9.x-Windows/>
> > https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-1.9.x-
> > Linux/
> > <https://builds.apache.org/view/A/view/Ant/job/Ant-Build-Matrix-
> > 1.9.x-Linux/>
> > AFAIR, it used to be able to do on several different OS. I don’t know
> > why they are split.
> >
> > And I don’t know if it is possible to do it while pulling a PR from
> > github.
> 
> 
> New buildjob "Ivy-GithubPR-Matrix". I deactivated the old (so we could
> easily switch back).
> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR-Matrix/
> Basically a copy of the old job:
> * discard old build jobs (keep 10)
> * git merge support: fail the build if push fails
> * github project: git://github.com/apache/ant-ivy.git
> * git
>  -- repository: git://github.com/apache/ant-ivy.git
>  -- branches: */master (= default)
>  -- clean before checkout
>  -- recursively update submodules
>  -- build commits submitted for validated merge (= PR support)
> * start build: build pull request to the repository (= PR support)
> * configuration matrix
>  -- JDK: JDK 1.7 (latest), JDK 1.8 (latest), JDK 9 b156 with jigsaw
>  -- os: label expression = ["ubuntu", "Windows"]
> * abort the build if it's stuck: absolute 20 minutes
> * Lock: Ant
> * build
>  -- ant(standard): clean coverage-r

AW: Buildjob: IvyDE

[jhm]

I updated the job config and checked with 
https://github.com/apache/ant-ivyde/pull/5.
IvyDE-GitHub-Integration should (really) work now.

Jan

> -Ursprüngliche Nachricht-
> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
> Gesendet: Dienstag, 23. Mai 2017 15:57
> An: 'Ant Developers List'
> Betreff: AW: Buildjob: IvyDE
> 
> The Github-support was deactivated. (For an unknown reason) I
> reactivated that.
> Please try again.
> 
> Jan
> 
> > -Ursprüngliche Nachricht-
> > Von: J Pai [mailto:jai.forums2...@gmail.com]
> > Gesendet: Dienstag, 23. Mai 2017 12:20
> > An: Ant Developers List
> > Betreff: Re: Buildjob: IvyDE
> >
> > For some reason, this PR https://github.com/apache/ant-ivyde/pull/2
> > hasn’t yet triggered that IvyDE-Github job
> >
> > -Jaikiran
> > On 23-May-2017, at 12:54 AM, Jan Matèrne (jhm) <apa...@materne.de>
> > wrote:
> >
> > I changed the buildjobs for IvyDE + IvyDE-Github to use
> Java7(latest).
> > But I prefer to use the lowest Java version we have defined as
> minimum.
> > ;)
> >
> > Jan
> >
> > > -Ursprüngliche Nachricht-
> > > Von: J Pai [mailto:jai.forums2...@gmail.com]
> > > Gesendet: Montag, 22. Mai 2017 15:09
> > > An: Ant Developers List
> > > Betreff: Re: Buildjob: IvyDE
> > >
> > > Is there a chance you could trigger this build to run using Java 7?
> > > I read up a few JIRA posts for the INFRA project in
> > > issues.apache.org and they seem to indicate that this probably will
> > > work fine with builds that use Java 7. I’m not 100% sure though.
> > >
> > > -Jaikiran
> > > On 22-May-2017, at 6:30 PM, J Pai <jai.forums2...@gmail.com> wrote:
> > >
> > > That specific line in the build.xml[1] of the IvyDE project is
> > > trying to “get” the ivy.jar from a URL. In this case, it’s trying
> to
> > > fetch
> > it
> > > from:
> > >
> > >> [get] Getting:
> > >>
> > >
> >
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/a
> > >> rtifact/jars/ivy.jar
> > >
> > > Since it’s https backed, there’s a SSL handshake going on via this
> > > build process which is running on JRE 6 (upgrading to JRE 7 won’t
> > > solve the issue) and the builds.apache.org system while retrieving
> > the file.
> > > It looks like as noted here [2] that builds.apache.org is
> presenting
> > a
> > > certificate which JRE versions before JRE 8 don’t allow. The
> > > workaround presented in that FAQ is to switch the settings on the
> > > “server” which in this case would be builds.apache.org to use a
> > different cipher list.
> > >
> > > I’m not sure, if we will be allowed to do that and I’m curious how
> > > other builds (not necessary Ivy project builds) that need to fetch
> > > something from builds.apache.org via https and JRE <=7 get past
> this
> > > currently. Either way, I think this is something that we will have
> > > to ask the Apache infra team for their inputs.
> > >
> > >
> > > [1] https://github.com/apache/ant-ivyde/blob/master/build.xml#L277
> > > [2] http://httpd.apache.org/docs/current/ssl/ssl_faq.html#javadh
> > >
> > >
> > > -Jaikiran
> > > On 22-May-2017, at 2:04 PM, Jan Matèrne <j...@materne.de> wrote:
> > >
> > > I copied the IvyDE buildjob to have github support here.
> > >
> > > https://builds.apache.org/view/A/view/Ant/job/IvyDE-GithubPR/
> > >
> > >
> > >
> > > I changed IvyDE and IvyDE to not use "Ant latest" instead "Ant
> > 1.9.9",
> > > so it will work on Java<8.
> > >
> > >
> > >
> > > I started IvyDE and it gives me an error I could not interpret:
> > >
> > >
> https://builds.apache.org/view/A/view/Ant/job/IvyDE/lastBuild/consol
> > > e
> > >
> > >
> > >
> > > compute-ivy-bundle-version:
> > >  [mkdir] Created dir:
> > > /home/jenkins/jenkins-slave/workspace/IvyDE/work/ivy/jar
> > >[get] Getting:
> > >
> >
> <https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/
> > > a
> > > rtifa
> > > ct/jars/ivy.jar>
> > >
> >
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/a
> > > r
> > > tifac
> > > t/jars/ivy.ja

AW: [GitHub] ant-ivyde pull request #3: Update the year in copyright messages

[jhm]

I did a quick check - I've forgotten to change two more checkboxes in the
job configuration.
Have it done now.
Sorry

Jan

> -Ursprüngliche Nachricht-
> Von: jaikiran [mailto:g...@git.apache.org]
> Gesendet: Dienstag, 23. Mai 2017 16:09
> An: dev@ant.apache.org
> Betreff: [GitHub] ant-ivyde pull request #3: Update the year in
> copyright messages
> 
> GitHub user jaikiran opened a pull request:
> 
> https://github.com/apache/ant-ivyde/pull/3
> 
> Update the year in copyright messages
> 
> The commit here updates the year in copyright messages.
> 
> 
> 
> You can merge this pull request into a Git repository by running:
> 
> $ git pull https://github.com/jaikiran/ant-ivyde patch-1
> 
> Alternatively you can review and apply these changes as the patch at:
> 
> https://github.com/apache/ant-ivyde/pull/3.patch
> 
> To close this pull request, make a commit to your master/trunk branch
> with (at least) the following in the commit message:
> 
> This closes #3
> 
> 
> commit 59bbca2866b6ff2b4678e54fdfa77df5a331b4c2
> Author: Jaikiran 
> Date:   2017-05-23T10:16:59Z
> 
> Update the year in copyright messages
> 
> 
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have
> your reply appear on GitHub as well. If your project does not have this
> feature enabled and wishes so, or if the feature is enabled but not
> working, please contact infrastructure at infrastruct...@apache.org or
> file a JIRA ticket with INFRA.
> ---
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: Buildjob: IvyDE

[jhm]

The Github-support was deactivated. (For an unknown reason)
I reactivated that.
Please try again.

Jan

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

AW: Buildjob: IvyDE

[jhm]

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

Jan

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

AW: Ivy - Buildjobs/PreCommit

[jhm]

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


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


Jan


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

AW: Ivy - Buildjobs/PreCommit

[jhm]

I'll try setting up the PreCommit-Job as Matrix job with Linux/Window.

Jan



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

AW: Minimum Java runtime version for proposed upcoming Ivy release

[jhm]

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

Jan

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


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

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

[jhm]

Ok, thanks.

Jan

> -Ursprüngliche Nachricht-
> Von: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
> Gesendet: Mittwoch, 17. Mai 2017 15:37
> An: dev@ant.apache.org
> Betreff: Re: [jira] [Resolved] (IVY-1520) Have makepom task take
> description from ivy-module > info > description element
> 
> FYI, the things fixed in the master in git are marked in jira « master
> » as « fix version », so that we can just rename it when the release is
> done, wether we do a 2.5.0 or 2.4.x.
> Here we’ll indeed do a 2.5.0, but since others jira are already marked
> as on « master », I changed this one.
> 
> Nicolas
> 
> > Le 17 mai 2017 à 14:36, Jan Matèrne (JIRA)  a écrit
> :
> >
> >
> > [
> > https://issues.apache.org/jira/browse/IVY-
> 1520?page=com.atlassian.jira
> > .plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Jan Matèrne resolved IVY-1520.
> > --
> >   Resolution: Fixed
> >Fix Version/s: 2.5.0-RC1
> >
> >> Have makepom task take description from ivy-module > info >
> >> description element
> >> 
> -
> >> --
> >>
> >>Key: IVY-1520
> >>URL: https://issues.apache.org/jira/browse/IVY-1520
> >>Project: Ivy
> >> Issue Type: Improvement
> >> Components: Ant
> >>   Affects Versions: 2.4.0
> >>   Reporter: Eric Milles
> >>   Priority: Minor
> >>Fix For: 2.5.0-RC1
> >>
> >>
> >> I've been exploring the Ant ivy:makepom task in more detail and
> found that I can transfer the module, organisation and homepage from
> the original Ivy file but not the description.  The docs for makepom
> say that I can set property ivy.pom.description or use a description
> element.  But using either of these does not present me with a
> straightforward means of transferring the description from the resolved
> Ivy file.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: Ivy - Buildjobs/PreCommit

[jhm]

My last test result:
The Jenkins job could not load Findbugs. So I have deactivated that for the 
moment.

https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/6/console
ant-1.9.9> ant clean jar sources checkstyle-internal coverage-report 
  resolve:
  BUILD FAILED
  /.../build.xml:184: java.lang.ClassCastException: 
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor cannot be cast to 
org.apache.ivy.core.module.descriptor.ModuleDescriptor
at 
org.apache.ivy.ant.IvyPostResolveTask.getConfsToResolve(IvyPostResolveTask.java:233)
at 
org.apache.ivy.ant.IvyPostResolveTask.ensureResolved(IvyPostResolveTask.java:219)
at 
org.apache.ivy.ant.IvyPostResolveTask.prepareAndCheck(IvyPostResolveTask.java:179)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:88)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:272)

ant-1.9.9> ant -f build-release.xml -Drat.failOnError=false rat
  not run due to prior problems


Some ideas?


Jan


> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Mittwoch, 17. Mai 2017 13:18
> An: Ant Developers List
> Betreff: Re: Ivy - Buildjobs/PreCommit
> 
> Updated the same PR and that triggered this job
> https://builds.apache.org/job/Ivy-GithubPR/3/. It failed to build due
> to a host not being resolvable. This job ran on node called H15
> https://builds.apache.org/computer/H15/ whereas the first job which had
> succeeded had run on https://builds.apache.org/computer/qnode3/. Maybe
> all nodes are not equal and perhaps this job needs to be
> assigned/categorized to certain node groups?
> 
> -Jaikiran
> On 17-May-2017, at 4:03 PM, Jan Matèrne (jhm) <apa...@materne.de>
> wrote:
> 
> Thanks, I changed the job to run:
> 
> ant clean jar sources findbugs checkstyle-internal coverage-report ant
> -f build-release.xml -Drat.failOnError=false rat
> 
> Please try again ;)
> 
> 
> Jan
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: J Pai [mailto:jai.forums2...@gmail.com]
> > Gesendet: Mittwoch, 17. Mai 2017 10:53
> > An: Ant Developers List
> > Betreff: Re: Ivy - Buildjobs/PreCommit
> >
> > It turns out the PR you submitted was to your personal repo instead
> of
> > the apache repo. I just submitted a dummy PR to apache repo
> > https://github.com/apache/ant-ivy/pull/13 and that did indeed trigger
> > the Jenkins job https://builds.apache.org/view/A/view/Ant/job/Ivy-
> > GithubPR/1/ automagically :) I’m guessing this job isn’t running any
> > tests right now (given how quickly it finished)?
> >
> > This is good start to getting this working. Thanks for getting this
> > setup :)
> >
> > -Jaikiran
> >
> >
> > On 17-May-2017, at 2:07 PM, J Pai <jai.forums2...@gmail.com> wrote:
> >
> > Doesn’t look like it got triggered in Jenkins.
> >
> > -Jaikiran
> > On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm) <apa...@materne.de>
> > wrote:
> >
> >> I read the wiki page
> https://wiki.apache.org/general/PreCommitBuilds,
> >> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
> >> had a look at some other PreCommit-jobs.
> >> For me this works like that:
> >> 1. The PreCommit-Admin job checks regularly on for new patches in
> > Jira.
> >> 2. It invokes the "PreCommit-{JiraProject}" job mit Jira-ID and
> >> file-ID as argument.
> >> 3. The job does the rest.
> >>
> >> That means the job itself has to apply the patchfile - and of course
> >> run the build.
> >>
> >> On the other hand I found a blog post from infra
> >> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
> >> and set up an according job
> >> https://builds.apache.org/view/A/view/Ant/job/Ivy-GithubPR/
> >> This job uses the Github integration by Cloudbees Enterprise plugin.
> >> So next step for test would be a new/updated PR ...
> >
> > I've created a small PR https://github.com/janmaterne/ant-ivy/pull/1.
> > Now ... wait ;)
> >
> > Jan
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> > commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



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

AW: Ivy - Buildjobs/PreCommit

[jhm]

Thanks, I changed the job to run:

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

Please try again ;)


Jan


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



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

AW: Ivy - Buildjobs/PreCommit

[jhm]

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

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

Jan


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

AW: Ivy+IvyDE: help wanted

[jhm]

> On the ICLA front -  I already have contributed and continue to
> contribute to some other Apache projects (these days mostly via
> github). Do I still have to sign the ICLA? 

The ICLA is for the ASF - so you don't have to sign a new one if you already 
have submitted one.


> Is there a way to check if I
> have already signed this ICLA previously? I don’t remember if I was
> asked to do that for the other Apache projects.

I have checked a file, but haven't found your name (Jaikiran) nor your email 
adress.
So I think best would be sending a new one.


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

I'll try to have a look.


> - As I have noted in the past, in some mails[1] to the dev list, I am
> willing to help out in whatever way I can to move the project forward.
> As noted in some of those mails, I in no way have the complete
> understanding of the current codebase, but am willing to invest time as
> I go along to help fixing issues and adding enhancements wherever I
> can. 

That's a good starting point. ;)


> One of the recent things I had attempted was to triage some issues
> in the Ivy JIRA and see if we can come to a decision on pushing out a
> new release with at least a few of them fixed. That discussion did get
> some community discussion but couldn’t achieve much given that there
> wasn’t any actionable involvement from those who could really do a
> release. In short, I would like to give this another try and see how it
> goes.

Fine.
Maybe it would be a good start to cut a release with the current code base.
That would show possible problems with the release process and it's a 
prerequisite for later releases.


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

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


Jan



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

Ivy+IvyDE: help wanted

[jhm]

Hello community

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

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

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

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

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

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

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


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



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

AW: ivy for web

[jhm]

It seems to be a REST interface for an Ivy repository.
Start the webapp, configure Ivy according to the repo layout and ready to use.

Looks nice.
But it's written in Groovy (I am not against Groovy, but I am not sure if here 
is knowledge to maintain that).


Jan

> -Ursprüngliche Nachricht-
> Von: Dmitry Lukyanov [mailto:dlukya...@ukr.net]
> Gesendet: Montag, 27. März 2017 14:30
> An: dev@ant.apache.org
> Betreff: ivy for web
> 
> Hello All,
> 
> I've created a simple project to work with ivy It implements repository
> access and some commands useful for integration with ci-tools and other
> tools
> 
> Details, code and releases are here:
> https://github.com/char-com-ua/rest-ivy
> 
> Question: would it be interesting to be published under apache?
> 
> --
> Regards,
> Dmitry


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