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

[J Pai]

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

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

Hi all

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

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

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

Cheers

   Stefan

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



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

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

[J Pai]

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

-Jaikiran
On 03-Jun-2017, at 7:09 AM, J Pai  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)  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

[GitHub] ant-ivy pull request #40: Fix regression in tutorials

[jaikiran]

GitHub user jaikiran opened a pull request:

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

Fix regression in tutorials

The commit here fixes some issues in tutorials, that went unnoticed in some 
of our recent changes.

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

$ git pull https://github.com/jaikiran/ant-ivy fix-tutorial-regression

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

https://github.com/apache/ant-ivy/pull/40.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 #40


commit 95a524ea06e546330ec3d95b9c139b7edc599b86
Author: Jaikiran Pai 
Date:   2017-06-03T02:04:44Z

Fix regression in tutorials




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

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

[J Pai]

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

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

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


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


Jan


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



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

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

[GitHub] ant-ivy pull request #39: first batch of SVG replacements

[twogee]

GitHub user twogee opened a pull request:

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

first batch of SVG replacements

Try them out and enjoy! The images have their width and height removed, 
scaling must be controlled by CSS.

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

$ git pull https://github.com/twogee/ant-ivy master

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

https://github.com/apache/ant-ivy/pull/39.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 #39


commit 9ae8bf9f94ec82b815f8b0c7ea32881d9f7ab236
Author: twogee 
Date:   2017-06-02T15:37:04Z

first batch of SVG replacements




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

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[twogee]

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
Thanks! BTW I had to keep the "test-coverage" target as an alias because 
that's what the Jenkins scripts expect. That's another adjustment for later...


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

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

[J Pai]

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

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

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

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

[GitHub] ant-ivy pull request #36: Replace emma with jacoco

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

[J Pai]

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

-Jaikiran
On 02-Jun-2017, at 5:39 PM, Jan Matèrne (jhm)  wrote:

+1
Jan

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

[GitHub] ant-ivy pull request #38: IVY-1475 Throw an explicit BuildException if cache...

[jaikiran]

GitHub user jaikiran opened a pull request:

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

IVY-1475 Throw an explicit BuildException if cachefileset cannot determine 
a common base directory

The commit here enhances the implementation of `cachefileset` task to throw 
an explicit `BuildException` in cases where it cannot determine a common base 
directory for the `fileset` it is trying to create. Furthermore, the 
documentation of this task has been updated to add details about the limitation 
of this task and also  a pointer to an alternate task that can be used in 
certain cases.

This issue was raised in JIRA 
https://issues.apache.org/jira/browse/IVY-1475 and discussed in the ant-dev 
mailing list https://www.mail-archive.com/dev@ant.apache.org/msg45656.html

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

$ git pull https://github.com/jaikiran/ant-ivy ivy-1475

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

https://github.com/apache/ant-ivy/pull/38.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 #38


commit 6c547b1c6321f89edfae433af343bf38f9dbfe43
Author: Jaikiran Pai 
Date:   2017-06-02T11:27:36Z

IVY-1475 Throw an error if a common base directory cannot be determined for 
cachefileset task




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

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[janmaterne]

Github user janmaterne commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
Adressed the deletion by myself.
Left the ASM over for another time.
Merge all ...


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

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[janmaterne]

Github user janmaterne commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
While not having the result of the clean-run, what about deleting the 
jacoco.data file just before running ?

With ASM I could spend a little bit to do a check before ... (something 
like: rc = all jars with name = *asm*.jar and a loadable ASM.class; if 
rc.length>1 fail)


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

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[janmaterne]

Github user janmaterne commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
Stacktrace is:
C:\projekte\apache-ant\ivy-core\build.xml:492: Error while creating report
at org.jacoco.ant.ReportTask.execute(ReportTask.java:501)
Caused by: java.io.IOException: Error while analyzing 
org\apache\ivy\Ivy$1.class.
at 
org.jacoco.core.analysis.Analyzer.analyzerError(Analyzer.java:155)
Caused by: java.lang.IllegalStateException: Can't add different class with 
same name: org/apache/ivy/Ivy$1
at 
org.jacoco.core.analysis.CoverageBuilder.visitCoverage(CoverageBuilder.java:107)

I'll try a clean+test-report ...


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

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

