> From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
> >
> >Martijn, Matt, the example above would be necessary if and only
> >if only had a add(ResourceSelector). In
> >practice, we'll likely have specialized addAnd(ResourceSelector) and
co
> >so that if can be written just:
> >
> >
> >
>
> But
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> I think we already have 1. and 2. if we want to use
> antlibs, and assuming we can place additional
> resources where we like.
You mean that we can easily achieve 1. and 2. by
defining a few XML files (and modify some code for 2.), no?
AFAIK, we
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the
> "newer" antunit I've used org.apache.ant.antlibs.antunit.
>
> I'd like to drop the "tools" for antlibs and I think antlibs should be
> somewhere in the package names, so I
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> as well as org/apache/tools/ant/types/antlib.xml with
>
>
>
>
>
But won't that create some kind of warning because of the
and/or/etc... name clashes from conditions/selectors? --DD
---
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
>
> Do we want to release Ant 1.6.3 on Thursday, April 28th ?
>
> Yes [X]
> No [ ]
--DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> We shouldnt plan the name only for the svn-package.
> That´s a general question for future extensions.
>
> > Von: Peter Reilly [mailto:[EMAIL PROTECTED]
> > Perhaps it could be just "org.apache.ant.svn" - i.e. drop antlibs.
Actually, Peter
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>
> Use of "core" as a package/directory name is mildly off
in
> a UNIX environment as the directory might be confused with a core
dump!
> ;n)
>
> Phil :n)
It would be a directory instead of a file though, so it wouldn't be
mistaken for long.
> From: Martijn Kruithof [mailto:[EMAIL PROTECTED]
>
> I also like core best, but maybe it isn't such a good idea indeed.
Let's just forget about org.apache.ant.core... --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additi
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> Any thoughts on the propriety of adding
>
> public java.util.Iterator iterator() {
> //return property NAMES
> }
>
> to PropertySet? This would make it easy to use with
> ant-contrib's task. Not that we have an
> obligation to do that, but
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> I will take your opinion as gospel, since you are the
> father of PropertySet, and since you agree with me ;)
Note that I can't think of any use case for iterating
over the property names selected by a propertyset, but
I'm sure someone somewhere some
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
>
> Do we want to release ant 1.6.4 on Thursday, May 19th
> (this would at least suit Eclipse)
>
> [+1] Yes
> [ ] No
--DD
--
This e-mail, including any attached files, may c
of a PITA.
Any suggestion for this Outlook/Exchange user?
Are web-based client really usable? --DD
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 10, 2005 8:44 AM
> To: Ant Developers List
> Subject: RE: [VOTE] Ant 1.6.
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> On Mon, 9 May 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> > Variable can accept a nested PropertySet OR have its
> > key & value attributes set as usual
> >
> > I wonder about the feeling of the dev community on such a
> > change... ?
>
> Works
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> I knew there were a discussion about that ...
> http://marc.theaimsgroup.com/?l=ant-user&m=106278198725781&w=2
Eh, I even said the same thing back then! ;-) --DD
--
This e-m
> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> My reason for wanting to nest the propertyset into a
> regular element is that these are passed by
> and to an Environment
> object. This means that if the code is added to
> Environment, so that:
>
>
>
> refid="foo.properties" />
>
I don't know if this is just me,
but I don't see the point of .
Writing the antlib.xml resource manually
and including it in the jar is trivial.
We don't need special code for it. What
we may need is simply a little tutorial
about writing a basic AntLib, that's all,
and even that would mostly rep
> I never liked the target renaming stuff - it seems a bit strange.
> Be that as it may, the current behaviour is a bit silly - i.e. inconsistent.
> The target gets renamed if there another target of the same name, but
> not otherwise - how can one write a proper reusable import file using the
> re
On 5/16/05, Peter Reilly <[EMAIL PROTECTED]> wrote:
> You need to use the "flattened" name - uri + ":" + name eg:
>
Don't XML specs or XML tools use the {namespace}local-name notation
when they expand ns-prefix:local-name?
So it would read:
BTW, I didn't know about . I missed its introduction
On 5/16/05, Steve Loughran <[EMAIL PROTECTED]> wrote:
> I think what is happening is that the maven dependency model does work
> if you live only in maven-land (that is, provide your own poms, only set
> up classpaths via the dependency declarations). In this world,
> dependency logic should be a l
On 14 May 2005 13:14:15 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> +
> + + server="ftp.hypthetical.fr"
> + userid="anonymous"
> + password="[EMAIL PROTECTED]"
> + defaultDateFormatConfig="d MMM "
> + recentDateFormatConfig="d
+1. Double commits is work and easy to forget. I like Steve's idea of
a quarterly drop and I agree with Jesse that we should be stricter
about what goes into a dot-dot release. I don't have much else to add.
--DD
-
To unsubscribe,
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> please ignore this, I need to ensure I haven't been unsubscibed - I'm
> just no used to three mails only in three days.
That's just because Matt is taking a breather or something ;-)
I'm so far behind all this BugZilla activity. --DD
--
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> >Now that I have a win98 vmware image, I could put an old
> >release of something on there to do regression testing. No
> >1,2SDK for windows though, unless I can find one on a CD somewhere.
>
> I think there are some in the Sun archive [1].
Ullrich was kind enough to provide me data gathered by
my own performance listener, which shows timings for
tasks as well as targets:
Timing by tasks in Ant 1.6.2:in Ant 1.6.5
--- -- -- -- --- --
19.578,0 ms 175,2%24x antcall62.235,0 ms 189,0%
5
FYI. I've setup this nightly build on windows against JDK 1.2.2. It
currently fails. --DD
P:\ant\nightly\ant1.7-jdk1.2.2>diff
workarea\src\etc\testcases\taskdefs\fixcrlf\expected\tab_in_literal_in_c
omment
workarea\src\etc\testcases\taskdefs\fixcrlf\input\tab_in_literal_in_comm
ent
1c1
< // ""
On 6/28/05, Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Well, I cannot say I run nightly tests against all JDK versions but
> yesterday 1.7 head passed on java 1.2.2_017 on Win XP after increasing
> java memory to 512m.
I'm not too sure I understand your point Martijn. Doesn't look like a
memo
On 6/30/05, Eliot Sykes <[EMAIL PROTECTED]> wrote:
> I've got a need in a build process for retrieving the version number
> of a checked out file from CVS and setting a property equal to this
> version number.
>
> Does anybody know if a task exists that does this already? If so
> please let me kn
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> well, it'd be nice if we could get/set unix file permissions; that is
> the most important thing to me, symlinks would be good too. There are no
> real symlinks in NTFS, though hard links are allowed in the same
> filesystem.
What about NTFS 'junc
Phil is right Jean. Independently of splitting the code in subsystems, which
is always a good idea, even if you can't do that you can split the compile
of a single source tree into several passes using regular . This can
even enforce dependencies of the code compiled by the different passes. The
tr
Migration to SVN is just fine with me. As for when to do it exactly,
anytime before the 1/1/2006 dead-line is fine by me, and the sooner is
indeed the better. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional command
> I think it would be possible to include the examples in the Ant source
> too - this would make it even more clear what the code is trying to
> accomplish and would hep to prevent refactorings etc that go against the
> intended use of the code.
>
> My thought would be to include at the top of the
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> Committer: 13+6=19
> -
> +1: 6
> +0: 1
> -1: 0
> no vote: 12
I thought I +1'd or at least +0'd, but maybe not.
+1 one to SVN migration (do we have a choice ;-)
+0 to migration any given
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
>
> I'm thinking more of automatically pulling the entire set of files in a
> directory, even if that (SCM-managed) dir changes.
>
> I'm trying to put together our plan for an ant1.7-only build process,
> and am working out how best to manage lib a
> 2. if you use antlib://org/ex/resource.xml we load in the resource by its
> full path, so you dont need multiple packages to have multiple antlib files.
> I'm not sure about #2; I think it is convenient once you have antlib-only
> distros (i.e. inline declaration and script; nothing else), bu
> 1- So is the antlib for svn available?
Yep. In Ant's SVN of course.
> 2- does it work independently of a native command installed?
No. It's a simple wrapper around the command line client Stefan wrote.
There's a pure Java library for SVN that SmartSVN and IntelliJ I think
use. Someone may have
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> I dont actually want packages, see. Instead I want a directory that you
> can -lib to that pulls in all the various project-independent
> declarations.
>
> Then I can run ant
>
> ant -lib /projects/smartfrog/antbuild/core
>
> And get everything
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> One change I have also checked in to Definer.java is some extra logic
> for naming antlibs. Instead of just
>
> antlib:org.example.package
>
> you can go
>
> antlib://org/example/package/file.xml
>
> and have that file's declaration
> -Original Message-
> From: koden (sent by Nabble.com) [mailto:[EMAIL PROTECTED]
>
> I encountered a strange problem.
>
> In ANT 1.6.5 the following code works:
> That works well in 1.6.5, but in 1.5.1 it gives me the error of "Unable to
> delete file: fail_log.txt"
>
> I can't figure o
I agree with your analysis. Your enhanced PropertyFile task doesn't
fit the filterchain framework, although as Antoine rightly writes,
many other things do fit it and should be implemented or retrofitted
into that framework.
Regarding your submission per se, it really depends on how you coded
it.
> Let's do this Saturday, 3rd Sept, 20:00 EST.
Any last minute change of plans? Let us know how this goes, and thanks
of lot for doing this for us Henri. Good luck, --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
See bottom of http://www.apache.org/licenses/ and
http://www.apache.org/licenses/software-grant.txt. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I just spent some time editing
http://wiki.apache.org/ant/AntExternalTaskdefs, I hit preview, and get
a 404! I do back, and sure enough I've lost my edits. Is that normal /
common? Because if it is, I won't loose time trying to edit this
thing. --DD
On 9/9/05, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > So, any ideas how this could be acomplished?
> Load all resources from META-INF/antlib.xml at startup and process
> them, I'd say.
But doesn't that go against Ant's tradition to not have auto-magic
things, but instead spell things out explic
On 9/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> "Jose Alberto Fernandez" <[EMAIL PROTECTED]> wrote ..
> > I do not see why we need to support this kind of thing.
> > NO-one asks the javac compiler to be able to compile code inside your
> > Word document. If you have ANT inside some other
I personnally switched from Xalan to Saxon... Just put the Saxon jar
first on the classpath and it will be used instead of the default XSL
engine. Saxon's really good and it implements XSL 2.0, which is a
marked improvement over XSL 1.0 (makes things simpler very often).
--DD
-
On 10/13/05, Peter Reilly <[EMAIL PROTECTED]> wrote:
> At one stage, the import task behaved as if
> it was added at the end of the build file. This was an
> unexpected consequence (bug!) of the initial implementation.
> This was changed (I think) in 1.6.1 or 1.6.2, so that the import behaved
> as
> Have you ever changed the value of a Property, re-run the build, but did
> not get the result you wanted?
Yep!
> Did you wonder if the property setting got ignored (ignored override),
> or if something else was wrong?
Yep again!
> I find myself in these situations when working on a large (sev
On 11/9/05, Craeg Strong <[EMAIL PROTECTED]> wrote:
> Cool! Continuing this thought experiment, what about enhancing
> BuildListener like so:
Changing an interface is a no-no of course.
> The issue with these events is the same one you normally have with
> exceptions.
I can't comment on your ap
On 11/9/05, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Does that work for you?
It does. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> Stefan Bodewig wrote:
1) Shall the *antunit* antlib be promoted? +1
1.a ) become commiter? +1
2) Shall the *svn* antlib be promoted? +1
2.a ) become commiter? +1
3) Shall the *.NET* antlib be promoted? +1
3.a ) become commiter? +0
Thanks, --DD
> I would like to propose Kevin Jackson as an Ant committer. Kevin has
> submitted a lot of useful patches.
+1. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I can't get the log for AntClassLoader (for some reason), but the file
dates from the 10th of this month.
Don't we have a Gump run on JDK 1.2.2?
Not sure how to resolve this. --DD
D:\org_apache\svn\core\trunk>bootstrap
... Bootstrapping Ant Distribution
JAVA_HOME=C:\pro\java\jdk1.2.2
JAVA=C:\pr
On 11/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Modified:
>ant/core/trunk/docs/contributors.html
>ant/core/trunk/xdocs/contributors.xml
> Stefan Bodewig (stefan.bodewig at freenet.de -
> - href="http://stefan.samaflost.de/";>http://stefan.samaflost.de/>
t; --- Ursprüngliche Nachricht ---
> > Von: Dominique Devienne <[EMAIL PROTECTED]>
> > Not sure how to resolve this. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> +++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadResource.java
> +if (!src.isExists()) {
> +throw new BuildException(src + " doesn't exist");
> +}
Does isExists() sound strange to me only? java.io.File uses just
exists(), so couldn't we just use the same
> > +if (!src.isExists()) {
>
> Does isExists() sound strange to me only? java.io.File uses just
> exists(), so couldn't we just use the same name for Resource? Thanks,
Didn't realize Resource was introduced a while back. Too late to
change, and not worth deprecating over a new exits() met
> > [delete] DEPRECATED - Use of the implicit FileSet is deprecated
>
> I was pretty surprised about this BTW [...]
This warning has been in place for while now I'd think.
I was using 1.6.2 and getting it.
> This breaks way too many builds.
It's just a warning; It doesn't break anything real
On 11/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> It would fit better into Ant´s future if the existing would
> support - e.g. s.
We've had this debate before...
I'd be all for allowing to resources instead of files, except
for the way was designed to not do things relative to its
p
> You could just do this:
> http://${myhost}/commons.xml";
> dest="${user.home}/.ant/commons.xml"
> usetimestamp="true"/>
>
That's the first level of import I describe. But if common.xml refers
(imports) to misc.xml also located at http://${myhost}/, but you must
also it explicit
> The current file attribute of the import task is meant to act
> in the same way as href in html- - i.e relative to the
> directory that the importer file is in.
>
> THe import task could easily use urls in the same way - but
> some internals in ant assume that build files are Files and
> only Fil
> A URL has no concept of a 'parent'.
I beg to disagree. If it didn't, the web wouldn't work ;-)
Here's the proof, in this URL contructor: URL(URL context, String spec). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
> Now how do I get the parent? You can parse the path manually, but a URL can
> be a jar resource, HTTP address, file location, newsgroup, partial url, etc.
>
> http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url-primer.html
>
> Rather than parsing the path, it's easier and more explicit to s
> > D:\org_apache>java MakeUrl http://foo/common.xml misc.xml
> > http://foo/misc.xml
> Yes, this works as long as the first file you reference is at the root
> level. This can be confusing in scripts since the root is dictated by that
> first import and not made explicit. Sometimes I want to impor
> We could add some macro task that copies the resources into a cache directory
> and then applies the from there.
>
> What this would mean is that all the "relative" stuff will be relative to the
> cache location. Something like:
>
>
>
>
>
> The macro will use to put it in the cache and th
> Just out of curiosity, how many people other than
> Peter and myself have ever started to modify
> to allow non-file imports? :)
I haven't ;-)
The two issues I faced when creating large multi-build files builds were:
1) Easily refer to the files to import arbitrarily deep in the file hierarch
> Propchange:
> ant/core/trunk/src/main/org/apache/tools/ant/types/resources/JavaResource.java
> --
>svn:eol-style = native
>
> Propchange:
> ant/core/trunk/src/main/org/apache/tools/ant/types/resources/JavaResource.j
> I believe that 'hierarchy' is a feature of protocols within a URL, which
> ftp, http, jar, file: support, but things like urn: uuid: that handle
> system thing, they dont.
I don't believe the JDK and the URL class support these other
protocols out-of-the-box either ;-) The RFC mentioned in the J
> ManifestClassPath should encode the classpaths like URIs.
> The jar spec from Sun says that classpath elements in Manifests are
> relative URLs.
> Non Ascii chars must be % encoded.
> We would need to extract from FileUtils.toURI() the bit of code which does
> the encoding so that we can encode a
> which also likely means the class has cariage returns in it and svn
> thinks it's a binary. Fixed.
Thanks! --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 11/30/05, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > ManifestClassPath should encode the classpaths like URIs.
> > The jar spec from Sun says that classpath elements in Manifests are
> > relative URLs.
> > Non Ascii chars must be % encoded.
>
> >Modified: ant/core/trunk/CONTRIBUTORS
> >URL:
> >http://svn.apache.org/viewcvs/ant/core/trunk/CONTRIBUTORS?rev=354209&r1=354208&r2=354209&view=diff
> >==
> >Binary files - no diff available.
> >
> >
> >
> Does anybody k
> I conclude that you can only use the "fully qualified" target naming
> scheme to when distinguishing ambiguity is required. Does anyone else
> think this is a bug? Thanks in advance.
Right. You can only use .target when the importer
'overrides' the target in question. Others have complained a
> I've had a look through the sandbox and I noticed Dominique's (sp?) xml'd
> version of the docs.
what does (sp?) means in this context?
> As you know I had a play with DocBook-izing the manual last year and in
> the end the effort of manually altering every html page to be valid
> DocBook xml d
> > Yes, I thought that would be the way to go as well down the line,
> > parsing the HTML with tagsoup [...]
>
> when I say script here I'm talking about a ruby script (partially as I
> saw this as being a converter for the manual for a limited amount of
> time, not immediate throwaway, but not a
On 1/24/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jan 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> > Will somebody teach me how to generate the site? :(
>
> ant -f docs.xml
>
> Unfortunately it is not that easy to get the required libs for Anakia
> in place. I have a checked o
On 3/17/06, Curt Arnold <[EMAIL PROTECTED]> wrote:
> I'm doing my annual cpptasks (http://ant-contrib.sourceforge.net)
> cleaning and expect to be producing long overdue release shortly and
> hopefully additional releases at more reasonable intervals. The
> current cpptasks build uses tools from t
> Specifically, it appears to be defaulting to source=1.5
> [...]
> I checked out the source in CVS; they are not saying source="1.5"; they
> are not saying anything about the source version. Yet javac has switched
> to java1.5. This is breaking backwards compatibility for builds.
It was always my
> The junit4 class doesn't know or care if there is a 'static Test suite()'
> method on the class. It looks for Annotations, and then falls back on
> pattern matching method names. It seems that the suite() method has always
> been an Ant thing.
I beg to differ. Honoring suite() methods has been
> Now, when 's dependency logic broke moving up to 1.5, I fixed it
> by forcing the proxy generation to be downwards compatible, so
> everything behaved as on a 1.3 or 1.4 box.
True, and was probably the right choice. But there are fewer
users than users, so impacts less people.
> Here are some
> if we the properties ant._internal._javac.source and
> ant._internal._javac.target that set the defaults for javac, then you
> can also use them on the command line to build anything 'legacy',
> without touching the build file.
Even though someone could abuse these "Magic" properties for other
p
> ok, I think the consensus is that I shouldn't have committed this
> change ie -1 to this change from while -> for.
I'm also a proponent of using for loops rather than while loops for
Iterators. I picked up the idiom reading "The Java Programming
Language", and I like the added scope it provides,
+1. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
+1. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> The point about building the strings when they aren't used (because
> logging verbosity is set too low) still stands though - this is less
> than efficient
The point, which Matt already raised, is that you can't know the level
at which the logger and the listeners are set. There is nothing ATM i
> My dream :
>
>
No! It was my dream first and you can't have it! :) I
agree wholeheartedly. IIRC myself, Stefan, and
probably others took part in a discussion of this
nature some time ago... though I'm too frustrated by
my slow home internet connection to find the thread
ATM. Maybe we can ge
On 4/26/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
The cleanup means concretely removing:
org.apache.tools.ant.taskdefs.optional.sitraka
org.apache.tools.ant.taskdefs.optiona.metamata
packages, with the corresponding documentation and testcases.
+1. --DD
--
Yes, this is by design, counter-intuitive as it may seem ;-)
With no include patterns, the filesets selects *all* files under the
given directory, i.e. any file (isDirectory() == false) or directory
(isDirectory() == true), and then trims this list using the exclude
patterns.
In your first examp
uzzled that you mention that your empty dirs seem selected
by looking at the debug output, yet are not deleted. --DD
On 5/8/06, Liz Burke-Scovill <[EMAIL PROTECTED]> wrote:
On 5/8/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> In your first example, your empty dirs are imp
OK, now I'm pretty confident everything's working as expected.
Desired outcome:
files test/something.ini, test/test1/test2/another.ini deleted
dirs test3 and test2 deleted as both are now empty.
test3 *would* be deleted if you included it somehow. One way would be
to have an file selector, wh
That's a good solution Matt. Gets rid of test3.
FTR, I'm a strong proponent of generating all build output into a
single dir (I use the build/ dir myself), and never anywhere in the
source tree or any dir under SCM, so I never have to pick and choose
what to delete and
might work as expected in HEAD. I did some things in
there specifically to sort directories such that
children would be encountered before their parents
IIRC. And I seem to remember thinking that something
related to this would delete more than the current release.
Hmm, that would be breaking
Still the overall problem I have with customizing Ant is the over-usage of
"private". It also bites at other places, ComponentHelper is just an example.
On the contrary, it's a Good Thing (TM)
Ant's purpose is as a build tools, not a Java library. Keeping its
internals private allows future re
However, it is possible to isolate Ant
idiosyncrasies as an implementation concern providing one can establish a
viable project model.
I've long thought Ant needed a more rigorous model exposed to Java
clients and extension builders. However, I don't think what I had in
mind was quite as ambitio
Who knows ;-) Let's just say that my laptop is now Java+SVN+Ant
ready, unlike an hour ago. --DD
On 5/26/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
Cool,
are you going to work on it further DD ?
Regards,
Antoine
> Original-Nachricht
> Datum: Fri, 26 May 2006 20:48:1
We simply can't. Leaving the generics/erasure problem aside, there is
a way to ensure you don't compile against methods that are too new,
but it is painful: start building with JDK 1.2, compile what hasn't
been compiled by building with JDK 1.3, repeat with JDK 1.4 and 1.5.
What about "cross-co
There is one big change here; a failing antunit test does now actually
halt the build. the other one matters less, as it makes the
expectedMessage string in a substring search on the
failure message, not a complete match. this is useful if part of the
message varies depending upon the target plat
Is your motivation being able to have conditionals in disguise, i.e.
be able to write
? Otherwise I can't see the use for this. Just curious ;-) Thanks, --DD
On 6/6/06, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
Hi,
I wonder how to implement a task (in Java) allowing me to execute
a ma
701 - 800 of 930 matches
Mail list logo
