Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
On Fri, Sep 19, 2008 at 12:10 AM, Wardrip, Paul <[EMAIL PROTECTED]>wrote:
> I entered one about multiple artifacts and included the patch I've been
> using with beta2: https://issues.apache.org/jira/browse/IVY-770
>
> I tried to setup one of my projects so each artifact has a separate
> build.xml and ivy.xml, but a relative path of ../target was breaking
> when I used subant. Am I correct in assuming that
> https://issues.apache.org/jira/browse/IVY-232 will fix this?
Yes, it should, but you can try 2.0-rc1 attempt to see if it works. And note
that the workaround is pretty easy: use ${basedir}/../target.
>
>
> If I can setup this kind of build then I can work around the multi
> artifact issue (although it's just like needing a pom for each artifact
> in maven... yuck). The packaging issue would still force me to compile
> my own ivy.jar. I would rather use the release unmodified, I'm sure the
> management would like that too. ;)
Sure. But now we are in feature freeze mode for 2.0.x, so this improvement
will probably not be included before 2.1.
Xavier
>
> --pw
>
> -Original Message-
> From: Maarten Coene [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 18, 2008 4:56 PM
> To: Ant Developers List
> Subject: Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
>
> Indeed, and an error (or warning) could be thrown if you Ivy module
> defines an artifact having a different name than the module name.
> I think there was a JIRA issue as well for supporting more than 1
> artifact...
>
> Maarten
>
>
>
> - Original Message
> From: Xavier Hanin <[EMAIL PROTECTED]>
> To: Ant Developers List
> Sent: Thursday, September 18, 2008 10:49:40 PM
> Subject: Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
>
> On Thu, Sep 18, 2008 at 10:12 PM, Wardrip, Paul
> <[EMAIL PROTECTED]>wrote:
>
> > In PomModuleDescriptorWriter.java would it be possible to change hard
> > coded "jar" value that is written for packaging to use the artifact
> > extension? If I publish something that isn't a jar to a maven
> > repository, ivy expects it to be a jar when I try to use it as a
> > dependency of another project.
> >
> >private static void printModuleId(ModuleDescriptor md, PrintWriter
> > out) {
> >ModuleRevisionId mrid = md.getModuleRevisionId();
> >out.println(" " + mrid.getOrganisation() +
> > "");
> >out.println(" " + mrid.getName() +
> > "");
> >out.println(" jar");
> >
> > -- to --
> >
> >out.println(" " + artifacts[i].getExt() +
> > "");
>
>
> The only problem I see to implement it is that in Ivy you can have
> multiple artifacts, while in Maven you have only one (well, you can have
> more with qualifiers, but you have one main artifact). So the patch is
> not that easy, but it could be at least improved when only one artifact
> is published by the Ivy module.
>
> Xavier
>
>
> >
> >
> > Paul Wardrip
> > Software Engineer, OpenStream
> > TANDBERG Television | Part of the Ericsson Group 4500 River Green
> > Parkway | Duluth | GA 30096
> > Mobile: 770-312-2852 | AIM: paulwardrip
> > Email: [EMAIL PROTECTED] | www.tandbergtv.com
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> > commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Xavier Hanin - Independent Java Consultant BordeauxJUG co leader -
> http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache
> Ivy Creator - http://ant.apache.org/ivy/
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: DirectoryScanner performance
Hi, > At the same time memory usage has increased with 1.7.0 and never > decreased after that, in fact the current HEAD uses more memory than > ever before. Something between revisions 687768 and 693846 has bumped > the memory mark without gaining us much in terms of performance, I'll > try to isolate and remove that later. This is an issue. Looking at your results, memory has significantly increased somewhere and for large builds we were already causing OutOfMemory errors. Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DirectoryScanner performance
Tests on Ubuntu 8.04, Java 1.6, I only tested two svn revisions and 1.7.1 (and used top instead of task manager in my highly scientific approach to measure memory consumption 8-) The trends are the same. Even though the machine is a lot slower than my work Windows system the times are comparable. I guess Linux' tempfs is quite a bit faster than a real NTFS formatted disk. The pre-tokenization changes have a stronger effect, though. My guess - again - is that scanning is stronger I/O bound on the Windows machine and CPU bound on tempfs on Linux. It also seems as if I needed to modify the test setup to make it even larger if I want to compare further tweaks. Interestingly the effect of followSymlinks=false is far less dramatic on Linux than on Windows. I removed memoization of File.list and File.getCanonicalPath (only local, not yet committed) and it didn't change much, so I'll probably remove it completely. I added a new many-roots tests (not part of the timings for "all" below) that should be sensitive to memoization and pre-tokenization. tests with default settings === matchall Ant 1.7.1 15 s ~ 20 MB trunk rev 696355 12 s ~ 34 MB trunk rev 696674 2 s ~ 29 MB no memoization 2 s ~ 20 MB roots - Ant 1.7.1 0 s ~ ?? MB trunk rev 696355 0 s ~ ?? MB trunk rev 696674 0 s ~ ?? MB no memoization 0 s ~ ?? MB recursive-excludes -- Ant 1.7.1 2 s ~ 14 MB trunk rev 696355 2 s ~ 13 MB trunk rev 696674 1 s ~ 19 MB no memoization 1 s ~ 21 MB name-matches Ant 1.7.1 3 s ~ 19 MB trunk rev 696355 3 s ~ 31 MB trunk rev 696674 2 s ~ 24 MB no memoization 1 s ~ 20 MB many-patterns - Ant 1.7.1 4 s ~ 21 MB trunk rev 696355 4 s ~ 28 MB trunk rev 696674 1 s ~ 35 MB no memoization 1 s ~ 22 MB all --- Ant 1.7.1 20 s ~ 41 MB trunk rev 696355 20 s ~ 44 MB trunk rev 696674 6 s ~ 43 MB no memoization 5 s ~ 44 MB many-roots -- Ant 1.7.1 14 s ~ 27 MB trunk rev 696674 2 s ~ 35 MB no memoization 2 s ~ 30 MB Case-insensitive scan = all --- Ant 1.7.1 21 s ~ 40 MB trunk rev 696355 20 s ~ 44 MB trunk rev 696674 6 s ~ 43 MB no memoization 5 s ~ 43 MB No followSymlinks = all --- Ant 1.7.1 25 s ~ 38 MB trunk rev 696355 24 s ~ 45 MB trunk rev 696674 9 s ~ 45 MB no memoization 8 s ~ 45 MB - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
I entered one about multiple artifacts and included the patch I've been
using with beta2: https://issues.apache.org/jira/browse/IVY-770
I tried to setup one of my projects so each artifact has a separate
build.xml and ivy.xml, but a relative path of ../target was breaking
when I used subant. Am I correct in assuming that
https://issues.apache.org/jira/browse/IVY-232 will fix this?
If I can setup this kind of build then I can work around the multi
artifact issue (although it's just like needing a pom for each artifact
in maven... yuck). The packaging issue would still force me to compile
my own ivy.jar. I would rather use the release unmodified, I'm sure the
management would like that too. ;)
--pw
-Original Message-
From: Maarten Coene [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2008 4:56 PM
To: Ant Developers List
Subject: Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
Indeed, and an error (or warning) could be thrown if you Ivy module
defines an artifact having a different name than the module name.
I think there was a JIRA issue as well for supporting more than 1
artifact...
Maarten
- Original Message
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Thursday, September 18, 2008 10:49:40 PM
Subject: Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
On Thu, Sep 18, 2008 at 10:12 PM, Wardrip, Paul
<[EMAIL PROTECTED]>wrote:
> In PomModuleDescriptorWriter.java would it be possible to change hard
> coded "jar" value that is written for packaging to use the artifact
> extension? If I publish something that isn't a jar to a maven
> repository, ivy expects it to be a jar when I try to use it as a
> dependency of another project.
>
>private static void printModuleId(ModuleDescriptor md, PrintWriter
> out) {
>ModuleRevisionId mrid = md.getModuleRevisionId();
>out.println(" " + mrid.getOrganisation() +
> "");
>out.println(" " + mrid.getName() +
> "");
>out.println(" jar");
>
> -- to --
>
>out.println(" " + artifacts[i].getExt() +
> "");
The only problem I see to implement it is that in Ivy you can have
multiple artifacts, while in Maven you have only one (well, you can have
more with qualifiers, but you have one main artifact). So the patch is
not that easy, but it could be at least improved when only one artifact
is published by the Ivy module.
Xavier
>
>
> Paul Wardrip
> Software Engineer, OpenStream
> TANDBERG Television | Part of the Ericsson Group 4500 River Green
> Parkway | Duluth | GA 30096
> Mobile: 770-312-2852 | AIM: paulwardrip
> Email: [EMAIL PROTECTED] | www.tandbergtv.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
>
>
--
Xavier Hanin - Independent Java Consultant BordeauxJUG co leader -
http://www.bordeauxjug.org/ Blogger - http://xhab.blogspot.com/ Apache
Ivy Creator - http://ant.apache.org/ivy/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
Indeed, and an error (or warning) could be thrown if you Ivy module defines an
artifact having a different name than the module name.
I think there was a JIRA issue as well for supporting more than 1 artifact...
Maarten
- Original Message
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Thursday, September 18, 2008 10:49:40 PM
Subject: Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
On Thu, Sep 18, 2008 at 10:12 PM, Wardrip, Paul <[EMAIL PROTECTED]>wrote:
> In PomModuleDescriptorWriter.java would it be possible to change hard
> coded "jar" value that is written for packaging to use the artifact
> extension? If I publish something that isn't a jar to a maven
> repository, ivy expects it to be a jar when I try to use it as a
> dependency of another project.
>
>private static void printModuleId(ModuleDescriptor md, PrintWriter
> out) {
>ModuleRevisionId mrid = md.getModuleRevisionId();
>out.println(" " + mrid.getOrganisation() +
> "");
>out.println(" " + mrid.getName() +
> "");
>out.println(" jar");
>
> -- to --
>
>out.println(" " + artifacts[i].getExt() +
> "");
The only problem I see to implement it is that in Ivy you can have multiple
artifacts, while in Maven you have only one (well, you can have more with
qualifiers, but you have one main artifact). So the patch is not that easy,
but it could be at least improved when only one artifact is published by the
Ivy module.
Xavier
>
>
> Paul Wardrip
> Software Engineer, OpenStream
> TANDBERG Television | Part of the Ericsson Group
> 4500 River Green Parkway | Duluth | GA 30096
> Mobile: 770-312-2852 | AIM: paulwardrip
> Email: [EMAIL PROTECTED] | www.tandbergtv.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
On Thu, Sep 18, 2008 at 10:12 PM, Wardrip, Paul <[EMAIL PROTECTED]>wrote:
> In PomModuleDescriptorWriter.java would it be possible to change hard
> coded "jar" value that is written for packaging to use the artifact
> extension? If I publish something that isn't a jar to a maven
> repository, ivy expects it to be a jar when I try to use it as a
> dependency of another project.
>
>private static void printModuleId(ModuleDescriptor md, PrintWriter
> out) {
>ModuleRevisionId mrid = md.getModuleRevisionId();
>out.println(" " + mrid.getOrganisation() +
> "");
>out.println(" " + mrid.getName() +
> "");
>out.println(" jar");
>
> -- to --
>
>out.println(" " + artifacts[i].getExt() +
> "");
The only problem I see to implement it is that in Ivy you can have multiple
artifacts, while in Maven you have only one (well, you can have more with
qualifiers, but you have one main artifact). So the patch is not that easy,
but it could be at least improved when only one artifact is published by the
Ivy module.
Xavier
>
>
> Paul Wardrip
> Software Engineer, OpenStream
> TANDBERG Television | Part of the Ericsson Group
> 4500 River Green Parkway | Duluth | GA 30096
> Mobile: 770-312-2852 | AIM: paulwardrip
> Email: [EMAIL PROTECTED] | www.tandbergtv.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Xavier Hanin - Independent Java Consultant
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
If you want this issue to be fixed, please do
- vote for https://issues.apache.org/jira/browse/IVY-736, or
- attach a patch to this issue, or
- attach a junit test to this issue, or
- do all of the things above :-)
Maarten
- Original Message
From: "Wardrip, Paul" <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Thursday, September 18, 2008 10:12:16 PM
Subject: Ivy 2.0.0-rc1 PomModuleDescriptorWriter
In PomModuleDescriptorWriter.java would it be possible to change hard
coded "jar" value that is written for packaging to use the artifact
extension? If I publish something that isn't a jar to a maven
repository, ivy expects it to be a jar when I try to use it as a
dependency of another project.
private static void printModuleId(ModuleDescriptor md, PrintWriter
out) {
ModuleRevisionId mrid = md.getModuleRevisionId();
out.println(" " + mrid.getOrganisation() +
"");
out.println(" " + mrid.getName() +
"");
out.println(" jar");
--to --
out.println(" " + artifacts[i].getExt() +
"");
Paul Wardrip
Software Engineer, OpenStream
TANDBERG Television | Part of the Ericsson Group
4500 River Green Parkway | Duluth | GA 30096
Mobile: 770-312-2852 | AIM: paulwardrip
Email: [EMAIL PROTECTED] | www.tandbergtv.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ivy 2.0.0-rc1 PomModuleDescriptorWriter
In PomModuleDescriptorWriter.java would it be possible to change hard
coded "jar" value that is written for packaging to use the artifact
extension? If I publish something that isn't a jar to a maven
repository, ivy expects it to be a jar when I try to use it as a
dependency of another project.
private static void printModuleId(ModuleDescriptor md, PrintWriter
out) {
ModuleRevisionId mrid = md.getModuleRevisionId();
out.println(" " + mrid.getOrganisation() +
"");
out.println(" " + mrid.getName() +
"");
out.println(" jar");
-- to --
out.println(" " + artifacts[i].getExt() +
"");
Paul Wardrip
Software Engineer, OpenStream
TANDBERG Television | Part of the Ericsson Group
4500 River Green Parkway | Duluth | GA 30096
Mobile: 770-312-2852 | AIM: paulwardrip
Email: [EMAIL PROTECTED] | www.tandbergtv.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DirectoryScanner performance
My complete test results are below. Ant 1.7.1 has been consistently a lot faster than 1.6.5 which consistently took half the time of 1.7.0. svn trunk's HEAD is consistently faster than 1.7.1. At the same time memory usage has increased with 1.7.0 and never decreased after that, in fact the current HEAD uses more memory than ever before. Something between revisions 687768 and 693846 has bumped the memory mark without gaining us much in terms of performance, I'll try to isolate and remove that later. The symlink loop detection has cost us a bit of performance but has been compensated by the later tokenization changes (and been more than made up for by VectorSet). Memoization of File.list and File.getCanonicalPath doesn't seem to win much, but before I remove it, I want to try it on a different OS. followsymlinks=false costs a lot of performance, and it seems to suck up memory as well - but this is completely due to File.getCanonicalPath and I don't think there was anything we could do. Stefan Raw test results to follow Method == All tests run on the same machine (WinXP) with the same JDK (1.4). For all tests < 60s the values are the median values of three consecutive runs (but to tell the truth, in most cases all three runs yielded the exact same results). Times are what Ant reports itself when it says "Build finished", memory numbers are the maximum values seen while watching the windows task manager - which also means it is the total memory of the Java process which could itself contain an empty heap. Contestants: Ant 1.6.5 Ant 1.7.0 Ant 1.7.1 trunk rev 687768- PathPattern trunk rev 693846- pre loop detection trunk rev 694254- with loop detection trunk rev 695389- memoization of canonical path trunk rev 696146- more pre-tokenization work trunk rev 696345- full pre-tokenization, no File.list memo trunk rev 696355- bring back memoization of File.list trunk rev 696674- introduction of VectorSet tests with default settings === matchall Ant 1.6.5 1 min 30 s ~ 19 MB Ant 1.7.0 3 min 53 s ~ 24 MB Ant 1.7.1 10 s ~ 14 MB trunk rev 687768 9 s ~ 19 MB trunk rev 693846 9 s ~ 30 MB trunk rev 694254 10 s ~ 41 MB trunk rev 695389 10 s ~ 39 MB trunk rev 696146 11 s ~ 39 MB trunk rev 696345 10 s ~ 41 MB trunk rev 696355 10 s ~ 43 MB trunk rev 696674 6 s ~ 44 MB roots - Ant 1.6.5 1 s ~ 14 MB Ant 1.7.0 3 s ~ 12 MB Ant 1.7.1 0 s ~ ?? MB trunk rev 687768 0 s ~ ?? MB trunk rev 693846 0 s ~ ?? MB trunk rev 694254 0 s ~ ?? MB trunk rev 695389 0 s ~ ?? MB trunk rev 696146 0 s ~ ?? MB trunk rev 696345 0 s ~ ?? MB trunk rev 696355 0 s ~ ?? MB trunk rev 696674 0 s ~ ?? MB recursive-excludes -- Ant 1.6.5 8 s ~ 19 MB Ant 1.7.0 16 s ~ 16 MB Ant 1.7.1 3 s ~ 14 MB trunk rev 687768 3 s ~ 14 MB trunk rev 693846 3 s ~ 24 MB trunk rev 694254 4 s ~ 29 MB trunk rev 695389 4 s ~ 28 MB trunk rev 696146 4 s ~ 28 MB trunk rev 696345 4 s ~ 27 MB trunk rev 696355 4 s ~ 28 MB trunk rev 696674 3 s ~ 31 MB name-matches Ant 1.6.5 11 s ~ 19 MB Ant 1.7.0 28 s ~ 17 MB Ant 1.7.1 3 s ~ 15 MB trunk rev 687768 3 s ~ 14 MB trunk rev 693846 4 s ~ 31 MB trunk rev 694254 5 s ~ 32 MB trunk rev 695389 5 s ~ 34 MB trunk rev 696146 5 s ~ 38 MB trunk rev 696345 4 s ~ 29 MB trunk rev 696355 5 s ~ 30 MB trunk rev 696674 3 s ~ 35 MB many-patterns - Ant 1.6.5 7 s ~ 19 MB Ant 1.7.0 13 s ~ 17 MB Ant 1.7.1 4 s ~ 17 MB trunk rev 687768 3 s ~ 14 MB trunk rev 693846 4 s ~ 20 MB trunk rev 694254 4 s ~ 23 MB trunk rev 695389 4 s ~ 24 MB trunk rev 696146 4 s ~ 25 MB trunk rev 696345 4 s ~ 29 MB trunk rev 696355 4 s ~ 25 MB trunk rev 696674 3 s ~ 26 MB all --- Ant 1.6.5 1 min 49 s ~ 30 MB Ant 1.7.0 4 min 54 s ~ 44 MB Ant 1.7.1 19 s ~ 4
Re: DirectoryScanner performance
On Thu, 18 Sep 2008, Steve Loughran <[EMAIL PROTECTED]> wrote: > Kevin Jackson wrote: > >> The tests are not through yet, but one thing was so surprising to me > >> that I wanted to show it upfront: > >> > >> Running the matchall target (of sr/etc/performance/dirscanner.xml): > >> > >> Ant 1.6.5 1 min 30 s ~ 19 MB > >> Ant 1.7.0 3 min 53 s ~ 24 MB > >> Ant 1.7.1 10 s ~ 14 MB > >> > >> So 1.7.0 took more than twice as long as 1.6.5 to find all files in a > >> big directory tree without any patterns and 1.7.1 is a whole lot > >> faster than even 1.6.5. > > > > That's a huge difference - what are we doing now in 1.7.1 that is > > different from before? > > > > I think it tries to sort stuff less. Not in DirectoryScanner, maybe in between 1.6.5 and 1.7.1. The pathconvert results of 1.6.5 and 1.7.1 are identical (only difference is that my drive letter - Windows - was lower case in 1.6.5 and is uppercase in 1.7.1). I checked because I couldn't believe the performance difference was real. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DirectoryScanner performance
On Thu, 18 Sep 2008, Kevin Jackson <[EMAIL PROTECTED]> wrote: >> The tests are not through yet, but one thing was so surprising to >> me that I wanted to show it upfront: >> >> Running the matchall target (of sr/etc/performance/dirscanner.xml): >> >> Ant 1.6.5 1 min 30 s ~ 19 MB >> Ant 1.7.0 3 min 53 s ~ 24 MB >> Ant 1.7.1 10 s ~ 14 MB >> >> So 1.7.0 took more than twice as long as 1.6.5 to find all files in >> a big directory tree without any patterns and 1.7.1 is a whole lot >> faster than even 1.6.5. > > That's a huge difference - what are we doing now in 1.7.1 that is > different from before? Jesse's changes in svn rev 581748 are the major contributor here, where he reduced the number of File.isDirectory/list calls and thus the number of OS syscalls. I'm currently testing something that will be committed in a few minutes and that runs the same test in 6 seconds 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ivy 2.0.0-rc1 Release
+1 Maarten - Original Message From: Xavier Hanin <[EMAIL PROTECTED]> To: Ant Developers List Sent: Tuesday, September 16, 2008 9:56:25 AM Subject: [VOTE] Ivy 2.0.0-rc1 Release I have built a release candidate for Ivy 2.0.0-rc1 You can download it from this URL: http://people.apache.org/~xavier/ivy/staging/2.0.0-rc1/ A maven 2 staging repo with this release is available here: http://people.apache.org/~xavier/m2-staging-repo/ A staging eclipse update site with this release is available here: http://people.apache.org/~xavier/updatesite-staging/ The bundle version is 2.0.0.cr1. Do you vote for the release of these binaries? [ ] Yes [ ] No Regards, Xavier, Ivy 2.0.0-rc1 release manager - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DirectoryScanner performance
Kevin Jackson wrote: The tests are not through yet, but one thing was so surprising to me that I wanted to show it upfront: Running the matchall target (of sr/etc/performance/dirscanner.xml): Ant 1.6.5 1 min 30 s ~ 19 MB Ant 1.7.0 3 min 53 s ~ 24 MB Ant 1.7.1 10 s ~ 14 MB So 1.7.0 took more than twice as long as 1.6.5 to find all files in a big directory tree without any patterns and 1.7.1 is a whole lot faster than even 1.6.5. That's a huge difference - what are we doing now in 1.7.1 that is different from before? I think it tries to sort stuff less. This broke hadoop builds as their class structure was wrong https://issues.apache.org/jira/browse/HADOOP-3907 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to configure batch file in build.xml
Jan K <[EMAIL PROTECTED]> wrote on 09/18/2008 02:54:57 AM: > I am new to ant.I need to configure batch file in Ant.I have Apache ActiveMq > installed for my mobile application.I need to include the activemq.bat file > in build.xml.Can you help me how to do this.I tried with exec command. This type of question is really not appropriate for the developer mailing list; please try the user list.
Re: DirectoryScanner performance
> The tests are not through yet, but one thing was so surprising to me > that I wanted to show it upfront: > > Running the matchall target (of sr/etc/performance/dirscanner.xml): > > Ant 1.6.5 1 min 30 s ~ 19 MB > Ant 1.7.0 3 min 53 s ~ 24 MB > Ant 1.7.1 10 s ~ 14 MB > > So 1.7.0 took more than twice as long as 1.6.5 to find all files in a > big directory tree without any patterns and 1.7.1 is a whole lot > faster than even 1.6.5. That's a huge difference - what are we doing now in 1.7.1 that is different from before? Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DirectoryScanner performance
Hi all, I've just committed a build file that uses pathconvert on a big directory tree to measure DirectoryScanner performance. Initially I only wanted to use it to compare current trunk with Ant 1.7.1 but when I saw that trunk was a tiny bit slower (something I didn't expect at all) I threw in Ant 1.6.5 and 1.7.0 as well as several trunk revisions between 1.7.1 and the current HEAD. The tests are not through yet, but one thing was so surprising to me that I wanted to show it upfront: Running the matchall target (of sr/etc/performance/dirscanner.xml): Ant 1.6.5 1 min 30 s ~ 19 MB Ant 1.7.0 3 min 53 s ~ 24 MB Ant 1.7.1 10 s ~ 14 MB So 1.7.0 took more than twice as long as 1.6.5 to find all files in a big directory tree without any patterns and 1.7.1 is a whole lot faster than even 1.6.5. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