[GitHub] ant-ivy issue #37: Don't pollute the source lib folder during ivy retrieval ...

[twogee]

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/37
  
:+1: 


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

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[twogee]

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
There are reports about the "log" file getting corrupt when it accumulates 
results from multiple runs. If 'ant clean' helps, then perhaps the "log" file 
must be removed in test-internal target before any tests are executed.


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

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

[Nicolas Lalevée]

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[janmaterne]

Github user janmaterne commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
First progress: found an old ASM on Ant's own classpath. Ant 1.9.6 loads 
that via fetch.xml. Different topic ...

JaCoCo runs fine. Report generation failed without any hint. Try running 
with -debug ...


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

Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at jdk.java.net/9/

[Rory O'Donnell]

Hi Stefan, **

*Announcing: Early-Access builds of JDK 9 for Alpine Linux/musl at  
jdk.java.net/9/ [1]

*

 * As of today there are pre-built Early-Access (EA) JDK binaries for
   Alpine Linux/musl at  jdk.java.net/9/**
 o look for “Alpine Linux”. [1]
 * The Alpine Linux build is compatible with linux distributions that
   use the musl C library. *[2]*

Feedback is very welcome via the portola-dev mailing list, remembering 
to subscribe to the mailing list first.



*Proposed schedule change for JDK 9 [3]*

   JDK 9 Project continues to work toward the current goal of producing
   an initial Release Candidate build on 22 June.
   This proposal is to adjust the GA date in order to accommodate the
   additional time required to move through the JCP process.
   To be specific, we propose to move the GA date out by eight weeks,
   from 27 July to 21 September. 



Rgds,Rory


[1] http://mail.openjdk.java.net/pipermail/portola-dev/2017-June/000191.html
[2] http://www.musl-libc.org/
[3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

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

[J Pai]

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

-Jaikiran
On 02-Jun-2017, at 2:55 PM, Nicolas Lalevée  wrote:


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

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

Nicolas

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


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



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

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

[Nicolas Lalevée]

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

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

Nicolas

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


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

PR-36

[Jan Matèrne]

>Gintas

> P.S. Could we please finish the PR #36? I'll look into adding Clover
separately.

 

I am currently having a look.

Actual status:

 

build.xml:480: java.lang.IncompatibleClassChangeError: class
org.jacoco.core.internal.flow.ClassProbesVisitor has interface
org.objectweb.asm.ClassVisitor as super class

...

at java.lang.ClassLoader.loadClass(Unknown Source)

at org.jacoco.ant.ReportTask.createBundle(ReportTask.java:563)

at org.jacoco.ant.ReportTask.createReport(ReportTask.java:542)

at org.jacoco.ant.ReportTask.execute(ReportTask.java:495)

 

 

You mentioned multiple/wrong ASM on the classpath. I am starting searching
...

 

 

Jan

Re: Ivy logo as SVG

[Gintautas Grigelionis]

If the choice of icons and/or colors is acceptable, I'll open a PR to burn
all gifs and embed svgs into xlts (whew, that was a bunch of abbreviations
:-)
I'm not quite sure if I could open a JIRA ticket -- or should it be a story?

Gintas

P.S. Could we please finish the PR #36? I'll look into adding Clover
separately.

2017-06-02 9:10 GMT+02:00 Stefan Bodewig :

> On 2017-06-02, Gintautas Grigelionis wrote:
>
> > Could we please check if a link works before we go any further?
>
> >   Ivy-report-ivy-by-org.apache.pdf
> >  XcySnBwU2otNHBBTW5j/view?usp=drivesdk>
>
> it does.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Ivy website - fixing a Quickstart documentation live

[J Pai]

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


-Jaikiran
On 26-May-2017, at 12:36 PM, J Pai  wrote:

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

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

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

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


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

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

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

-Jaikiran






On 26-May-2017, at 10:39 AM, J Pai  wrote:

Thanks everyone for the inputs.

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

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

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

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

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

Nicolas

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

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



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





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

Re: Ivy logo as SVG

[Stefan Bodewig]

On 2017-06-02, Gintautas Grigelionis wrote:

> Could we please check if a link works before we go any further?

>   Ivy-report-ivy-by-org.apache.pdf
> 

it does.

Stefan

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