Re: Next plans for Ivy
Right, that’s true. The more JDKs you require in the build, the harder it is to set up. If you target Java 8 but build at a newer release, you could possibly get away with a single JDK plus an API checker to avoid using new things. On Fri, Nov 1, 2019 at 22:33 Jaikiran Pai wrote: > Hello Matt, > > On 31/10/19 2:34 AM, Matt Sicker wrote: > > Java 9 and beyond can be handled with version specific code in META-INF. > > I think we should be able to do that even now. Of course, _building_ Ivy > would need higher version of Java (to use those specific APIs) but once > built, we can package these higher version classes within the META-INF > structure and that should get picked up if someone uses Ivy in a higher > version of Java and at the same time shouldn't impact Java 8 usage. > > -Jaikiran > -- Matt Sicker
Re: Next plans for Ivy
Java 9 and beyond can be handled with version specific code in META-INF. That’s what we’re doing in Log4j for now. Based on how the new LTS schedule works, it’s better to keep updated with each new release as it comes out due to how deprecated APIs are removed now. Version specific overrides of code can be maintained for a reasonable amount of time, but I guess that really depends on how much version specific code is needed. On Wed, Oct 30, 2019 at 15:46, Gintautas Grigelionis < g.grigelio...@gmail.com> wrote: > It will be good to be on the same page with major dependencies (and > hopefully fix that old nut listTokenValues() :-) > Please consider Java 11 for TLSv1.3 when time comes (or the next LTS > version, Java 17 when it's out -- > by then, pack200 will surely be gone...) > > Gintas > > On Wed, 30 Oct 2019 at 20:26, Jan Matèrne (jhm) wrote: > > > 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 > > > > > -- Matt Sicker
Re: Deleting older releases from svn?
Plus the old releases would still technically be available via the subversion history. On Thu, 5 Sep 2019 at 02:24, Jaikiran Pai wrote: > > > On 05/09/19 12:36 PM, Stefan Bodewig wrote: > > On 2019-09-05, Jaikiran Pai wrote: > > > >> One of the steps that I haven't yet done as a release manager is, > >> deleting the older releases from our svn repo at > >> dist/release/ant[binaries/sources/manual]. The release instructions say > >> that it's as simple as "svn rm". But before doing that I wanted to check > >> if I should be moving those to some "archive" location before the "svn rm"? > > No, just delete them. > > > > archive.apache.org rsyncs releases and is independent of the dist svn > > repo. > > Thank you Stefan. I have cleaned up 1.9.13 and 1.10.5 release artifacts > from the dist svn repo. In a few days, I will remove 1.10.6 artifacts too. > > -Jaikiran > > > ----- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > -- Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Command line argument files
FWIW, picocli is small enough to simply shade into your project. We do it in Log4j with some CLI tooling that’s included. On Sun, Nov 18, 2018 at 09:19, Stefan Bodewig wrote: > Hi Remko > > On 2018-11-15, Remko Popma wrote: > > > Would there be any interest in using picocli ( > > https://github.com/remkop/picocli) as the command line parser in > > `org.apache.tools.ant.Main`? > > Ant's core has zero dependencies and we value this property. > > > 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.) > > I'm pretty sure Picocli is great. > > Personally I wouldn't want to add it just to enable an edge case. Most > people don't have Ant command lines long enough to even make them think > about @-files. -propertyfile helps with the case of many -D options and > then there always is the option to set the ANT_ARGS environment > variable. > > It should be possible to provide a Picocli ArgumentProcessor that people > who need additional features can plug into their builds and activate, > though. > > Cheers > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker
Re: ant git commit: Remove redundancies
Pretty much every implementation of javac will automatically convert the
string concatenation code into StringBuilders. Decompile the byte code and
see for yourself.
On Tue, 21 Aug 2018 at 13:05, Stefan Bodewig wrote:
>
> > diff --git a/src/main/org/apache/tools/ant/types/PatternSet.java
> b/src/main/org/apache/tools/ant/types/PatternSet.java
>
> > -: new
> StringBuilder(baseString).append(";encoding->").append(encoding).toString();
> > +: baseString + ";encoding->" + encoding;
>
> I don't understand what kind of redundancy have you been removing here.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
--
Matt Sicker
Re: Parameterized Tests (was Re: ant git commit: Inline buildfile names, make search easier)
Yes, I'm definitely suggesting/hyping JUnit 5. :) On 3 May 2018 at 12:01, Gintautas Grigelionis <g.grigelio...@gmail.com> wrote: > My focus was on maximising the use of JUnit 4 idioms. > Are you suggesting a switch to JUnit 5 instead? > Sounds like Ant 1.11 :-) > > Gintas > > 2018-05-03 17:12 GMT+02:00 Matt Sicker <boa...@gmail.com>: > > > I've started using JUnit 5 in a personal project and found that it has a > > lot more useful features for test parameters. For instance, they now > > support parameterized test methods instead of just the class itself. > There > > are also more convenient ways of injecting test data through annotations > > and such. Plus, JUnit 5 still supports v3 and v4 tests, so it's not a > mass > > migration effort, either. > > -- > > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
Re: Migrating Ivy and IvyDE site to asciidoc
I haven't looked at that xooki thing, that might work better for all I know. Interesting :) On 23 April 2018 at 10:38, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote: > > > > Le 23 avr. 2018 à 17:23, Matt Sicker <boa...@gmail.com> a écrit : > > > > For what it's worth, I used pandoc <https://pandoc.org> to automate > most of > > the conversion from xdoc and markdown to asciidoc over at Log4j. The only > > struggles I had with that tool are that it supports HTML, not xdoc, so it > > doesn't understand the section/subsection/etc. tags, and it doesn't > output > > the correct syntax for nested tables (need to convert | to ! in a nested > > table). > > Very interesting. > I won’t have time to investigate if it is useful here, since xooki2ascii > is working. But if pandoc can do a better job, I am all ears. > At least next time I’ll probably start with that. > > Nicolas > > > > > On 23 April 2018 at 08:25, Nicolas Lalevée <nicolas.lale...@hibnet.org> > > wrote: > > > >> Hi, > >> > >> I would like to go forward and migrate the part of the site about Ivy > and > >> IvyDE to asciidoc, since it has gone well for the documentation about > Ivy > >> and IvyDE. > >> > >> So first, is OK for everybody ? > >> Reminding of the pros: way faster, more standard source of doc. For the > >> cons: not 'html-hackable’ easily, see below about the home page. > >> > >> For a first base of the discussion, I have give it a shot. I have reused > >> the xooki2asciidoc tool developed for Ivy's documentation. And I have > done > >> a first run, committed the result of the asciidoc files. I think that > since > >> the amount of the pages is reasonable, the quality is fine enough and > can > >> fix the page manually from there. > >> > >> You can see the generated site from the asciidoc files with: ant -f > >> build-doc.xml generate-site > >> The new site is generated in a ‘production2’ folder, so we do not mess > >> with the real site. It is only for testing purpose for now. > >> > >> There are some cleanup to do, I haven't fix any page manually. If > somebody > >> want to start, he is welcome to do so. > >> > >> One page I am worried about is the main page [2]. I am not sure there > are > >> some sane asciidoc directives to render something similar. If you > already > >> have ideas, please share. If I remember correctly there is directive to > >> blindly render content, which could be html, as a fall back. > >> > >> Then, if we’re OK with the change, and if we find something suitable to > >> generate the Home page, we prepare a new version of the site, pushing > >> somewhere so we can review it online. Once happy with the result, we > >> switch. And then we apply the same process with the site for IvyDE. > Sounds > >> good ? > >> > >> Nicolas > >> > >> [1] http://ant.apache.org/ivy/index.html <http://ant.apache.org/ivy/ > >> index.html> > >> > >> > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: Migrating Ivy and IvyDE site to asciidoc
For what it's worth, I used pandoc <https://pandoc.org> to automate most of the conversion from xdoc and markdown to asciidoc over at Log4j. The only struggles I had with that tool are that it supports HTML, not xdoc, so it doesn't understand the section/subsection/etc. tags, and it doesn't output the correct syntax for nested tables (need to convert | to ! in a nested table). On 23 April 2018 at 08:25, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote: > Hi, > > I would like to go forward and migrate the part of the site about Ivy and > IvyDE to asciidoc, since it has gone well for the documentation about Ivy > and IvyDE. > > So first, is OK for everybody ? > Reminding of the pros: way faster, more standard source of doc. For the > cons: not 'html-hackable’ easily, see below about the home page. > > For a first base of the discussion, I have give it a shot. I have reused > the xooki2asciidoc tool developed for Ivy's documentation. And I have done > a first run, committed the result of the asciidoc files. I think that since > the amount of the pages is reasonable, the quality is fine enough and can > fix the page manually from there. > > You can see the generated site from the asciidoc files with: ant -f > build-doc.xml generate-site > The new site is generated in a ‘production2’ folder, so we do not mess > with the real site. It is only for testing purpose for now. > > There are some cleanup to do, I haven't fix any page manually. If somebody > want to start, he is welcome to do so. > > One page I am worried about is the main page [2]. I am not sure there are > some sane asciidoc directives to render something similar. If you already > have ideas, please share. If I remember correctly there is directive to > blindly render content, which could be html, as a fall back. > > Then, if we’re OK with the change, and if we find something suitable to > generate the Home page, we prepare a new version of the site, pushing > somewhere so we can review it online. Once happy with the result, we > switch. And then we apply the same process with the site for IvyDE. Sounds > good ? > > Nicolas > > [1] http://ant.apache.org/ivy/index.html <http://ant.apache.org/ivy/ > index.html> > > -- Matt Sicker <boa...@gmail.com>
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>
Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability
After 2.8.2, there's a class whitelist used for deserializing data in the receiver. On 7 February 2018 at 12:19, Gintautas Grigelionis <g.grigelio...@gmail.com> wrote: > Sorry, could you please clarify whether there different aspects pertaining > to 1.x and 2.x up to and after 2.8.2? > > Thanks, Gintas > > 2018-02-07 19:10 GMT+01:00 Matt Sicker <boa...@gmail.com>: > > > Based on that version, this is related to using Java serialization for > > logs. The general workaround here is to use a different format like JSON > > instead to avoid the vulnerability entirely. > > > > On 7 February 2018 at 12:03, Gintautas Grigelionis < > > g.grigelio...@gmail.com> > > wrote: > > > > > Exactly, what I meant is that it's worth pointing out that not even all > > > versions of log4j 2.x are safe. > > > > > > Gintas > > > > > > 2018-02-07 18:18 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > > > > > > > On 2018-02-07, Gintautas Grigelionis wrote: > > > > > > > > > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not > > > only > > > > > Log4j 1.x issue. Did I miss something? > > > > > > > > The subject is how it has been reported to us. > > > > > > > > Prior to the latest releases you have not been able to use log4j2 so > > > > there is no reason to talk about those versions. The recommended > > > > mitigation of "don't use Log4JListener or use the log4j2-bridge" is > > > > correct, one might add "of a log4j 2.x version that is not vulnerable > > to > > > > the attack". > > > > > > > > Stefan > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > > > > > > > > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
Re: [SECURITY] CVE-2017-5645: Apache Ant 1.9.9 and 1.10.1 - Apache Log4j 1.2.13 security vulnerability
Based on that version, this is related to using Java serialization for logs. The general workaround here is to use a different format like JSON instead to avoid the vulnerability entirely. On 7 February 2018 at 12:03, Gintautas Grigelionis <g.grigelio...@gmail.com> wrote: > Exactly, what I meant is that it's worth pointing out that not even all > versions of log4j 2.x are safe. > > Gintas > > 2018-02-07 18:18 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > > > On 2018-02-07, Gintautas Grigelionis wrote: > > > > > The CVE says it affects SocketServer up to Log4j 2.8.2, so it's not > only > > > Log4j 1.x issue. Did I miss something? > > > > The subject is how it has been reported to us. > > > > Prior to the latest releases you have not been able to use log4j2 so > > there is no reason to talk about those versions. The recommended > > mitigation of "don't use Log4JListener or use the log4j2-bridge" is > > correct, one might add "of a log4j 2.x version that is not vulnerable to > > the attack". > > > > Stefan > > > > ----- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > > -- Matt Sicker <boa...@gmail.com>
Re: (IVY-1502) Be a nice freedesktop citizen, move the ~/.ivy to the appropriate location
On 31 October 2017 at 04:06, Jan Matèrne (jhm) <apa...@materne.de> wrote: > Has someone heard from that XDG-specification before? > You mean the ~/.local directory and XDG_* environment variables? Yeah, I've used them before, but tons of applications still spam the home directory with config files, so it's only a partial solution. > Are there other "usually used directories" for other platforms than > FreeDesktop? > On macOS, there's ~/Library which would be the appropriate place for dumping config, caches, etc. -- Matt Sicker <boa...@gmail.com>
Re: Process for handling GitHub PRs and closing them
What I've done on other Apache projects is essentially "git pull github/pull/N/head", merging directly into master (this is after it's ready to merge of course). After pushing that, GitHub will see that the branch is merged and auto-closes the PR. If you rewrite history as with the rebase example, GitHub (and git in general) doesn't notice that it's merged, so it doesn't auto-close. If you really want to rebase, there's no way around adding an additional commit to add the magic "closes #N" message. On 19 June 2017 at 09:48, Jaikiran Pai <jai.forums2...@gmail.com> wrote: > > On 19-Jun-2017, at 2:43 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> > wrote: > > > > >> Le 19 juin 2017 à 05:14, Jaikiran Pai <jai.forums2...@gmail.com> a > écrit : > >> > >> We have (read only) github repos which back our main ASF git repos > (consider the github ant-ivy repo which is a read-only mirror of ASF git > repo). Users submit pull requests to our github repos and the process I > follow for merging such PRs is the “rebase” approach which looks something > like this: > >> > >> > >> - Fetch the PR locally (git fetch github pull/45/head:pr-45) > >> - Checkout to that branch locally (git checkout pr-45) > >> - Rebase that PR on top of latest ASF (upstream) repo (git rebase > asf/master) > >> - Run a short build, verify and push to ASF repo (git push asf > pr-45:master) > >> > >> (assume 45 is the pull request id). > >> > >> So essentially, I rebase the commits from the PR on top of the latest > master and then push to the ASF repos. All this works fine and the ASF > repos get those changes. However, this doesn’t “close” the pull request on > github. > >> > >> Apparently, the way to have the pull request closed is doing a actual > “merge” of the pull request commits into the ASF repo instead of rebasing > the commits. > >> > >> Then the other approach, which isn’t that clean IMO, is to push a > commit to the ASF repo with a commit message which includes “This closes > #X” where X is the pull request id. The ASF github bot then notices this > commit messages and goes and closes the open PR. > >> > >> I usually prefer the rebase approach (the one I outlined above) for > dealing with pull requests, since it gives a clean git commit tree. But > clearly that doesn’t have a way to close the PR. > >> > >> Is there any preferred approach that we should follow with PRs? > > > > I agree with the approach you have. I have been lazy though, I just use > the command line suggested in the email notifications, which makes things > quite straight forward. > > > > I would just insist on trying to get the PR closed. Even if it may > pollute the commit log, we should put the "This closes #X" message. And it > can be viewed as a marker, just like we do with Jira. Also, we could make > thing more explicit by specifying the full path of the github project: « > closes apache/ant-ivy#123 ». > > See the github documentation about it: https://help.github.com/ > articles/closing-issues-via-commit-messages/ <https://help.github.com/ > articles/closing-issues-via-commit-messages/> > > > > > I wasn’t aware that this kind of commit message comes from and is > supported by github itself. I was under the impression that this is > something that the ASF github integration had introduced. Thanks for that > link. > > What you suggest about making sure that the PR gets closed even if we end > up with those mark commit messages, sounds fine to me and I’ll start doing > that. > > -Jaikiran > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: new committer: Jaikiran Pai
Welcome! On 16 June 2017 at 10:51, Jan Matèrne (jhm) <apa...@materne.de> wrote: > 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 > > -- Matt Sicker <boa...@gmail.com>
Re: [VOTE] Release Compress Antlib 1.5 based on RC3
I generally import each project's KEYS file, and having been to a key signing party before at ApacheCon, I have a small web of trust to help verify those signatures. The more people sign each other's keys, the easier it is to verify. On 14 June 2017 at 02:59, Jan Matèrne (jhm) <apa...@materne.de> wrote: > 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 > > -- Matt Sicker <boa...@gmail.com>
Re: Replace emma with jacoco?
rge.net > EMMA can instrument classes for coverage either offline (before they are > loaded) or on the fly (using an instrumenting application classloader). > > > > > 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<https:// > sourceforge.net/p/emma/feature-requests/> > 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 ... > > > > > > > EMMA code coverage / Feature Requests - sourceforge.net<https:// > > sourceforge.net/p/emma/feature-requests/> > > 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 <g.grigelio...@gmail.com> > > 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 > > > -- Matt Sicker <boa...@gmail.com>
Re: PR-33: problems
Removing a checked exception can affect source compatibility, for example,
if that particular exception is caught in a try block and nothing else in
the try block can throw the exception. Or at least that's how I remember it
I think.
On 29 May 2017 at 06:05, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote:
>
> > Le 29 mai 2017 à 11:46, Jan Matèrne (jhm) <apa...@materne.de> a écrit :
> >
> > Sounds like I would do ;)
> > I'll merge the PR locally and insert the delegates.
> >
> > Open is
> > "src/java/org/apache/ivy/osgi/util/Version.java:
> > the constructor removes the (IMO unneccessary) ParseException.
> > But because it is a checked Exception we break BC."
> >
> > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 defines the removal
> of a checked exception:
> > "Breaks compatibility"
> > "Adding and deleting checked exceptions declared as thrown by an API
> method
> > does not break binary compatibility; however,
> > it breaks contract compatibility (and source code compatibility)."
> >
> > What do we want?
>
> Thanks for the link, I’ll bookmark it.
>
> Then I am OK with that. The Ivy jar can still be a upgraded without
> worries, and if somebody compile against it, then he has the source so he
> can modify them.
>
> I am OK with that also because having stricter compatibility rules will be
> painful considering the wide API Ivy is exposing.
>
> Nicolas
>
> >
> >
> >
> > Jan
> >
> >> -Ursprüngliche Nachricht-
> >> Von: J Pai [mailto:jai.forums2...@gmail.com]
> >> Gesendet: Montag, 29. Mai 2017 10:26
> >> An: Ant Developers List
> >> Betreff: Re: PR-33: problems
> >>
> >> IMO, for each of these public classes/methods/fields that we are fixing
> >> for typos, we should mark them @Deprecated (and add a @deprecated
> >> javadoc too and point to the new field/method/class) and introduce the
> >> rightly named class/method/field. For methods it’s straightforward, the
> >> deprecated method internally calls the new method. For fields too it’s
> >> straightforward. The deprecated field uses the value of the new field.
> >> For classes, I think we can copy over the existing class into the new
> >> one and leave around the existing one just for possible external
> >> references (that we can’t control off) and migrate all internal
> >> references to the new one.
> >>
> >> At some point, in some future version of Ivy, we remove/delete these
> >> deprecated method/field/class.
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >> On 29-May-2017, at 1:43 PM, Jan Matèrne <j...@materne.de> wrote:
> >>
> >> I did a review of <https://github.com/apache/ant-ivy/pull/33>
> >> https://github.com/apache/ant-ivy/pull/33
> >>
> >> Here are the points I have problems with, so I want to discuss them
> >> here.
> >>
> >> Basically it's about breaking BC. So how to deal with that?
> >>
> >>
> >>
> >>
> >>
> >> Jan
> >>
> >>
> >>
> >>
> >>
> >> Fixing the spell error in DelegateHandler$ChildElementHandler
> >> (s/childHanlded/childHandled/) means breaking beakward compatiblity.
> >>
> >> We could introduce a delegetate for that:
> >>
> >> /** for BC */
> >>
> >> @Deprecated
> >>
> >> public void childHanlded(DH child) throws SAXParseException {
> >>
> >> childHandled(DH child);
> >>
> >> }
> >>
> >> While refactoring you have renamed all occurences in the Ivy codebase.
> >>
> >> On the other hand I don't know the impact (maybe outside of Ivy). I'll
> >> bring that to the dev-list.
> >>
> >>
> >>
> >>
> >>
> >> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming the
> >> public constant DEFAULT_BUNLDE_FILTER also means breaking BC.
> >>
> >>
> >>
> >>
> >>
> >> src/java/org/apache/ivy/osgi/util/Version.java: the constructor removes
> >> the (IMO unneccessary) ParseException. But because it is a checked
> >> Exception we break BC.
> >>
> >>
> >>
> >>
> >>
> >> renaming EncrytedProperties to EncryptedProperties means breaking BC.
> >> If required we could introduce a delegating class or a subclass.
> >>
> >>
> >>
> >>
> >>
> >> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If
> >> required we could introduce a delegating method.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> >> commands, e-mail: dev-h...@ant.apache.org
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
--
Matt Sicker <boa...@gmail.com>
Re: Ivy website - fixing a Quickstart documentation live
Can't you run the original Ruby asciidoc parser via JRuby, too? On 26 May 2017 at 02:06, J Pai <jai.forums2...@gmail.com> wrote: > So I got this site generation working locally (had to fix a xooki script > to make it work with Nashorn. The attached patch includes the fix). > > At this point, I need help to commit the newly generated doc fixes to the > SVN. I’ve attached a patch file for it and will explain what it is doing. > > The changes/patch relates to _one_ of the more important issues noted in > the JIRA https://issues.apache.org/jira/browse/IVY-1542. That JIRA lists > more than one issue with the latest docs. However, the missing .png and > .css don’t directly contribute to anything noticeable, so I haven’t > included it in this patch (and probably will look into it separately). The > issue that this patch fixes is the more important one: > > > Code examples are missing. About 2/3 of the way down the page are two > code examples that are rendering as just a black rectangle for me. The > underlying html looks like it has tags with no content. > > > The way these tutorial docs are generated, during the build, it triggers > the build of quickstart examples and dumps the logs into files. The log > files are then referred to via xooki references and the contents of those > log files are inlined within the div tags. So I went ahead and built these > tutorials on 2.4.0 tag of Ivy project, generated those logs and then > regenerated the site with these logs in the relevant folder. The generated > documentation now has these output inlined correctly in the quickstart and > various other docs. > > The attached patch was generated with https://svn.apache.org/repos/ > asf/ant/site/ as the root of the SVN checkout. So whoever is applying the > patch will have to cd to that directory and then apply it. Let me know if > you run into issues or if any changes are necessary in this patch. > > As for the other two issues noted in that JIRA, I’m planning to remove > references to the non-existent .css and .png files and submit that as a > separate patch. > > -Jaikiran > > > > > > > > On 26-May-2017, at 10:39 AM, J Pai <jai.forums2...@gmail.com> wrote: > > Thanks everyone for the inputs. > > I’m trying to get a proper build going locally for the site generation > (and running into issues). Once I get a proper build and the fixes to the > issues noted in that JIRA, I’ll send out an update. Hopefully soon. > > -Jaikiran > On 25-May-2017, at 5:26 PM, Nicolas Lalevée <nicolas.lale...@hibnet.org> > wrote: > > The entire Ant site is in svn: > https://svn.apache.org/repos/asf/ant/site > > There is a Readme.txt explaining a little bit stuff, but seems outdated > since the migration to git. For Ivy and IvyDE, part of the site is built > from the source for the projects. It used to be managed via svn:externals. > Now there are ant tasks to run to the fetch of the sources. I have found an > old discussion [1] we had about it which should help you. > > By the way, the Ivy documentation is managed by an hand crafted html > editor, xooki, just is good but quite slow. I did some work 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 <http://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 <jai.forums2...@gmail.com> 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 > -- Matt Sicker <boa...@gmail.com>
Re: Ivy documentation with asciidoc
Merge commits always spam the commits list which, while annoying, I've learned to mass-delete whenever it happens. ;) I looked at some random changes and found a couple markup typos, but otherwise it looks like it converted well enough. I'm more familiar with the maven plugins for site management, so I'm not sure about the integration aspects, but worst case scenario, can't you just commit the parts to svnpubsub on release? On 25 May 2017 at 09:00, Nicolas Lalevée <nicolas.lale...@hibnet.org> wrote: > I have updated the branch xooki2asciidoc. The merge generated 50 emails, > which I still find weird, I would expect just one mail about the commit of > the merge. > > I can see the current status of the transformation of the xooki source > into asciidoc source and then the generated html from that here: > http://hibnet.org/tmp/ivy-asciidoc/index.html <http://hibnet.org/tmp/ivy- > asciidoc/index.html> > > It seems pretty good, but I didn’t looked to most of the pages. > > Before going further, we need to figure out how it would be integrated to > the website since it is also managed by xooki. The site and the > documentation are tidily coupled by the toc which is managed by xooki. > > Nicolas > > -- Matt Sicker <boa...@gmail.com>
Re: [VOTE] Increase minimum Java version for Ivy to Java7
Isn't HTTP 2.0 only in Java 9? Otherwise you need a 3rd party library that implements the protocol support. On 22 May 2017 at 02:00, Jan Matèrne (jhm) <apa...@materne.de> wrote: > > Should we start talking about using HTTP/2? Then we're firmly in Java 8 > > territory :-) > > While having HTTP/2 support would be a cool thing, I think we should make > small steps, and one after the other. > So increase minimum Java version from 1.5 to 1.7, apply some changes, make > a release. > Then we could think about moving to Java8, maybe preparing for Java9 ... > > 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>
Re: Minimum Java runtime version for proposed upcoming Ivy release
Using 1.7 for the next release and then 1.8 for the following release makes sense to me. On 18 May 2017 at 05:58, J Pai <jai.forums2...@gmail.com> wrote: > +1 > > -Jaikiran > On 18-May-2017, at 4:26 PM, Jan Matèrne (jhm) <apa...@materne.de> wrote: > > 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 > > <nicolas.lale...@hibnet.org > >> 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 <jai.forums2...@gmail.com> 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: Ivy+IvyDE: help wanted
Backporting changes from the various forks would be a great idea. On 16 May 2017 at 11:31, Gintautas Grigelionis <g.grigelio...@gmail.com> wrote: > Ivy is also a part of Groovy, through Grapes. There are quite a few forks > of Ivy on GitHub, perhaps it is worth the while to solicit PRs? > > Meanwhile, I was asking for help/opinions about > https://issues.apache.org/jira/browse/IVY-1478 (updatesite resolver) which > would in turn help setting up builds for IvyDE (because Eclipse folks no > longer provide drops and OSGi resolver provided by Eclipse launcher is > cumbersome). > -- Matt Sicker <boa...@gmail.com>
Re: Ivy+IvyDE: help wanted
The very interesting thing about Ivy, in my opinion, is that while it isn't developed on that much currently, it's still the basis of SBT, Gradle, and probably other build tools that are a bit more popular. I'm curious how all those projects continue to use Ivy while its development seems somewhat stalled here. On 16 May 2017 at 07:53, J Pai <jai.forums2...@gmail.com> wrote: > 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 <jai.forums2...@gmail.com> wrote: > > > On 16-May-2017, at 6:09 PM, Jan Matèrne (jhm) <apa...@materne.de> 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 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? > > > Apache Kafka are doing this for their github mirror > https://github.com/apache/kafka/pulls. They had a discussion about this > in their mailing list on how to setup. I’ll try and find if there’s some > detailed instructions for Apache projects to follow this model. > > -Jaikiran > > > ----- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: Ivy - Proposal for reviving the project and moving towards a release
I'd definitely agree with the consistency principle. On 15 December 2016 at 01:38, Stefan Bodewig <bode...@apache.org> wrote: > On 2016-12-14, Matt Sicker wrote: > > > When it comes to version numbers, I'm more concerned about following > > semantic versioning than whether or not it's a major release. Bugfixes > > warrant micro version updates, while new features warrant minor version > > updates (and backward incompatible API changes are for the major > version). > > I'm not sure how Ivy has decided on its version numbers in the past, but > for Ant we've never followed semantic versioning that strictly. In > particular we've created lots of micro releases that contained new > features and most of the time created minor versions when we changed JDK > requirements. In a sense we've shifted semantic versioning to the right > and never created major releases (and neither pure bugfix releases), > maybe because Ant2 could bring up some ghosts of the far past. :-) > > As much as I like semantic versioning (and use it in other projects), > I'd prefer to stay consistent with the way versions have been used in > prior releases. > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: Ivy - Proposal for reviving the project and moving towards a release
t; > filters or even assign some to myself to track them better. So I think > > for now, we can rely on that JIRA search query [1]. > > > > At this point, I think, if we can target March 2017 for releasing a > > 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a > > good start. Some of the issues noted in that JIRA are indeed important > > ones and would need some review/help in fixing them correctly, which > > essentially means, we need at least one person who has had experience > > with the Ivy code and its design details and also has the committer > rights. > > > > > > Does any of this look feasible? Let me know if this isn't enough to > > move things forward - I don't want to end up sending PRs and spending > > time on this if there's no way we can get to a proper release in the > > next few months. > > > > > > [1] > > > https://issues.apache.org/jira/browse/IVY-1553?jql= > project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20% > 22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1. > 0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND% > 20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC > > > > [2] https://github.com/apache/ant-ivy/pull/11 > > > > [3] https://github.com/apache/ant-ivy/pull/12 > > > > -Jaikiran > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > > commands, e-mail: dev-h...@ant.apache.org > > > > > > > > > - > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- Matt Sicker <boa...@gmail.com>
Re: Ivy - Proposal for reviving the project and moving towards a release
Issues in the release process? Those would be handled by multiple release candidates. People normally only use alphas and betas for new projects or new major versions of projects at Apache. On 11 December 2016 at 19:53, J Pai <jai.forums2...@gmail.com> 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 first time. > > -Jaikiran > > On Sunday, December 11, 2016, Matt Sicker <boa...@gmail.com> wrote: > > Do we really need a beta release? If you're working on bugfixes first, > then > > a regular 2.4.1 release would be great. It would go through the normal > > Apache release candidate process, and perhaps we could get some Gradle > > developers to test it out as well since they still seem to be big users > of > > Ivy. > > > > Any committer to the Ant project could prepare the release and be a > release > > manager. The only requirements involving PMCs is to vote on approving the > > release; adding your GPG key to the KEYS file (only PMCs can commit to > that > > repository involved); and committing the artifacts to the release svn > > repository (again, PMCs). I'm also not a committer, but if you're > > interested enough in maintaining Ivy, I'd guess that the PMCs may wish to > > bring you on board to do so. > > > > > > On 11 December 2016 at 08:22, Jaikiran Pai <jai.forums2...@gmail.com> > wrote: > > > >> First off, I'm not an Ivy or Ant committer. The proposal that I make > below > >> for an Ivy release is based on what was discussed in a recent mail > thread > >> about the future of Ivy https://www.mail-archive.com/d > >> e...@ant.apache.org/msg45078.html. There was a suggestion that someone > from > >> community volunteer to try and bring in some activity into the project > and > >> see if we can create a release after triaging the JIRA issues. > >> > >> > >> I have had a look at the open issues in JIRA today and decided to filter > >> out issues that are open, updated since Jan 2014 and affects versions > 2.1, > >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just > select > >> a few that I thought can be considered "active". This [1] returns 57 > >> issues. I went ahead and looked at those issues today and have asked for > >> more information in the JIRAs wherever relevant and have sent a couple > of > >> pull requests [2] [3] to fix some straightforward ones. I also have > another > >> PR that I opened this week to fix one other issue. Out of those 57 > issues, > >> many are no longer relevant or don't have enough details. I don't have > JIRA > >> privileges to label them, share filters or even assign some to myself to > >> track them better. So I think for now, we can rely on that JIRA search > >> query [1]. > >> > >> At this point, I think, if we can target March 2017 for releasing a > >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a > good > >> start. Some of the issues noted in that JIRA are indeed important ones > and > >> would need some review/help in fixing them correctly, which essentially > >> means, we need at least one person who has had experience with the Ivy > code > >> and its design details and also has the committer rights. > >> > >> > >> Does any of this look feasible? Let me know if this isn't enough to move > >> things forward - I don't want to end up sending PRs and spending time on > >> this if there's no way we can get to a proper release in the next few > >> months. > >> > >> > >> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project% > >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In% > >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in% > >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)% > >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC > >> > >> [2] https://github.com/apache/ant-ivy/pull/11 > >> > >> [3] https://github.com/apache/ant-ivy/pull/12 > >> > >> -Jaikiran > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > >> For additional commands, e-mail: dev-h...@ant.apache.org > >> > >> > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
Re: Ivy - Proposal for reviving the project and moving towards a release
Do we really need a beta release? If you're working on bugfixes first, then a regular 2.4.1 release would be great. It would go through the normal Apache release candidate process, and perhaps we could get some Gradle developers to test it out as well since they still seem to be big users of Ivy. Any committer to the Ant project could prepare the release and be a release manager. The only requirements involving PMCs is to vote on approving the release; adding your GPG key to the KEYS file (only PMCs can commit to that repository involved); and committing the artifacts to the release svn repository (again, PMCs). I'm also not a committer, but if you're interested enough in maintaining Ivy, I'd guess that the PMCs may wish to bring you on board to do so. On 11 December 2016 at 08:22, Jaikiran Pai <jai.forums2...@gmail.com> wrote: > First off, I'm not an Ivy or Ant committer. The proposal that I make below > for an Ivy release is based on what was discussed in a recent mail thread > about the future of Ivy https://www.mail-archive.com/d > e...@ant.apache.org/msg45078.html. There was a suggestion that someone from > community volunteer to try and bring in some activity into the project and > see if we can create a release after triaging the JIRA issues. > > > I have had a look at the open issues in JIRA today and decided to filter > out issues that are open, updated since Jan 2014 and affects versions 2.1, > 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just select > a few that I thought can be considered "active". This [1] returns 57 > issues. I went ahead and looked at those issues today and have asked for > more information in the JIRAs wherever relevant and have sent a couple of > pull requests [2] [3] to fix some straightforward ones. I also have another > PR that I opened this week to fix one other issue. Out of those 57 issues, > many are no longer relevant or don't have enough details. I don't have JIRA > privileges to label them, share filters or even assign some to myself to > track them better. So I think for now, we can rely on that JIRA search > query [1]. > > At this point, I think, if we can target March 2017 for releasing a > 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a good > start. Some of the issues noted in that JIRA are indeed important ones and > would need some review/help in fixing them correctly, which essentially > means, we need at least one person who has had experience with the Ivy code > and its design details and also has the committer rights. > > > Does any of this look feasible? Let me know if this isn't enough to move > things forward - I don't want to end up sending PRs and spending time on > this if there's no way we can get to a proper release in the next few > months. > > > [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project% > 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In% > 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in% > 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)% > 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC > > [2] https://github.com/apache/ant-ivy/pull/11 > > [3] https://github.com/apache/ant-ivy/pull/12 > > -Jaikiran > > ----- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Matt Sicker <boa...@gmail.com>
Re: Ivy - any future or is it also going to be retired?
core developers of Ivy in > a short timeframe. > So every development/planning stoped. (Just my personal point of view.) > Now we are trying to reactivate 'old', aquire 'new' committers and getting > 'existing' > (Ant)commmiters be more familiar with the Ivy codebase, so that we could > do more here. > (Also my personal point of view.) > > > > Jan > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org > > - > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- Matt Sicker <boa...@gmail.com>
Re: [VOTE] GitHub integration
Apache Commons is one of those projects that looks feature-complete and bug-free. It's one of those things people use but don't even think about. :) On 8 June 2014 14:05, Jan Matèrne (jhm) apa...@materne.de wrote: From my experience with log4net and commons, pull requests are pertty rare, BTW. At Camel PRs come in very often ... 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
Re: migration to git : next steps
I'm going to have to look into subtree as I've been using submodule at work lately and it's becoming a huge mess. On 20 May 2014 13:39, Charles Duffy char...@dyfis.net wrote: I'd suggest looking into git-subtree as well, if we wanted to maintain a single-development-tree experience. Submodules have a reputation (well-deserved, IMHO) of being somewhat unwieldy to work with; using git-subtree to manage linked trees can be a bit more automation/setup work, but can also provide a much smoother user experience. On Mon, May 12, 2014 at 8:03 PM, Matt Sicker boa...@gmail.com wrote: Something I've been experimenting with is using git submodules. You basically have a repository for each submodule, then you can have another repository that groups them all together for convenience. It's handy for making a sort of stable master that points to the latest tag or something similar. It's kind of confusing, but I think it works well for when people want to check out a project corresponding to the latest stable rather than the trunk (which would normally be stable anyway). On 12 May 2014 21:19, Antoine Levy Lambert anto...@gmx.de wrote: Hi, resending a message which I sent on May 7th but might have been lost completely due to our infrastructure problems last week : To actually migrate to git, we could either make one INFRA JIRA for all the ant family of projects, or do this one step at a time. Concerning the antlibs, I suppose we want one git module for each antlib - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a common folder which ought to be on its own. If we do it one step at a time we could start with ant proper, then move to ivy, ivyde, easyant and the antlibs. What do you think ? Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com
Re: migration to git : next steps
On Tuesday, 13 May 2014, Antoine Levy Lambert anto...@gmx.de wrote: Hello Matt, this is interesting - thanks for pointing this out since I am a newbie in git land. does one need to do some advance planning to make a module become a submodule of another repository aggregating the submodules ? Nope! You use it somewhat like svn:external, but you manually keep the commit ID in sync to whatever you want. I find it useful to use a tag for that commit. Otherwise you end up with a history like update submodule over and over again. there would be a use case for an aggregation of the complete ant family, maybe for an aggregation of the antlibs too … If there's a master build.xml or similar that can just iterate through all the projects and build them in order, that's a neat use case. -- Matt Sicker boa...@gmail.com
Re: migration to git : next steps
Something I've been experimenting with is using git submodules. You basically have a repository for each submodule, then you can have another repository that groups them all together for convenience. It's handy for making a sort of stable master that points to the latest tag or something similar. It's kind of confusing, but I think it works well for when people want to check out a project corresponding to the latest stable rather than the trunk (which would normally be stable anyway). On 12 May 2014 21:19, Antoine Levy Lambert anto...@gmx.de wrote: Hi, resending a message which I sent on May 7th but might have been lost completely due to our infrastructure problems last week : To actually migrate to git, we could either make one INFRA JIRA for all the ant family of projects, or do this one step at a time. Concerning the antlibs, I suppose we want one git module for each antlib - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a common folder which ought to be on its own. If we do it one step at a time we could start with ant proper, then move to ivy, ivyde, easyant and the antlibs. What do you think ? Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
I think it would work better to just do development on ASF, but accept pull requests via GitHub somewhat manually. This is how it's done with Apache Camel: http://camel.apache.org/contributing.html So it's done manually. Plus, nobody can write to the ASF GitHub repos without pulling some strings in INFRA to do something about it, and I don't think they like that idea anyhow due to the bylaws regarding what was already said above. On 7 May 2014 01:28, Jan Matèrne (jhm) apa...@materne.de wrote: As a ASF project we MUST have a repo in Apache land: http://www.apache.org/dev/writable-git ASF releases must be cut from the canonical ASF Git repositories. The absolute minimum is therefore: - working on somewhere else - starting a release: -- pull all changes to local -- push to ASF-repo -- create a branch/tag in the ASF repo for the release -- do the release But personally I prefer having one right repo in the ASF I could trust. Additional repos somewhere else (like on Github) could just help. (If working with Git - would Gerrit a good candidate?) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Mittwoch, 7. Mai 2014 02:18 An: Ant Developers List Betreff: Re: Hoped for advantages of migrating to git Matt, Jesse, I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work, including more command line work, in the case of a migration to git-wip- us.apache.org as opposed to migrating to use only github. I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ? Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial. While github today is a very attractive platform, it could one day diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence. There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txt which links the apache user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors of Apache projects ? Also, while researching this I found an interesting presentation by Jukka Zitting [1] and a mail message concerning Apache and Github [2] and also a wiki page from the Apache Cordova project [3] Best regards, Antoine [1] http://www.slideshare.net/jukka/apache-development-with-github-and- travis-ci [2] http://mail-archives.apache.org/mod_mbox/lucene- dev/201401.mbox/%3c596fff55-6e33-4451-93d4-75add6cad...@gmail.com%3E [3] http://wiki.apache.org/cordova/GitWorkflow On May 6, 2014, at 6:33 PM, Matt Sicker boa...@gmail.com wrote: I mean how do you accept pull requests? You wouldn't be able to do it through GitHub. You'd have to manually pull the branch from GitHub like the name pull request implies. If you could commit to GitHub, then you could add a remote besides origin for GitHub, then pull from the GitHub remote, then push to the ASF remote (origin). On 6 May 2014 01:45, Stefan Bodewig bode...@apache.org wrote: On 2014-05-06, Matt Sicker wrote: Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. You don't, you commit to the ASF repo and it gets mirrored. IIRC some projects have their own forks of the ASF mirror and accept pull request on this fork. They then merge changes from their fork to the ASF repo. I'm not conviced I'd want to work that way, applying PRs without the Web-UI on a local checkout of the ASF git repo works fine for me. Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
You can merge this pull request into a Git repository by running: $ git pull https://github.com/user/repo branchname Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant/1234.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 #1234 On 11 May 2014 15:05, Matt Sicker boa...@gmail.com wrote: And here's some more info about how to do that. On 11 May 2014 15:04, Matt Sicker boa...@gmail.com wrote: I think it would work better to just do development on ASF, but accept pull requests via GitHub somewhat manually. This is how it's done with Apache Camel: http://camel.apache.org/contributing.html So it's done manually. Plus, nobody can write to the ASF GitHub repos without pulling some strings in INFRA to do something about it, and I don't think they like that idea anyhow due to the bylaws regarding what was already said above. On 7 May 2014 01:28, Jan Matèrne (jhm) apa...@materne.de wrote: As a ASF project we MUST have a repo in Apache land: http://www.apache.org/dev/writable-git ASF releases must be cut from the canonical ASF Git repositories. The absolute minimum is therefore: - working on somewhere else - starting a release: -- pull all changes to local -- push to ASF-repo -- create a branch/tag in the ASF repo for the release -- do the release But personally I prefer having one right repo in the ASF I could trust. Additional repos somewhere else (like on Github) could just help. (If working with Git - would Gerrit a good candidate?) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Mittwoch, 7. Mai 2014 02:18 An: Ant Developers List Betreff: Re: Hoped for advantages of migrating to git Matt, Jesse, I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work, including more command line work, in the case of a migration to git-wip- us.apache.org as opposed to migrating to use only github. I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ? Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial. While github today is a very attractive platform, it could one day diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence. There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txt which links the apache user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors of Apache projects ? Also, while researching this I found an interesting presentation by Jukka Zitting [1] and a mail message concerning Apache and Github [2] and also a wiki page from the Apache Cordova project [3] Best regards, Antoine [1] http://www.slideshare.net/jukka/apache-development-with-github-and- travis-ci [2] http://mail-archives.apache.org/mod_mbox/lucene- dev/201401.mbox/%3c596fff55-6e33-4451-93d4-75add6cad...@gmail.com%3E [3] http://wiki.apache.org/cordova/GitWorkflow On May 6, 2014, at 6:33 PM, Matt Sicker boa...@gmail.com wrote: I mean how do you accept pull requests? You wouldn't be able to do it through GitHub. You'd have to manually pull the branch from GitHub like the name pull request implies. If you could commit to GitHub, then you could add a remote besides origin for GitHub, then pull from the GitHub remote, then push to the ASF remote (origin). On 6 May 2014 01:45, Stefan Bodewig bode...@apache.org wrote: On 2014-05-06, Matt Sicker wrote: Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. You don't, you commit to the ASF repo and it gets mirrored. IIRC some projects have their own forks of the ASF mirror and accept pull request on this fork. They then merge changes from their fork to the ASF repo. I'm not conviced I'd want to work that way, applying PRs without the Web-UI on a local checkout of the ASF git repo works fine for me. Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr
Re: Hoped for advantages of migrating to git
And here's some more info about how to do that. On 11 May 2014 15:04, Matt Sicker boa...@gmail.com wrote: I think it would work better to just do development on ASF, but accept pull requests via GitHub somewhat manually. This is how it's done with Apache Camel: http://camel.apache.org/contributing.html So it's done manually. Plus, nobody can write to the ASF GitHub repos without pulling some strings in INFRA to do something about it, and I don't think they like that idea anyhow due to the bylaws regarding what was already said above. On 7 May 2014 01:28, Jan Matèrne (jhm) apa...@materne.de wrote: As a ASF project we MUST have a repo in Apache land: http://www.apache.org/dev/writable-git ASF releases must be cut from the canonical ASF Git repositories. The absolute minimum is therefore: - working on somewhere else - starting a release: -- pull all changes to local -- push to ASF-repo -- create a branch/tag in the ASF repo for the release -- do the release But personally I prefer having one right repo in the ASF I could trust. Additional repos somewhere else (like on Github) could just help. (If working with Git - would Gerrit a good candidate?) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Mittwoch, 7. Mai 2014 02:18 An: Ant Developers List Betreff: Re: Hoped for advantages of migrating to git Matt, Jesse, I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work, including more command line work, in the case of a migration to git-wip- us.apache.org as opposed to migrating to use only github. I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ? Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial. While github today is a very attractive platform, it could one day diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence. There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txt which links the apache user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors of Apache projects ? Also, while researching this I found an interesting presentation by Jukka Zitting [1] and a mail message concerning Apache and Github [2] and also a wiki page from the Apache Cordova project [3] Best regards, Antoine [1] http://www.slideshare.net/jukka/apache-development-with-github-and- travis-ci [2] http://mail-archives.apache.org/mod_mbox/lucene- dev/201401.mbox/%3c596fff55-6e33-4451-93d4-75add6cad...@gmail.com%3E [3] http://wiki.apache.org/cordova/GitWorkflow On May 6, 2014, at 6:33 PM, Matt Sicker boa...@gmail.com wrote: I mean how do you accept pull requests? You wouldn't be able to do it through GitHub. You'd have to manually pull the branch from GitHub like the name pull request implies. If you could commit to GitHub, then you could add a remote besides origin for GitHub, then pull from the GitHub remote, then push to the ASF remote (origin). On 6 May 2014 01:45, Stefan Bodewig bode...@apache.org wrote: On 2014-05-06, Matt Sicker wrote: Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. You don't, you commit to the ASF repo and it gets mirrored. IIRC some projects have their own forks of the ASF mirror and accept pull request on this fork. They then merge changes from their fork to the ASF repo. I'm not conviced I'd want to work that way, applying PRs without the Web-UI on a local checkout of the ASF git repo works fine for me. Stefan - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
I added my GH account info a while ago, but it only added my account to the ASF organization on GH. It's kinda buggy with linking histories even, and INFRA isn't too interested in resolving those issues since it's outside ASF. The Camel project takes PRs from GH, though, so they may have some useful info about that. On Tuesday, 6 May 2014, Antoine Levy Lambert anto...@gmx.de wrote: Matt, Jesse, I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work, including more command line work, in the case of a migration to git-wip-us.apache.org as opposed to migrating to use only github. I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ? Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial. While github today is a very attractive platform, it could one day diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence. There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txtwhich links the apache user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors of Apache projects ? Also, while researching this I found an interesting presentation by Jukka Zitting [1] and a mail message concerning Apache and Github [2] and also a wiki page from the Apache Cordova project [3] Best regards, Antoine [1] http://www.slideshare.net/jukka/apache-development-with-github-and-travis-ci [2] http://mail-archives.apache.org/mod_mbox/lucene-dev/201401.mbox/%3c596fff55-6e33-4451-93d4-75add6cad...@gmail.com%3E [3] http://wiki.apache.org/cordova/GitWorkflow On May 6, 2014, at 6:33 PM, Matt Sicker boa...@gmail.com javascript:; wrote: I mean how do you accept pull requests? You wouldn't be able to do it through GitHub. You'd have to manually pull the branch from GitHub like the name pull request implies. If you could commit to GitHub, then you could add a remote besides origin for GitHub, then pull from the GitHub remote, then push to the ASF remote (origin). On 6 May 2014 01:45, Stefan Bodewig bode...@apache.org javascript:; wrote: On 2014-05-06, Matt Sicker wrote: Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. You don't, you commit to the ASF repo and it gets mirrored. IIRC some projects have their own forks of the ASF mirror and accept pull request on this fork. They then merge changes from their fork to the ASF repo. I'm not conviced I'd want to work that way, applying PRs without the Web-UI on a local checkout of the ASF git repo works fine for me. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org javascript:; For additional commands, e-mail: dev-h...@ant.apache.org javascript:; -- Matt Sicker boa...@gmail.com javascript:; - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org javascript:; For additional commands, e-mail: dev-h...@ant.apache.org javascript:; -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
I mean how do you accept pull requests? You wouldn't be able to do it through GitHub. You'd have to manually pull the branch from GitHub like the name pull request implies. If you could commit to GitHub, then you could add a remote besides origin for GitHub, then pull from the GitHub remote, then push to the ASF remote (origin). On 6 May 2014 01:45, Stefan Bodewig bode...@apache.org wrote: On 2014-05-06, Matt Sicker wrote: Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. You don't, you commit to the ASF repo and it gets mirrored. IIRC some projects have their own forks of the ASF mirror and accept pull request on this fork. They then merge changes from their fork to the ASF repo. I'm not conviced I'd want to work that way, applying PRs without the Web-UI on a local checkout of the ASF git repo works fine for me. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
Git allows you to do both. You can auto-merge from GH, but I'm not sure how you can even get write access to ASF GH repos. On Monday, 5 May 2014, Jesse Glick typr...@gmail.com wrote: On Mon, May 5, 2014 at 8:22 AM, Nicolas Lalevée nicolas.lale...@hibnet.org javascript:; wrote: once a committer is satisfied with the result, the work is being imported into the git repo with a script A much more straightforward workflow is just to do all work in the GitHub repo, accepting pull requests simply by pressing the Merge button, and have some cron process to push from the GH repo to the ASF repo—using the latter merely as a mirror to satisfy legal requirements, and acknowledging that GH is far more functional and pleasant to work with. I am not working on Ant these days (everything pertaining to my job uses Maven) so I have little personal stake; this is just a suggestion. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org javascript:; For additional commands, e-mail: dev-h...@ant.apache.org javascript:; -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
Git is great for making small branches for things like bugfixes, features, refactors, etc. That plus it's way faster than Subversion. Freaky fast. On 30 April 2014 09:01, Josh Suereth joshua.suer...@gmail.com wrote: If you don't mind some recommendations from the peanut gallery (been using git for 5 years now) On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert anto...@gmx.de wrote: Hello Maarten, I do not know a lot about git either. Here are the advantages I see in migrating to git : - git allows third-parties to clone an original repository and in fact to create a fork while keeping the possibility of contributing back what they have created if they want to, and also importantly to incorporate inside their branches changes done elsewhere including in the reference repository. So I see git as having the same strategic importance for the source code like the fact of uploading the ant jars to maven central is for the use of the binaries. This is pretty huge. The cost of contributions is a lot lower *and* you can perform magic on branches (git rebase) before submitting to upstream projects. We (sbt + Scala) generally have a workflow of: 1. hack, hack, hack on our own clone/branch with a name wip 2. When done (across the group working on it), rebase the commits and clean up the commit messages to be as useful as possible 3. Submit a pull request, code review, go back to #1 as necessary 4. Merge into master, delete local branch, continue work. Not only that, we're already using the git Ivy mirror to collaborate between sbt devs and outside ivy contributors. It's a very good model for highly distributed (i.e. OSS) teams where coordination of contributions is hard. - for the developers of the Apache project - us - the small advantages are to be able to commit stuff locally on our computers before pushing when we are happy with our changes. Also one can switch branch very quickly within the same workspace when using git, this might be an advantage. I often run 3-5 branches of code for OSS projects. 1-2 of itch scratching and 1-3 of bug fixing. It's a great thing. - because of the popularity of git I imagine that the change is good for the long run but this is speculation Popularity definitely puts it above something like mercurial. It also means the tooling for git has become pretty good over the past few years. JGit even provides really good Git support for programatic access. I imagine that some corporations, individuals,or other open source organizations will take advantage of our projects moving to git to create these forks, either because the contribution process via JIRA is too slow, or because they want to create proprietary enhancements, or because they are not sure that the changes that they do match the views /plans... of our the Ant/Ivy/Ivyde/Easyant Apache project. From an sbt perspective, you'd see us attempting to contribute things back far more often than we do now. If you'd like an example project that contains website assets in it, feel free to checkout github.com/sbt/sbtand see how long it takes to switch branches / load the repository initially. - The Peanut Gallery (Josh) -- Matt Sicker boa...@gmail.com
Re: Hoped for advantages of migrating to git
-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 -- Matt Sicker boa...@gmail.com
Re: migration to git and web site publication
It's good to use a separate git repository (or svn repository or whatever works best for you) for storing large assets. You can use it as a git submodule to pull in a specific revision ID (so it's somewhat similar to svn:external, except you have to update it yourself and commit changes to the pointer in the parent repository). That way it only takes up a tiny text file in the main git repo. On 29 April 2014 07:50, Dominique Devienne ddevie...@gmail.com wrote: On Tue, Apr 29, 2014 at 12:15 PM, Antoine Levy Lambert anto...@gmx.de wrote: On Apr 29, 2014, at 3:32 AM, Dominique Devienne ddevie...@gmail.com wrote: Just for info, what makes you say that? Why would git be worse than SVN for large files? Below see some references found in google, the first one says that each version of a large file is stored (or maybe each version with a different md5). [DD] Read this old thread [1], I get the impression that git supports deltas both during network transfers, and in the remote repo, but chooses performance by default over disk-space, by keeping full copies of files. But git does support delta-compression, even across files apparently. So I guess it's more the matter of DCVS' in general forcing you to get the whole repos, that is the main drawback of storing large files in them. But I'm definitely out of my depth here, so I'll stop here :). --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
Re: migration to git and web site publication
You can use git submodules similarly. I just don't think it stays automatically up to date with the HEAD of a branch. If you want that, I believe you need to use a 3rd party plugin. On 29 April 2014 10:10, Jean-Louis Boudart jeanlouis.boud...@gmail.comwrote: Then this could be an issue with while migrating to git for Ivy / EasyAnt as they both use xooki to create website and project documentation (website contains version of each releassed documentation through svn:external). I thought gitpubsub could be used for website. 2014-04-29 5:00 GMT+02:00 Antoine Levy Lambert anto...@gmx.de: Hello Jan, On Apr 28, 2014, at 1:29 AM, Jan Matèrne (jhm) apa...@materne.de wrote: The web sites will remain in svn in any event because svnpubsub is the only supported mechanism to maintain web sites AFAIK. I havent looked at the current svnpubsub, but there is also one with that name for git https://www.apache.org/dev/gitpubsub.html I would appreciate to have the same scm. Could we start a new git repo for tests and vote later after the git/gitpubsub is working? Apache Infra does not support gitpubsub for the purpose of maintaining an Apache web site. I asked confirmation of that on the #asfinfra All Apache web sites are in svn and use svnpubsub. git is not the tool of choice to deal with large files such as the ones on dist.apache.org. That might be part of the reason why infra supports only svn for the web site. Jan Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/ -- Matt Sicker boa...@gmail.com
Re: svn commit: r1588563 [4/16] - in /ant/core/trunk: ./ manual/ manual/Types/ src/etc/testcases/taskdefs/ src/etc/testcases/taskdefs/optional/ src/etc/testcases/taskdefs/optional/antlr/ src/etc/testc
You can use the ExpectedException rule exactly where you expect the exception to be thrown. Using the @Test(expected = foo.class) (or whatever the attribute name was) is for the whole method. Unless you're talking about larger methods being tested that can throw multiple exceptions, then that's a different story altogether. On 19 April 2014 04:59, Michael Clarke michael.m.cla...@gmail.com wrote: buildRule.executeTarget(test1); == could the BuildFileRule use a default (test name) for executeTarget? buildRule.executeTarget(); I'm not sure it can - the same build file is often used for multiple tests, each calling a different target, so how would we know which target was intending to be called? If we were to change the general testing practice to have an individual build XML for each test then this would be fine, although I'm not sure this would be the right way to go. Alternatively we could have an executeTarget() method that executes a default target (e.g. test) or incrementally executes targets for that class (test1 on first call, test2 on the second call), but this seems like it would just be introducing complexity into BuildFileRule to force a specific convention. I'd be interested in other's opinions on this though. //TODO assert exception message Here the rule ExpectedException would help Agreed, although the problem still remains that we're not asserting we have the right exception: how do we know Ant hasn't thrown a build exception about a missing attribute when the test is expecting it to throw a BuildException about now being able to create a temporary file? Working out the exception messages and moving to ExpectedException is currently planned to be part of my second phase of migration. There are some tests where we have multiple exception asserts grouped into a single method so I need to spit these into individual methods to allow the ExpectedException rule to be used, but I plan on doing this as part of the exception testing cleanup. Thanks, Michael -- Matt Sicker boa...@gmail.com
Re: Migration of Ant test to JUnit4
This is pretty awesome! On 12 April 2014 07:37, Michael Clarke michael.m.cla...@gmail.com wrote: Hi, I've now completed the migration of Ant's test cases to JUnit4 and would like to give other developers a chance to review/comment on these changes before I merge them back into SVN. My changes can be found on Github at https://github.com/mc1arke/ant/tree/JUnit4Conversion ( https://github.com/mc1arke/ant/compare/JUnit4Conversion.patch for anyone who wants to apply a patch against their local workspace). Notable changes: 1. Deprecation of org.apache.tools.ant.BuildFileTest and org.apache.tools.ant.types.selectors.BaseSelectorTest 2. Introduction of org.apache.tools.ant.BuildFileRule and org.apache.tools.ant.types.selectors.BaseSelectorRule to replace deprecated classes, but with the removal of methods directly relating to asserting values 3. Introduction of org.apache.tools.ant.AntAssert to provide additional Asserts beyond the default JUnit ones, and thecreation of org.apache.tools.ant.FileUtilities to provide common file utilities used in many tests 4. Addition of @Test annotation to all Test methods, and addition or @Ignore annotations to methods that had previously been commented out or named in a way that prevented JUnit 3 seeing/running them. 5. Use of JUnit's Assume to dynamically skip tests that previously silently returned if certain conditions weren't met (e.g. the Symlink tests not running on Windows) 6. TODO markers added to tests that previously used exception handling checks but didn't check the value of the exception being returned. I'll look at coming back to these in the future to add proper asserts and remove the TODOs. 7. Removal of Thread.sleep in tests, and the sleep command in associated XML build files where this has been used to force a difference in file creation timestamps, and the use of File.setLastModified() instead. This has knocked 1 minute 30 seconds off the JUnit execution time using Cloudbees Buildhive Jenkins instance, although I've not looked at whether similar can be done for the AntUnit tests. 8. Updated the documentation for writing tests to refer to the new 'Rule' classes rather than the previous Test classes I'll hold of committing these changes to SVN for a couple of days to give people a chance to comment. Unless I hear any significant objections to these changes by the middle of Wednesday, I'll look commit to SVN on Wednesday night (UK time). Thanks, Michael -- Matt Sicker boa...@gmail.com
Re: svn commit: r1580520 - in /ant/core/trunk: ./ manual/Tasks/ src/main/org/apache/tools/ant/taskdefs/optional/junit/
@Michael: I'll fork your repo then to continue work on that. I actually got interested in Ant finally due to build troubles at my job. We've got two separate build systems on one of our largest projects: a terribly written ant build, and a terribly slow gradle build. I've taken over rewriting the ant build, and in the process, I ended up rewriting an antlib we were using which got me further into Ant internals. I couldn't get into gradle or maven, but ant was actually understandable! On 31 March 2014 20:46, Antoine Levy Lambert anto...@gmx.de wrote: Hello Michael, yes please go back and continue this, this is interesting. @Matt we are always happy to have new volunteers to help us maintain Ant :-) Ant’s minimum Java version is 1.5 so we are good on that side. Regards, Antoine On Mar 31, 2014, at 5:28 PM, Michael Clarke michael.m.cla...@gmail.com wrote: I had started this a few months back ( https://github.com/mc1arke/ant/tree/JUnit4Conversion) but got side-tracked due to a job change. I'd be happy to go back and continue/finish the work if there's a general demand for it. On 31 March 2014 01:14, Matt Sicker boa...@gmail.com wrote: I'd be a willing volunteer to help port the unit tests to JUnit 4. There are various methods to using JUnit 4 with JUnit 3 test cases, suites, etc., that allow for easier migration as well. I do know that JUnit 4 has a minimum requirement of Java 1.5 at least due to annotations. On 30 March 2014 18:53, Antoine Levy Lambert anto...@gmx.de wrote: Hello Matt, thanks for this suggestion. I have not used the JUnit TemporaryFolder rule because it is introduced in JUnit 4 and the Ant test cases are extending a class of JUnit 3. The policy of the Ant project is usually to keep everything binary compatible ... If there is interest and willing volunteers and a consensus we could change that, at least in the case of BuildFileTest and JUnit 3/4 and base BuildFileTest on JUnit 4. Regards, Antoine On Mar 23, 2014, at 1:50 PM, Matt Sicker boa...@gmail.com wrote: Could you use the JUnit TemporaryFolder rule? That appears to be rather threadsafe. On 23 March 2014 11:28, Antoine Levy Lambert anto...@gmx.de wrote: Hi, Thanks to John Elion for this contribution. I have tried it on the Ant test cases. This makes the execution of the test cases shorter by 3 minutes with 2 threads [ not sure what is the total time because I also run the antunit tests ]. Some of our test cases do not support parallelism because they are creating and dropping temporary directories and files which have the same names. - 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 -- Matt Sicker boa...@gmail.com
Re: svn commit: r1553704 - /ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
Oh man those logger call stacks are notoriously difficult to deal with.
On 1 April 2014 01:24, Charles Duffy char...@dyfis.net wrote:
The amount of fun otherwise involved when two separate threads called
into Ivy code in parallel was considerable, and was regularly resulting in
a logger stack with no relationship with any individual thread's call
stack.
On Mar 25, 2014 7:27 AM, Maarten Coene maarten_co...@yahoo.com wrote:
Maybe a bit late, but what was the reason to use a ThreadLocal here?
This gives issues when the configuration of Ivy (for instance setting a
custom logger) is done from a different thread than the actual resolve.
Maarten
Van: cdu...@apache.org cdu...@apache.org
Aan: notificati...@ant.apache.org
Verzonden: vrijdag 27 december 18:40 2013
Onderwerp: svn commit: r1553704 -
/ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
Author: cduffy
Date: Fri Dec 27 17:40:20 2013
New Revision: 1553704
URL: http://svn.apache.org/r1553704
Log:
Move non-root MessageLogger instances into a thread-local stack
Logger context is inherently thread-local.
Modified:
ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
Modified:
ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
URL:
http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java?rev=1553704r1=1553703r2=1553704view=diff
==
---
ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
(original)
+++
ant/ivy/core/trunk/src/java/org/apache/ivy/util/MessageLoggerEngine.java
Fri Dec 27 17:40:20 2013
@@ -34,7 +34,7 @@ import java.util.Stack;
* /p
*/
public class MessageLoggerEngine implements MessageLogger {
-private final Stack/*MessageLogger*/ loggerStack = new Stack();
+private final ThreadLocal/*StackMessageLogger*/ loggerStacks =
new ThreadLocal();
private MessageLogger defaultLogger = null;
@@ -44,6 +44,15 @@ public class MessageLoggerEngine impleme
private List errors = new ArrayList();
+private Stack getLoggerStack() {
+Stack stack = (Stack) loggerStacks.get();
+if (stack == null) {
+stack = new Stack();
+loggerStacks.set(stack);
+}
+return stack;
+}
+
public MessageLoggerEngine() {
}
@@ -66,7 +75,7 @@ public class MessageLoggerEngine impleme
*/
public void pushLogger(MessageLogger logger) {
Checks.checkNotNull(logger, logger);
-loggerStack.push(logger);
+getLoggerStack().push(logger);
}
/**
@@ -76,8 +85,8 @@ public class MessageLoggerEngine impleme
* /p
*/
public void popLogger() {
-if (!loggerStack.isEmpty()) {
-loggerStack.pop();
+if (!getLoggerStack().isEmpty()) {
+getLoggerStack().pop();
}
}
@@ -86,10 +95,10 @@ public class MessageLoggerEngine impleme
* @return the current logger, or the default one if there is no
logger in the stack
*/
public MessageLogger peekLogger() {
-if (loggerStack.isEmpty()) {
+if (getLoggerStack().isEmpty()) {
return getDefaultLogger();
}
-return (MessageLogger) loggerStack.peek();
+return (MessageLogger) getLoggerStack().peek();
}
private MessageLogger getDefaultLogger() {
@@ -130,7 +139,7 @@ public class MessageLoggerEngine impleme
public void clearProblems() {
getDefaultLogger().clearProblems();
-for (Iterator iter = loggerStack.iterator(); iter.hasNext();) {
+for (Iterator iter = getLoggerStack().iterator();
iter.hasNext();) {
MessageLogger l = (MessageLogger) iter.next();
l.clearProblems();
}
@@ -142,7 +151,7 @@ public class MessageLoggerEngine impleme
public void setShowProgress(boolean progress) {
getDefaultLogger().setShowProgress(progress);
// updates all loggers in the stack
-for (Iterator iter = loggerStack.iterator(); iter.hasNext();) {
+for (Iterator iter = getLoggerStack().iterator();
iter.hasNext();) {
MessageLogger l = (MessageLogger) iter.next();
l.setShowProgress(progress);
}
--
Matt Sicker boa...@gmail.com
Re: svn commit: r1580520 - in /ant/core/trunk: ./ manual/Tasks/ src/main/org/apache/tools/ant/taskdefs/optional/junit/
I'd be a willing volunteer to help port the unit tests to JUnit 4. There are various methods to using JUnit 4 with JUnit 3 test cases, suites, etc., that allow for easier migration as well. I do know that JUnit 4 has a minimum requirement of Java 1.5 at least due to annotations. On 30 March 2014 18:53, Antoine Levy Lambert anto...@gmx.de wrote: Hello Matt, thanks for this suggestion. I have not used the JUnit TemporaryFolder rule because it is introduced in JUnit 4 and the Ant test cases are extending a class of JUnit 3. The policy of the Ant project is usually to keep everything binary compatible … If there is interest and willing volunteers and a consensus we could change that, at least in the case of BuildFileTest and JUnit 3/4 and base “BuildFileTest” on JUnit 4. Regards, Antoine On Mar 23, 2014, at 1:50 PM, Matt Sicker boa...@gmail.com wrote: Could you use the JUnit TemporaryFolder rule? That appears to be rather threadsafe. On 23 March 2014 11:28, Antoine Levy Lambert anto...@gmx.de wrote: Hi, Thanks to John Elion for this contribution. I have tried it on the Ant test cases. This makes the execution of the test cases shorter by 3 minutes with 2 threads [ not sure what is the total time because I also run the antunit tests ]. Some of our test cases do not support parallelism because they are creating and dropping temporary directories and files which have the same names. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
Re: svn commit: r1580520 - in /ant/core/trunk: ./ manual/Tasks/ src/main/org/apache/tools/ant/taskdefs/optional/junit/
Could you use the JUnit TemporaryFolder rule? That appears to be rather threadsafe. On 23 March 2014 11:28, Antoine Levy Lambert anto...@gmx.de wrote: Hi, Thanks to John Elion for this contribution. I have tried it on the Ant test cases. This makes the execution of the test cases shorter by 3 minutes with 2 threads [ not sure what is the total time because I also run the antunit tests ]. Some of our test cases do not support parallelism because they are creating and dropping temporary directories and files which have the same names. this makes errors looking like this one : [junit] Testcase: testNoAddNewLine(org.apache.tools.ant.filters.NoNewLineTest): Caused an ERROR [junit] Warning: Could not find file /Users/antoine/dev/asf/ant-core/src/etc/testcases/filters/result/nonl to copy. [junit] /Users/antoine/dev/asf/ant-core/src/etc/testcases/filters/build.xml:111: Warning: Could not find file /Users/antoine/dev/asf/ant-core/src/etc/testcases/filters/result/nonl to copy. [junit] at org.apache.tools.ant.taskdefs.Copy.copySingleFile(Copy.java:639) Does someone have a suggestion about how to adapt the test cases to support parallelism. I was thinking of adding somewhere in the Ant codebase a utility class or method to get the PID of the currently running process and add the PID somewhere in the name of temporary folders created for tests. Any thoughts on that ? see http://stackoverflow.com/questions/35842/how-can-a-java-program-get-its-own-process-id Regards, Antoine On Mar 23, 2014, at 12:18 PM, anto...@apache.org wrote: Author: antoine Date: Sun Mar 23 16:18:29 2014 New Revision: 1580520 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Matt Sicker boa...@gmail.com
