Thanks everyone for the warm welcome :)
I’m really excited to be part of the team.
I’m sure most of the long-timers in this list don’t know me much, given that I
have been active in the lists only in the past year or so. So here’s a quick
intro about me (you can read a bit more about me here[
There’s been some good progress on reviving the Ivy project (thanks Nicolas and
Jan for helping out with the reviews and merging PRs) and we seem to be moving
towards a state where the release is a possibility. The other project IvyDE
(the Eclipse plugin) however needs a bit more push I think.
, instead of creating a PR. I
am not experienced with Eclipse plugins, so I personally won’t be able to help
much, but hopefully someone from the IvyDE team will be able to review and
decide about this patch. Thank you again for contributing this.
-Jaikiran
On 26-May-2017, at 8:28 AM, J Pai wrote
+1.
-Jaikiran
On 06-Jun-2017, at 9:56 AM, Stefan Bodewig wrote:
On 2017-06-01, Stefan Bodewig wrote:
> I've created a new release candidate for Compress Antlib 1.5, this time
> with working Ivy coordinates and a release date three days into the
> future.
> git tag: 1_5_RC2
> on commit:
) wrote:
merged.
We'll see the next nightly ...
Jan
> -Ursprüngliche Nachricht-
> Von: J Pai [mailto:jai.forums2...@gmail.com]
> Gesendet: Samstag, 3. Juni 2017 04:07
> An: Ant Developers List
> Betreff: Re: Ivy nightly builds - Generate a full .zip/.tar.gz
> sna
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:
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
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
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 t
> 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
elative 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-14
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
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
Thanks Nicolas.
-Jaikiran
On 01-Jun-2017, at 5:24 PM, Nicolas Lalevée wrote:
done.
Thanks
Nicolas
> Le 1 juin 2017 à 13:46, J Pai a écrit :
>
> The PR for this issue https://issues.apache.org/jira/browse/IVY-1528 was
> merged a few days back, but I think we forgot to resolve
The new organization being proposed “org.apache.ant” instead of “org/apache” is
the right way to go IMO. It’s not just Ivy and applies to Maven co-ordinates
(via pom.xml) as well. Ideally, they should match with each other. Using the
org.apache.ant would make it fit with the groupId (in Maven la
The PR for this issue https://issues.apache.org/jira/browse/IVY-1528 was merged
a few days back, but I think we forgot to resolve the JIRA and include this in
the release notes. Can someone with the access rights please do so?
-Jaikiran
---
On 31-May-2017, at 9:02 PM, Nicolas Lalevée wrote:
> Le 31 mai 2017 à 15:34, J Pai a écrit :
>
> One thing I just noticed in the generated adoc files is that “external” links
> that are part of the original xooki backed .html files are not being
> generated as links in the
[features]].
-Jaikiran
On 31-May-2017, at 6:50 PM, J Pai wrote:
I had some time today and decided to test this branch out locally. I was able
to generate the docs without any hassle. The conversion works fine which is a
great thing.
There are certain warning about the heading/section level we use in the
I had some time today and decided to test this branch out locally. I was able
to generate the docs without any hassle. The conversion works fine which is a
great thing.
There are certain warning about the heading/section level we use in the
generated adoc files, for top level heading:
> [ascii
Just had a look at that ivysettings-nexus.xml file. You are right, changing
that file should fix it.
-Jaikiran
On 31-May-2017, at 5:43 PM, Stefan Bodewig wrote:
On 2017-05-31, J Pai wrote:
> These are the changes (which incorporates Gintas suggestion) that
> might help get us past the
These are the changes (which incorporates Gintas suggestion) that might help
get us past the upload issue.
Change to ivy.xml of compress project:
diff --git a/ivy.xml b/ivy.xml
index eb034ac..6c5e823 100644
--- a/ivy.xml
+++ b/ivy.xml
@@ -18,7 +18,7 @@
-->
-
+
value="${
-Jaikiran
On 31-May-2017, at 12:14 PM, J Pai wrote:
I had a brief look at this project’s repo and triggered these tasks locally. Of
course, I won’t be able to test the whole upload process, but I was able to see
what’s wrong.
Essentially, the build targets are all fine and they are generating the
I had a brief look at this project’s repo and triggered these tasks locally. Of
course, I won’t be able to test the whole upload process, but I was able to see
what’s wrong.
Essentially, the build targets are all fine and they are generating the
necessary files, including the pom file. It’s jus
+1
-Jaikiran
On 29-May-2017, at 4:59 PM, Nicolas Lalevée wrote:
+1
Nicolas
> Le 29 mai 2017 à 13:15, Jan Matèrne a écrit :
>
> Ivy uses Java7 from Ivy-2.5.x, so let us increase the minimum Java version
> for IvyDE from 1.4 [2] to Java7, too.
>
> According to Eclipse Wiki [2] this will resu
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 meth
hich is the source of truth
> about the resolution report. I have also wondered why the resolve report
> should have to be always wrote and then read from file. I’ll try to get an
> answer myself too while reading the code.
>
> Nicolas
>
>> Le 22 mai 2017 à 07:37, J Pai a
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
run
ttp://ant.1045680.n5.nabble.com/stuck-with-site-generation-issue-for-ivy-td5715758.html>
[2] https://github.com/apache/ant-ivy/tree/xooki2asciidoc
<https://github.com/apache/ant-ivy/tree/xooki2asciidoc>
> Le 25 mai 2017 à 06:12, J Pai a écrit :
>
> What would be the process of ha
Hi Alexander,
Thank you for volunteering to provide this feature patch. I had a look a the
repo you pointed to and read the README. It does seem to contain a good amount
of work in that branch in multiple commits.
To make it easier for whoever will decide about merging these to upstream
ant-i
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
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 resulti
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
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
That specific line in the build.xml[1] of the IvyDE project is trying to “get”
the ivy.jar from a URL. In this case, it’s trying to fetch it from:
> [get] Getting:
> https://builds.apache.org/job/Ivy/lastSuccessfulBuild/artifact/build/artifact/jars/ivy.jar
Since it’s https backed, there’s a SSL
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
One other thing about this issue - this is reproducible (as shown in the test
case) with static revisions too and isn’t specific to any dynamic revision
resolution.
-Jaikiran
On 22-May-2017, at 11:02 AM, J Pai wrote:
I have had a look at that issue, this last week and I have been able to
<https://issues.apache.org/jira/browse/IVY-1485>
It would be a shame if it is not fixed within the next release.
The issue and the fix are not easy to understand. Any review will be welcomed.
Nicolas
> Le 21 mai 2017 à 18:46, Nicolas Lalevée a écrit :
>
>
>> Le 21 mai 2
IvyDE project
itself come to life recently, so I guess we can target to do something similar
in terms of release goals, for that project too.
-Jaikiran
[1] https://issues.apache.org/jira/browse/IVYDE
On 21-May-2017, at 7:58 PM, J Pai wrote:
The past few days I’ve sent some PRs for bug fixes
The past few days I’ve sent some PRs for bug fixes and some enhancements in
preparation for the proposed release of Ivy. Thanks Nicolas for reviewing them
and merging those that were good enough.
I’ve been using this JIRA filter [1] to narrow down on the issues to look into.
That filter essent
-Jaikiran
2017-05-21 7:00 GMT+02:00 J Pai :
> Having been involved in a HttpClient 3 to 4 migration in an unrelated
> project, I think at this point, it’s too big a change to consider. A few
> stable Ivy releases down the line, maybe we can re-evaluate this and
> consider the H
I’ve been going through some of the Ivy code recently and have a few related
questions. Some of my basic testing shows that a “resolve” of a module produces
the following (internal) files:
1. A resolution report, in the form of XML, per configuration of the module, in
the form of --.xml (ex: fo
probably require to propagate a
> timeout value up to the ivy settings, while declaring resolvers. And as you
> pointed, better semantic would need to be defined. Probably two kind of
> timeout should be defined.
>
> Nicolas
>
>> Le 19 mai 2017 à 16:10, J Pai a écrit :
>
Not fully familiar with the voting process and don’t know if IvyDE will require
a voting thread of its own, but either way +1 for Java 7 for IvyDE too.
-Jaikiran
On 19-May-2017, at 12:50 PM, Gintautas Grigelionis
wrote:
Java 7 implements TLS 1.2; Ivy depends a lot more on network communication
should give a decent coverage for the upstream code.
-Jaikiran
On 18-May-2017, at 4:03 PM, Nicolas Lalevée wrote:
I have changed the config of the build so it does a build, then checkstyle,
then findbugs, and then the unit tests.
Nicolas
> Le 18 mai 2017 à 08:21, J Pai a écrit :
>
I was looking at some timing issues in test cases and noticed that the
BasicURLHandler.getURLInfo with a timeout[1] seems to be ignoring that timeout
completely. Am I missing something or is it just a oversight/bug? Furthermore,
the javadoc of URLHandler.getURLInfo doesn’t tell much about what t
One of the reasons, other than the fact that I haven’t personally seen anyone
using Java 5 in development projects or production for many years now, has to
do with the development and testing of the project itself.
It’s hard to find a Java 5 runtime to actually test the product against (almost
+1
-Jaikiran
On 19-May-2017, at 10:55 AM, Jan Matèrne wrote:
As discussed on this mailing list [1] we should increase the minimum Java
version [2] from current (Ivy-2.4.0) Java5 to Java 7 (Ivy-2.5.0).
Decisions whether to increase to Java8 after that release should be make
after that release.
Ac
sense to me.
>
> On 18 May 2017 at 05:58, J Pai wrote:
>
>> +1
>>
>> -Jaikiran
>> On 18-May-2017, at 4:26 PM, Jan Matèrne (jhm) wrote:
>>
>> I would favour 1.7 as it's the newest before the major update to Java8.
>> Having a 1.7 in t
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, Grad
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 lo
esolveTask.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
>
I just submitted a PR https://github.com/apache/ant-ivy/pull/16 which I think
should fix the init-findbug task.
-Jaikiran
On 17-May-2017, at 6:59 PM, Nicolas Lalevée wrote:
The build dedicated to check the style of Ivy is just calling: ant findbugs
checkstyle-internal
https://builds.apache.or
-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
>
>
:) I’m guessing this job isn’t running any tests right now (given
how quickly it finished)?
This is good start to getting this working. Thanks for getting this setup :)
-Jaikiran
On 17-May-2017, at 2:07 PM, J Pai wrote:
Doesn’t look like it got triggered in Jenkins.
-Jaikiran
On 17-May-2017
Doesn’t look like it got triggered in Jenkins.
-Jaikiran
On 17-May-2017, at 1:49 PM, Jan Matèrne (jhm) wrote:
> I read the wiki page https://wiki.apache.org/general/PreCommitBuilds,
> the Kafka issue https://issues.apache.org/jira/browse/KAFKA-1856 and
> had a look at some other PreCommit-jobs.
Thank you very much Nicolas. Having you around for code reviews and even just
watching is definitely going to help a lot.
Thanks for merging that patch too.
-Jaikiran
On 17-May-2017, at 2:09 AM, Nicolas Lalevée wrote:
> Le 16 mai 2017 à 13:11, J Pai a écrit :
>
> Thanks Jan for i
Here’s the instructions https://wiki.apache.org/general/PreCommitBuilds which
Kafka team apparently followed. They tracked this activity in this JIRA
https://issues.apache.org/jira/browse/KAFKA-1856
-Jaikiran
On 16-May-2017, at 6:20 PM, J Pai wrote:
On 16-May-2017, at 6:09 PM, Jan Matèrne
On 16-May-2017, at 6:09 PM, Jan Matèrne (jhm) wrote:
> - From a development point of view, given that there aren’t many who
> are familiar with the codebase, it would really help build some kind of
> confidence level in submitted patches, if the github repo was backed by
> the usual PR proces
Thanks Jan for initiating this.
On the ICLA front - I already have contributed and continue to contribute to
some other Apache projects (these days mostly via github). Do I still have to
sign the ICLA? Is there a way to check if I have already signed this ICLA
previously? I don’t remember if I
Maarten, thanks for volunteering to review the PRs. One of them has a test
case. I will add a test for the other one.
It looks like you have been involved with Ivy development and releases
before, so I think you would be in a better position to decide if it should
be 2.5.0 or 2.4.1. I personally p
On 11 December 2016 at 19:53, J Pai wrote:
>
>> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is
to
>> iron out any issues involved in the process itself which, from what I
read
>> in the other thread, might involve certain challenges for the fi
I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
iron out any issues involved in the process itself which, from what I read
in the other thread, might involve certain challenges for the first time.
-Jaikiran
On Sunday, December 11, 2016, Matt Sicker wrote:
> Do we real
62 matches
Mail list logo
