RE: project dependencies
Ted, in what way? You can create a main build.xml that does, for example: ... which will ensure that the third party distribution is created before attempting to create the project distribution. This is less than ideal as there is no true dependency between the two. However, it is also possible to use import to pull all the targets into the main build.xml directly. You then have to ensure that you provide targets in the build.xml that will define or correct the inter-script target inter-dependencies. E.g. if the two scripts both have "dist" targets and you want to simulate the project.xml dist depending on the third-party.xml dist target you would do something like: third-party.xml: ... project.xml: ... build.xml: The benefit here over the "ant" task version is that if there are common targets they can be "merged" together (much as has been done here with "dist") and Ant will ensure that those targets are only invoked once in the dependency sequence (instead of the twice that would occur using the "ant" task version). BTW, no guarantees the attributes are correctly named in this example! As I said, this is a user list thing. If you want more help or examples re-post on the user list. Phil -Original Message- From: Ted Yu [mailto:[EMAIL PROTECTED] Sent: Thu 1/19/2006 23:14 To: Ant Developers List Cc: Subject: Re: project dependencies Thanks Phil. But can I specify their dependency ? --- Phil Weighill Smith <[EMAIL PROTECTED]> wrote: > Ted, this is something that should be addressed to > the user list, not > the developer list. However, short answer: no. But > remember that you can > call the ant build script anything you like. You > could have a main > "build.xml" that invokes targets in or imports (as > appropriate) the two > other build scripts, e.g. project.xml and > third-party.xml. > > Phil :n) > > On Thu, 2006-01-19 at 11:19 -0800, Ted Yu wrote: > > Hi, > > Am I able to specify two projects in one build.xml > > file such that one depends on the other ? > > The reason is that I want to move thirdparty to > same > > level as the other project source tree. > > > > Thanks > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.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] > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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]
Re: project dependencies
Ted, this is something that should be addressed to the user list, not the developer list. However, short answer: no. But remember that you can call the ant build script anything you like. You could have a main "build.xml" that invokes targets in or imports (as appropriate) the two other build scripts, e.g. project.xml and third-party.xml. Phil :n) On Thu, 2006-01-19 at 11:19 -0800, Ted Yu wrote: > Hi, > Am I able to specify two projects in one build.xml > file such that one depends on the other ? > The reason is that I want to move thirdparty to same > level as the other project source tree. > > Thanks > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.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]
RE: fails if inner fileset directory does not exist.
Fair point though I would suggest a fileset that generates no matches (e.g. a
typo in the includes or selector) might warrant this "error" behaviour to aid
debugging in that case to be consistently "helpful".
-Original Message-
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED]
Sent: Tue 10/25/2005 16:49
To: Ant Developers List
Cc:
Subject: Re: fails if inner fileset directory does not exist.
The current behaviour is useful, because it helps find build script
problems
easier. Otherwise a simple typo would be hidden and it will be a painful
manual process to see why a build script does not do what it is
supposed to
do.
- Alexey.
On 10/25/05, Phil Weighill-Smith <[EMAIL PROTECTED]> wrote:
>
> I simply wonder if backwards compatibility is actually necessary here
as a
> missing fileset base directory causes a build failure and I'd have
thought
> that most builds would not depend on this sort of scenario. Clearly
there
> could be some (IMHO) strange build scripts that do rely on this
behaviour,
> but this seems very obscure (correct me if you can think of a common
use
> case).
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tue 10/25/2005 09:00
> To: dev@ant.apache.org
> Cc:
> Subject: AW: fails if inner fileset directory does not exist.
>
>
>
> With the ability to configure that, we´d get a
> (default=true --> BWC)
>
> Users could override the default with .
>
>
>
> Jan
>
> >-Ursprüngliche Nachricht-
> >Von: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> >Gesendet: Dienstag, 25. Oktober 2005 09:45
> >An: Ant Developers List
> >Betreff: RE: fails if inner fileset directory does not
exist.
> >
> >My point is more about filesets in general rather than within
> >delete specifically. I'd have thought that since old behaviour
> >is unlikely to be relied on in build files (the implication is
> >that something outside the build script *must* create certain
> >directories otherwise the build fails) changing the behaviour
> >to simply not cause an exception in the directory scanner but
> >rather do a "zero matches" result would suffice.
> >
> >Phil :n.
> >
> > -Original Message-
> > From: Alexey Solofnenko [mailto:[EMAIL PROTECTED]
> > Sent: Mon 10/24/2005 22:42
> > To: Ant Developers List
> > Cc:
> > Subject: Re: fails if inner fileset directory
> >does not exist.
> >
> >
> >
> > I think it would be require something like the following:
> >
> > - flag in ;
> > - lazy initialization, so can set
> >this flag;
> > - should always set this flag on all
> >provided filesets.
> >
> > - Alexey.
> >
> > On 10/24/05, Phil Weighill-Smith
> ><[EMAIL PROTECTED]> wrote:
> > >
> > > Which has always given me grief. It has always seemed
> >sensible to me that
> > > a fileset would simply evaluate to no files if the
> >base directory for the
> > > fileset doesn't exist (and perhaps generate a verbose
> >log mentioning that
> > > fact) in the same way it does when the pattern(s)
> >doesn't match anything.
> > >
> > > Phil :n(
> > >
> > > -Original Message-
> > > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > > Sent: Mon 10/24/2005 21:15
> > > To: Ant Developers List
> > > Cc:
> > > Subject: Re: fails if inner fileset
> >directory does not exist.
> > >
> > >
> > >
> > > Nothing ever works w/ filesets where the directory
> > > does not exist...
> > >
> > > -Matt
RE: fails if inner fileset directory does not exist.
I simply wonder if backwards compatibility is actually necessary here as a
missing fileset base directory causes a build failure and I'd have thought that
most builds would not depend on this sort of scenario. Clearly there could be
some (IMHO) strange build scripts that do rely on this behaviour, but this
seems very obscure (correct me if you can think of a common use case).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tue 10/25/2005 09:00
To: dev@ant.apache.org
Cc:
Subject: AW: fails if inner fileset directory does not exist.
With the ability to configure that, we´d get a
(default=true --> BWC)
Users could override the default with .
Jan
>-Ursprüngliche Nachricht-
>Von: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>Gesendet: Dienstag, 25. Oktober 2005 09:45
>An: Ant Developers List
>Betreff: RE: fails if inner fileset directory does not exist.
>
>My point is more about filesets in general rather than within
>delete specifically. I'd have thought that since old behaviour
>is unlikely to be relied on in build files (the implication is
>that something outside the build script *must* create certain
>directories otherwise the build fails) changing the behaviour
>to simply not cause an exception in the directory scanner but
>rather do a "zero matches" result would suffice.
>
>Phil :n.
>
> -Original Message-
> From: Alexey Solofnenko [mailto:[EMAIL PROTECTED]
> Sent: Mon 10/24/2005 22:42
> To: Ant Developers List
> Cc:
> Subject: Re: fails if inner fileset directory
>does not exist.
>
>
>
> I think it would be require something like the following:
>
> - flag in ;
> - lazy initialization, so can set
>this flag;
> - should always set this flag on all
>provided filesets.
>
> - Alexey.
>
> On 10/24/05, Phil Weighill-Smith
><[EMAIL PROTECTED]> wrote:
> >
> > Which has always given me grief. It has always seemed
>sensible to me that
> > a fileset would simply evaluate to no files if the
>base directory for the
> > fileset doesn't exist (and perhaps generate a verbose
>log mentioning that
> > fact) in the same way it does when the pattern(s)
>doesn't match anything.
> >
> > Phil :n(
> >
> > -Original Message-
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > Sent: Mon 10/24/2005 21:15
> > To: Ant Developers List
> > Cc:
> > Subject: Re: fails if inner fileset
>directory does not exist.
> >
> >
> >
> > Nothing ever works w/ filesets where the directory
> > does not exist...
> >
> > -Matt
> >
> > --- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > This does not work:
> > >
> > >
> > >
> > >> > failonerror="false">
> > >
> > >
> > >
> > >
> > >
> > >
> > > - Alexey.
> > > --
> > >
> >
>---
>-
> > > / Alexey N. Solofnenko
> > > home: http://trelony.cjb.net/
> > > /
> > >
> > >
> >
>-
> > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > For additional commands, e-mai
RE: fails if inner fileset directory does not exist.
My point is more about filesets in general rather than within delete
specifically. I'd have thought that since old behaviour is unlikely to be
relied on in build files (the implication is that something outside the build
script *must* create certain directories otherwise the build fails) changing
the behaviour to simply not cause an exception in the directory scanner but
rather do a "zero matches" result would suffice.
Phil :n.
-Original Message-
From: Alexey Solofnenko [mailto:[EMAIL PROTECTED]
Sent: Mon 10/24/2005 22:42
To: Ant Developers List
Cc:
Subject: Re: fails if inner fileset directory does not exist.
I think it would be require something like the following:
- flag in ;
- lazy initialization, so can set this flag;
- should always set this flag on all provided filesets.
- Alexey.
On 10/24/05, Phil Weighill-Smith <[EMAIL PROTECTED]> wrote:
>
> Which has always given me grief. It has always seemed sensible to me
that
> a fileset would simply evaluate to no files if the base directory for
the
> fileset doesn't exist (and perhaps generate a verbose log mentioning
that
> fact) in the same way it does when the pattern(s) doesn't match
anything.
>
> Phil :n(
>
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: Mon 10/24/2005 21:15
> To: Ant Developers List
> Cc:
> Subject: Re: fails if inner fileset directory does not exist.
>
>
>
> Nothing ever works w/ filesets where the directory
> does not exist...
>
> -Matt
>
> --- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
> wrote:
>
> > This does not work:
> >
> >
> >
> > > failonerror="false">
> >
> >
> >
> >
> >
> >
> > - Alexey.
> > --
> >
>
> > / Alexey N. Solofnenko
> > home: http://trelony.cjb.net/
> > /
> >
> >
> -
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
>
> __
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
--
Alexey N. Solofnenko trelony at gmail.com <http://gmail.com>
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: fails if inner fileset directory does not exist.
Which has always given me grief. It has always seemed sensible to me that a fileset would simply evaluate to no files if the base directory for the fileset doesn't exist (and perhaps generate a verbose log mentioning that fact) in the same way it does when the pattern(s) doesn't match anything. Phil :n( -Original Message- From: Matt Benson [mailto:[EMAIL PROTECTED] Sent: Mon 10/24/2005 21:15 To: Ant Developers List Cc: Subject: Re: fails if inner fileset directory does not exist. Nothing ever works w/ filesets where the directory does not exist... -Matt --- "Alexey N. Solofnenko" <[EMAIL PROTECTED]> wrote: > This does not work: > > > > failonerror="false"> > > > > > > > - Alexey. > -- > > / Alexey N. Solofnenko > home: http://trelony.cjb.net/ > / > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: suggestion refactor SCM
I would suggest having a separate (external) "typedef" (or whatever the appropriate Ant concept would be): ... Referencing this value by ID would allow programmatic and build script level references to be made to such a repository without the need to know the exact details of that repository implementation. E.g. could commit against SubVersion since "xyz" has been mapped to an svn repository implementation. Following Ant's norms, the scm:commit task could also have an embedded repository definition instead and therefore not require the refrepository attribute, or even have a nested repository element with a refid attribute etc. Phil :n. On Tue, 2005-09-27 at 10:50 +0100, Jose Alberto Fernandez wrote: > I think that it will be a very good idea, mostly as a stepping stone to > higher level functionality. > > The main reason for not having such a thing is the fact that each > project knows in advance what kind of repository is being in used. So > why do we need something abstract? > > On the other hand, once you have such an abstracted functionality, I am > sure we could envision higher level tasks stored on other antlibs that > may provide project management style functionality irrespective of the > underlying repository. That would be a very good thing to have. > > So I am all for it. The question is what are the concepts that can be > ported across all different SCMs? > > As per syntax, I would much prefer something like: > > > > Now, can this be done in such a way as to figure out by itself what is > the underlying repository is. That would limit the need for magic stuff. > > Jose Alberto > > > -Original Message- > > From: Kev Jackson [mailto:[EMAIL PROTECTED] > > Sent: 27 September 2005 07:34 > > To: Ant Developers List > > Subject: suggestion refactor SCM > > > > Hi > > > > I've been playing with darcs recently and I've almost finished an > antlib > > for it (though I keep being distracted, first Haskell, now Lisp). > > > > 'darcs get' is roughly similar to 'cvs checkout' or 'svn co' > > > > I was wondering if it would make sense to refactor the SCM tasks into > an > > interface (scm) and have a set of antlibs that implement that > interface > > in a vendor specific manner. Such that > > > > > > > > is handled appropriately by each SCM system in it's own way, whilst at > > the same time exposing a common API to simplify this (very common) set > > of tasks. I'm thinking it'd be similar to how the task > > simplifies compiling regardless of which compiler you want to use. > > > > Is this: > > a - a stupid idea and a colossal waste of time > > b - a not too stupid idea, but still a colossal waste of time > > c - not stupid, a colossal waste of time, but it'd be worth doing > anyway > > d - none of the above > > > > Kev > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ant Wiki] Update of "AntDTD" by RonKuris
On the understanding this is a "work in progress", I'd like to point out
that a project can now contain pretty much anything (if not everything)
that a target can (essentially creating an unnamed target that all other
targets in the file depend on implicitly) making the "project" element
definition completely wrong ;n)
Phil
On Thu, 2005-09-15 at 16:48 +, Apache Wiki wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Ant Wiki" for change
> notification.
>
> The following page has been changed by RonKuris:
> http://wiki.apache.org/ant/AntDTD
>
> New page:
> Although there is no official DTD for Ant, here's a work-in-progress, based
> on the work from Michel Casabiana, with some modifications for Ant 1.6.
> {{{
>
>
>
>
>
>
>
>
> %ext-file;
>
> patternset)*)>
>nameCDATA #IMPLIED
> default CDATA #IMPLIED
> basedir CDATA #IMPLIED>
>
>
>
>
> id ID #IMPLIED>
>
>
> path CDATA #IMPLIED>
>
>
> location CDATA #IMPLIED
> path CDATA #IMPLIED>
>
>
> dir CDATA #IMPLIED
> file CDATA #IMPLIED
> defaultexcludes ( yes | no ) "yes"
> includes CDATA #IMPLIED
> includesfile CDATA #IMPLIED
> excludes CDATA #IMPLIED
> excludesfile CDATA #IMPLIED
> casesensitive ( yes | no ) "yes"
> followsymlinks ( yes | no ) "yes">
>
>
> dir CDATA #REQUIRED
> includes CDATA #IMPLIED
> includesfile CDATA #IMPLIED
> excludes CDATA #IMPLIED
> excludesfile CDATA #IMPLIED
> casesensitive ( yes | no ) "yes"
> followsymlinks ( yes | no ) "yes">
>
>
> id ID #IMPLIED
> refid NMTOKEN #IMPLIED
> includes CDATA #IMPLIED
> includesfile CDATA #IMPLIED
> excludes CDATA #IMPLIED
> excludesfile CDATA #IMPLIED>
>
>
> name CDATA #REQUIRED
> if CDATA #IMPLIED
> unless CDATA #IMPLIED>
>
>
> name CDATA #REQUIRED
> if CDATA #IMPLIED
> unless CDATA #IMPLIED>
>
>
> name CDATA #REQUIRED
> if CDATA #IMPLIED
> unless CDATA #IMPLIED>
>
>
> name CDATA #REQUIRED
> if CDATA #IMPLIED
> unless CDATA #IMPLIED>
>
>cvs | delete | deltree | echo | exec | expand |
> filter | get | gzip | fixcrlf | jar | java |
> javac | javadoc | javadoc2 | keysubst | mkdir |
> property | rename | replace | rmic | tar |
> taskdef | tstamp | zip %ext;)*>
>nameCDATA #REQUIRED
> depends CDATA #IMPLIED
> if CDATA #IMPLIED
> unless CDATA #IMPLIED
> description CDATA #IMPLIED>
>
>
>name CDATA #REQUIRED
> valueCDATA #IMPLIED
> location CDATA #IMPLIED
> resource CDATA #IMPLIED
> file CDATA #IMPLIED>
>
>
>antfile CDATA #IMPLIED
> dir CDATA #IMPLIED
> targetCDATA #IMPLIED
> outputCDATA #IMPLIED
> inheritAll( true | false ) "true"
> inheritRefs ( true | false ) "false">
>
>
>refid CDATA #REQUIRED
> torefid CDATA #IMPLIED>
>
>
>property CDATA #REQUIRED
> value CDATA #IMPLIED
> classname CDATA #IMPLIED
> file CDATA #IMPLIED
> resource CDATA #IMPLIED
> classpath CDATA #IMPLIED
> filepath CDATA #IMPLIED
> classpathref CDATA #IMPLIED
> type ( dir | file ) #IMPLIED
> ignoresystemclasses ( true | false ) "false">
>
>
>src CDATA #REQUIRED
> perm CDATA #REQUIRED>
>
>
>file CDATA #IMPLIED
> preservelastmodified ( yes | no ) "no"
> tofileCDATA #IMPLIED
> todir CDATA #IMPLIED
> overwrite ( yes | no ) "no"
> filtering ( yes | no | off | on ) "no"
> flatten ( yes | no ) "no"
> includeEmptyDirs ( yes | no ) "yes"
> failonerror ( yes | no ) "yes"
> verbose ( yes | no ) "no"
> encoding CDATA #IMPLIED
> outputencodingCDATA #IMPLIED
> enamblemultiplemappings ( yes | no ) "no"
> granularity CDATA #IMPLIED>
>
>
>src CDATA #REQUIRED
> destCDATA #REQUIRED
> ignore CDATA #IMPLIED
> includesCDATA #IMPLIED
> excludesCDATA #IMPLIED
> defaultexcludes CDATA #IMPLIED
> filtering CDATA #IMPLIED>
>
Re: task namespaces
Jim, What you've said sounds wrong to me; and are in the "default namespace" (a declared namespace that has no prefix), whatever that has been defined to be. This could be the same as n1 if the URI for n1 is also associated with the default namespace, but that seems unlikely. Phil :n. On Mon, 2005-09-12 at 06:09 -0400, [EMAIL PROTECTED] wrote: > Steve Loughran <[EMAIL PROTECTED]> wrote .. > > > > > > > > I know separate namespace work is optional, but once you start on it it, > > it is more manageable. For this reason, the next edition of > > java-dev-with-ant will use namespaces everywhere too, except for the > > bits where I dont understand what is going on. Actually, I am slowly > > building up model. Nested stuff is the troublespot > > > > -declare task in namespace n1: > > -declare type extends Condition in namespace n1: > > > > If mytask has a nested element , and it also supports multiple > > nested conditions, is this how it looks > > > > > > this action is a direct element; default NS or local > > ns? > > > > this is my new test, in the new ns > > > > > > What confuses me here is that the ns of a nested element (not a type, an > > element) is what? local? or Ant's main ns? > > this is an old XML NS chestnut. > > http://www.rpbourret.com/xml/NamespacesFAQ.htm > > is the authoratative place to go to understand the permathreads. > > specifically > > http://www.rpbourret.com/xml/NamespacesFAQ.htm#s6 > > discusses scope. > > 'An XML namespace declaration remains in scope for the element on which it is > declared and all of its descendants, unless it is overridden or undeclared on > one of those descendants' > > so and are in the n1: namespace. > > hth, Jim Fuller > > > - > 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: starting and killing background exec or java task
Would be handy. I'm assuming that the "name" could create a property of that name, set to the process ID for example. You can then just "kill" that process using this ID... Phil :n. On Fri, 2005-08-12 at 15:38 +0100, Steve Loughran wrote: > I'm just reviewing what major changes I am needing to do to my (big) > work project to simplify stuff. One troublespot is running functional > tests against a running system, I need to (maybe) start a program, run > tests against it and then stop the program if I started it (but not if > it was already running under a debugger or something). what we have > today is nasty and brittle. > > I have to start something in parallel, wait by polling a port for a > signal that it is running, then run the tests, finally shut it down if > we started it (broken). > > depends="parse,dist,compile-tests,init-codebase" > description="run system tests" > if="system.tests.enabled"> > > > > > > > > > > > > > No daemon > errorProperty="test.failed" >failureProperty="test.failed" >> > > > > > > > > > > > > > > > name="org/smartfrog/services/junit/test/*Test.class"/> > > > > > > > > > > > > > Life would be simpler if I could exec something in the background. Not > spawned, which is designed to outlive ant, just in the background. > stopping ant would stop background stuff. output would still go to the > logger. > > I would also like to be able to kill a background process by name, a > name I assigned it earlier. My testing would then be > > > > > > > > Nice and simple to use. To implement? I dont know, yet. > > What do people think? > > -steve > > > - > 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: Java Development with Ant
You may well have already included this sort of thing, but I'd cover (not really esoteric): * Immutability and overriding of properties (an often mis- understood aspect) * Conditional targets * Usage of id/refid * Multiple source tree support (e.g. for production and test code) * Sub-builds (e.g. via subant and ant tasks) * Test execution and reporting * PropertySet * FilterChains and FilterReaders * Selectors * File Mappers (perhaps with multiple mappings) * Availability of third-party extensions (tasks, such as Ant Contrib) Phil :n) On Tue, 2005-07-26 at 09:52 +0700, Kev Jackson wrote: > Hi all, > > I'm preparing a talk for the developers here in Vietnam about how to use > Ant to build software (mainly Java, but you know there's the .net tasks > too). I have the main body of the presentation completed, but I wanted > to include some of the more esoteric things you can do with Ant (not the > videogame!). I noticed on the Manning web-site that Steve mentioned > that he has slides available showing imports, macrodefs etc, these would > be incerdibly hadny if he still has them (nudge, nudge, wink, wink). > > I cover: > - Ant versus Make > - Ant instead of IDE compilation > - Continuous Integration (CruiseControl) > - Common tasks (clean, compile, jar etc) > - Server-side stuff (ftp, deploy etc) > > Anything else I should include for first-timers? My aim is to help the > developers realise that although it is possible to work as a team with > each person compiling in their own ide, that Ant simplifies things and > allows them to re-use the build script on other projects etc. I've got > another talk on unit testing coming up (I've been here nearly 10 months > and I've only seen 1 unit test and there was nothing tested in it). > Needless to say, the working practices are similar to what I'd expect in > the 80's (SourceSafe as version control, everyone locks files, Waterfall > as the process, massive investment in design up front, testing is done > by teams of bored people etc etc). > > Kev > > - > 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: javac
Why not simply put two calls to javac in your build script and split the source tree in two in the same way that you have in your new task, passing one tree to the first call and the other to the second? Clearly you need to ensure that the first call compiles "pre-requisite" code for the second call and that you should avoid cyclic references between the two sets of classes. Phil :n. PS: I would consider re-structuring the application into "subsystems" with separate source trees and separate build scripts per subsystem. Dependencies between subsystems only on the class files (not the source files). This is the approach we have taken to great effect. On Tue, 2005-07-12 at 00:12 -0700, Jean Lazarou wrote: > We had problem with a (legacy) build from scratch, seems that, because we > have too many java files to compile, nothing is compiled (both on Linux and > Windows2000). > > After spending 4 days on that, I decided to split the compilation, I created > a new task, name "bydir-javac". The task is derived from Javac. > > Can I publish this? Is it a better way of doing it? > > Jean Lazarou > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XJ - xml extension for Java
On Mon, 2005-07-04 at 12:56 +0100, Steve Loughran wrote: > Xpath is profound once you apply to > object trees Interestingly, and orthogonal to the initial discussion, JXPath has been able to apply XPaths to object trees for quite some time. (Clearly XJ is something else again and definitely interesting for a number of reasons including the XPath processing within the "language".) Phil :n) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
"Local" properties
I was thinking about "local" properties, having read the discussions relating to these in the last few months. Perhaps we could introduce the concept of "property scopes" instead. The project would provide a standard "global" property scope by default. It would also provide the ability to push and pop new property scopes (i.e. manage a stack of scopes). When a property is defined it goes into the current property scope (unless specifically allowed to be set in the "global" scope; see my export concept below for an example). When looking up a property, the property is looked for in widening scope (i.e. from top to bottom of the scope stack) until it is found or we have traversed the stack of property scopes all the way up to the "global" scope and found nothing. We could then provide any or all of: * "" and "" tasks (not my favorite idea as these can be unbalanced, I prefer the following). * a "createPropertyScope" attribute on target and/or "sequential" and "parallel" tasks or a special "" task based on "sequential" * allow scopes to be automatically managed in macrodefs to avoid the need for special syntax for macro parameters (they can be properties in a new scope). * an "" task to promote a named property up one scope or into the global scope as required (understanding that export will not modify any existing property with the same name in the target scope; it might also be possible to provide a means of this exporting properties from a sub-ant execution to the calling ant execution...?). An alternative is to name scopes and allow export to promote a property to the named scope, with "default" or "global" being the name of the "global" (initial) scope. All existing behaviour (and therefore BC) can be retained through the Project API and the "default" settings for any new attributes introduced. What do people think? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to pipe output to input?
The key here is likely to be Sockets. On Thu, 2005-06-23 at 10:05 +0200, Peter Nabbefeld wrote: > Hello, > > I've asked this question on the users list, but it seems nobody knows there: > Is it possible to create two java processes (with fork="true") and pipe > the output of one process into the other? How? Can I focus a component? > Or generate a mouse event? > > I haven't found an example for this, neither in the FAQ nor using the > search function, so I guess there is nothing other than the parameter > description, which isn't very helpful. > > Kind regards > > Peter Nabbefeld > > > - > 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: Alternatives to XSLT (was Re: Can you help me!!!)
A fair approach as long as the XML document hasn't already been processed and re-written by some nasty container such as WebSphere or Weblogic (coz they always strip out comments). I like the idea of the external XmlTask task mentioned by Jan. Phil :n) On Thu, 2005-06-09 at 15:13 +0100, Steve Loughran wrote: > Phil Weighill-Smith wrote: > > As to your varying new content, simply handle this with parameters to > > your XSLT or something like that (perhaps even having different > > conditional targets that handle different EJB configuration setups in > > addition to parameterized XSLTs). > > > > Don't panic, take a deep breath and think about just what you're trying > > to do. Look at the Ant manual's list of core and optional tasks and work > > out how you can use them address your problem using them. > > > > Phil > > > > I've been abusing XML docs recently with replaceregexp; patching > comments in and out to produce 'normative' docs from 'usable docs with > local schemalocations'. Surprisingly simple. > > - > 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: Can you help me!!!
As to your varying new content, simply handle this with parameters to
your XSLT or something like that (perhaps even having different
conditional targets that handle different EJB configuration setups in
addition to parameterized XSLTs).
Don't panic, take a deep breath and think about just what you're trying
to do. Look at the Ant manual's list of core and optional tasks and work
out how you can use them address your problem using them.
Phil
On Thu, 2005-06-09 at 17:37 +0530, Srinivas wrote:
> No need of writing our own task???
>
> As I said I am totally new, I started working with ant now.
> What I understood is of ant do the necessary processing and
> modifications.
>
> But if the value of this particular tag
> varies from EJB to EJB then
>
> srini.
>
> -----Original Message-
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 09, 2005 5:07 PM
> To: Ant Developers List
> Subject: Re: Can you help me!!!
>
>
> Try using to extract the XML file from the EAR then use
> to process and modify the XML file accordingly. Rename the
> output file from the XSLT back to the original name (using )
> then use to put the file back in the EAR.
>
> Phil
>
> On Thu, 2005-06-09 at 15:52 +0530, Srinivas wrote:
> > Dear Smith,
> >
> > I am new to ant Scripting. My requirement is like this. We are using
> Weblogic.
> >
> > I receive an .EAR file and before deployment my BUILD should do
> the following.
> >
> > a. My Script should locate the weblogic-ejb-jar.xml inside the
> > .EAR and
>
> > Element should be modified per EJB basis.
> >
> > What do you suggest?
> >
> > Regards,
> > Srini.
> >
> > -Original Message-
> > From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, May 29, 2005 8:42 PM
> > To: Ant Developers List
> > Subject: RE: A possible solution for conditional execution of tasks?
> >
> >
> > There is the option to use the conditional task ("if") from ant-contrib...
> this allows the nesting of a "sequential" task which itself can contain any
> tasks you want.
> >
> > -Original Message-
> > From: Sandip Chitale [mailto:[EMAIL PROTECTED]
> > Sent: Sun 29/05/2005 16:06
> > To: Ant Developers List
> > Cc:
> > Subject: Re: A possible solution for conditional execution of tasks?
> >
> >
> >
> > Phil Weighill-Smith wrote:
> >
> > >My opinion regarding the disadvantages of this approach:
> > >
> > >* Antcall has to create a whole new Project in memory in order to
> work and is therefore an inefficient task
> > >
> > >
> > Yes. If the project is large this could be a large overhead. It seems
> > the semantics of antcall is not like a sub target but more like a target
> > in a sub project (even though the project happens to be the same
> > project). Is there a more lightweight solution planned in this area?
> >
> > >* If something invoked via Antcall depends on a target that is
> > also
> depended on by something depending on the target invoking Antcall then this
> dependency target will be executed more than once because dependencies are
> not handled across Antcall invocations
> > >
> > >
> > Yes.
> >
> > >* The dependency tree is "interrupted" and graphing tools that can
> show ant build script structures will not (generally) work correctly and
> show the whole dependency tree
> > >
> > >
> > I did not think about the graphing tools, but that is a good point also.
> >
> > Given the fact that you did not list any advantages it seems this is not
> > a good idea.
> >
> > >It might be better to add "if" and "unless" to the standard ant Task to
> allow for conditional execution, or even add a nested "condition" to the
> standard ant Task to allow for conditional execution. To provide BC with the
> standard "execute" method, the condition/if/unless processing would need to
> happen outside this method.
> > >
> > >
> > This seems like this is the real answer. However I read somewhere that
> > it is an architectural decision to not support "if" and "unless" etc. at
> > the task level. Can anyone point me to a discussion/document on that?
> >
> > What about using scripting
RE: Can you help me!!!
No need for a new task... Ant provides a whole host of generic tasks
that you can string together in a script to address a large number of
problem domains.
Please note that this sort request should be addressed to the user list
rather than the developer list.
Phil
On Thu, 2005-06-09 at 17:37 +0530, Srinivas wrote:
> No need of writing our own task???
>
> As I said I am totally new, I started working with ant now.
> What I understood is of ant do the necessary processing and
> modifications.
>
> But if the value of this particular tag
> varies from EJB to EJB then
>
> srini.
>
> -----Original Message-
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 09, 2005 5:07 PM
> To: Ant Developers List
> Subject: Re: Can you help me!!!
>
>
> Try using to extract the XML file from the EAR then use
> to process and modify the XML file accordingly. Rename the
> output file from the XSLT back to the original name (using )
> then use to put the file back in the EAR.
>
> Phil
>
> On Thu, 2005-06-09 at 15:52 +0530, Srinivas wrote:
> > Dear Smith,
> >
> > I am new to ant Scripting. My requirement is like this. We are using
> Weblogic.
> >
> > I receive an .EAR file and before deployment my BUILD should do
> the following.
> >
> > a. My Script should locate the weblogic-ejb-jar.xml inside the
> > .EAR and
>
> >Element should be modified per EJB basis.
> >
> > What do you suggest?
> >
> > Regards,
> > Srini.
> >
> > -Original Message-
> > From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, May 29, 2005 8:42 PM
> > To: Ant Developers List
> > Subject: RE: A possible solution for conditional execution of tasks?
> >
> >
> > There is the option to use the conditional task ("if") from ant-contrib...
> this allows the nesting of a "sequential" task which itself can contain any
> tasks you want.
> >
> > -Original Message-
> > From: Sandip Chitale [mailto:[EMAIL PROTECTED]
> > Sent: Sun 29/05/2005 16:06
> > To: Ant Developers List
> > Cc:
> > Subject: Re: A possible solution for conditional execution of tasks?
> >
> >
> >
> > Phil Weighill-Smith wrote:
> >
> > >My opinion regarding the disadvantages of this approach:
> > >
> > >* Antcall has to create a whole new Project in memory in order to
> work and is therefore an inefficient task
> > >
> > >
> > Yes. If the project is large this could be a large overhead. It seems
> > the semantics of antcall is not like a sub target but more like a target
> > in a sub project (even though the project happens to be the same
> > project). Is there a more lightweight solution planned in this area?
> >
> > >* If something invoked via Antcall depends on a target that is
> > also
> depended on by something depending on the target invoking Antcall then this
> dependency target will be executed more than once because dependencies are
> not handled across Antcall invocations
> > >
> > >
> > Yes.
> >
> > >* The dependency tree is "interrupted" and graphing tools that can
> show ant build script structures will not (generally) work correctly and
> show the whole dependency tree
> > >
> > >
> > I did not think about the graphing tools, but that is a good point also.
> >
> > Given the fact that you did not list any advantages it seems this is not
> > a good idea.
> >
> > >It might be better to add "if" and "unless" to the standard ant Task to
> allow for conditional execution, or even add a nested "condition" to the
> standard ant Task to allow for conditional execution. To provide BC with the
> standard "execute" method, the condition/if/unless processing would need to
> happen outside this method.
> > >
> > >
> > This seems like this is the real answer. However I read somewhere that
> > it is an architectural decision to not support "if" and "unless" etc. at
> > the task level. Can anyone point me to a discussion/document on that?
> >
> > What about using scripting? Is that not r
Re: Can you help me!!!
Try using to extract the XML file from the EAR then use
to process and modify the XML file accordingly. Rename the
output file from the XSLT back to the original name (using )
then use to put the file back in the EAR.
Phil
On Thu, 2005-06-09 at 15:52 +0530, Srinivas wrote:
> Dear Smith,
>
> I am new to ant Scripting. My requirement is like this. We are using
> Weblogic.
>
> I receive an .EAR file and before deployment my BUILD should do the
> following.
>
> a. My Script should locate the weblogic-ejb-jar.xml inside the
> .EAR and
> Element should be modified per EJB basis.
>
> What do you suggest?
>
> Regards,
> Srini.
>
> -Original Message-
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> Sent: Sunday, May 29, 2005 8:42 PM
> To: Ant Developers List
> Subject: RE: A possible solution for conditional execution of tasks?
>
>
> There is the option to use the conditional task ("if") from ant-contrib...
> this allows the nesting of a "sequential" task which itself can contain any
> tasks you want.
>
> -Original Message-
> From: Sandip Chitale [mailto:[EMAIL PROTECTED]
> Sent: Sun 29/05/2005 16:06
> To: Ant Developers List
> Cc:
> Subject: Re: A possible solution for conditional execution of tasks?
>
>
>
> Phil Weighill-Smith wrote:
>
> >My opinion regarding the disadvantages of this approach:
> >
> >* Antcall has to create a whole new Project in memory in order to
> work and is therefore an inefficient task
> >
> >
> Yes. If the project is large this could be a large overhead. It seems
> the semantics of antcall is not like a sub target but more like a target
> in a sub project (even though the project happens to be the same
> project). Is there a more lightweight solution planned in this area?
>
> >* If something invoked via Antcall depends on a target that is
> also depended on by something depending on the target invoking Antcall then
> this dependency target will be executed more than once because dependencies
> are not handled across Antcall invocations
> >
> >
> Yes.
>
> >* The dependency tree is "interrupted" and graphing tools that
> can show ant build script structures will not (generally) work correctly and
> show the whole dependency tree
> >
> >
> I did not think about the graphing tools, but that is a good point also.
>
> Given the fact that you did not list any advantages it seems this is not
> a good idea.
>
> >It might be better to add "if" and "unless" to the standard ant Task
> to allow for conditional execution, or even add a nested "condition" to the
> standard ant Task to allow for conditional execution. To provide BC with the
> standard "execute" method, the condition/if/unless processing would need to
> happen outside this method.
> >
> >
> This seems like this is the real answer. However I read somewhere that
> it is an architectural decision to not support "if" and "unless" etc. at
> the task level. Can anyone point me to a discussion/document on that?
>
> What about using scripting? Is that not recommended either?
>
> Google search revealed that many people are looking for solutions for
> similar problems.
>
> Regards,
> Sandip
>
> >
> >Phil :n.
> >
> > -Original Message-
> > From: Sandip Chitale [mailto:[EMAIL PROTECTED]
> > Sent: Sat 28/05/2005 18:56
> > To: dev@ant.apache.org
> > Cc:
> > Subject: A possible solution for conditional execution of tasks?
> >
> >
> >
> > To conditionally execute a step in Ant one has to resort to
> setting up a
> > target structure like this:
> >
> > :
> >
> >
> >
> > :
> >
> >
> >
> >
> >
> > :
> > :
> >
> >
> >
> >
> >
> > :
> > :
> >
> >
RE: A possible solution for conditional execution of tasks?
There is the option to use the conditional task ("if") from ant-contrib... this
allows the nesting of a "sequential" task which itself can contain any tasks
you want.
-Original Message-
From: Sandip Chitale [mailto:[EMAIL PROTECTED]
Sent: Sun 29/05/2005 16:06
To: Ant Developers List
Cc:
Subject: Re: A possible solution for conditional execution of tasks?
Phil Weighill-Smith wrote:
>My opinion regarding the disadvantages of this approach:
>
>* Antcall has to create a whole new Project in memory in order to
work and is therefore an inefficient task
>
>
Yes. If the project is large this could be a large overhead. It seems
the semantics of antcall is not like a sub target but more like a target
in a sub project (even though the project happens to be the same
project). Is there a more lightweight solution planned in this area?
>* If something invoked via Antcall depends on a target that is
also depended on by something depending on the target invoking Antcall then
this dependency target will be executed more than once because dependencies are
not handled across Antcall invocations
>
>
Yes.
>* The dependency tree is "interrupted" and graphing tools that
can show ant build script structures will not (generally) work correctly and
show the whole dependency tree
>
>
I did not think about the graphing tools, but that is a good point also.
Given the fact that you did not list any advantages it seems this is not
a good idea.
>It might be better to add "if" and "unless" to the standard ant Task
to allow for conditional execution, or even add a nested "condition" to the
standard ant Task to allow for conditional execution. To provide BC with the
standard "execute" method, the condition/if/unless processing would need to
happen outside this method.
>
>
This seems like this is the real answer. However I read somewhere that
it is an architectural decision to not support "if" and "unless" etc. at
the task level. Can anyone point me to a discussion/document on that?
What about using scripting? Is that not recommended either?
Google search revealed that many people are looking for solutions for
similar problems.
Regards,
Sandip
>
>Phil :n.
>
> -Original Message-
> From: Sandip Chitale [mailto:[EMAIL PROTECTED]
> Sent: Sat 28/05/2005 18:56
> To: dev@ant.apache.org
> Cc:
> Subject: A possible solution for conditional execution of tasks?
>
>
>
> To conditionally execute a step in Ant one has to resort to
setting up a
> target structure like this:
>
> :
>
>
>
> :
>
>
>
>
>
> :
> :
>
>
>
>
>
> :
> :
>
> :
>
> This is because of several reasons:
>
> * The ant tasks do not have something like *if* attribute.
> * One cannot get away with only two targets instead of
three because
> the dependencies are executed before the dependent. Using
the
> above example it is not possible to do what target
predicate does
> in the main target and avoid using the predicate target.
> * Ensure order of execution
>
> However, I tried a solution making use of antcall task and it
worked. It
> works as follows:
>
> :
>
>
> :
> :
>
>
>
> :
>
>
> :
>
>
> :
>
>
> The advantage of this approach is to quickly have some tasks
execute
> conditionall
RE: A possible solution for conditional execution of tasks?
My opinion regarding the disadvantages of this approach: * Antcall has to create a whole new Project in memory in order to work and is therefore an inefficient task * If something invoked via Antcall depends on a target that is also depended on by something depending on the target invoking Antcall then this dependency target will be executed more than once because dependencies are not handled across Antcall invocations * The dependency tree is "interrupted" and graphing tools that can show ant build script structures will not (generally) work correctly and show the whole dependency tree It might be better to add "if" and "unless" to the standard ant Task to allow for conditional execution, or even add a nested "condition" to the standard ant Task to allow for conditional execution. To provide BC with the standard "execute" method, the condition/if/unless processing would need to happen outside this method. Phil :n. -Original Message- From: Sandip Chitale [mailto:[EMAIL PROTECTED] Sent: Sat 28/05/2005 18:56 To: dev@ant.apache.org Cc: Subject: A possible solution for conditional execution of tasks? To conditionally execute a step in Ant one has to resort to setting up a target structure like this: : : : : : : : This is because of several reasons: * The ant tasks do not have something like *if* attribute. * One cannot get away with only two targets instead of three because the dependencies are executed before the dependent. Using the above example it is not possible to do what target predicate does in the main target and avoid using the predicate target. * Ensure order of execution However, I tried a solution making use of antcall task and it worked. It works as follows: : : : : : : The advantage of this approach is to quickly have some tasks execute conditionally by putting them in a target and calling that target using antcall after setting some property. And it seemed to work. My question is - is there a problem using this approach? Why or why isn't this a preferred approach? Thanks in advance, Sandip
Re: cvs commit: ant/docs/manual/CoreTasks echoxml.html
On Thu, 2005-05-26 at 10:06 +0100, Steve Loughran wrote: > > Hmm. Currently the task is only writing the first > > child as the root element of the output XML document, > > and including the XML declaration. AFAIK a > > non-well-formed fragment should forego the > > declaration. If so, we can do one of the following: > > > > 1) Disallow > 1 direct child of > > 2) Always write fragments, skipping the declaration. > > 3) Automatically include the declaration when there > >is only one direct child element. > > 4) Add some sort of cumbersome configuration options. > > > > XML not being my forte, I can say that 2) is simplest. > > What say any XML gurus out there? > > I'd say sometimes you want to write fragments, sometimes whole bits > with > encoding declarations. That is, #4. > > Make the default a well formed XML doc with a UTF-8 encoding; if you > want fragment then fragment=true, if you want a different encoding, > then > select it with an encoding attr. I'd go with that too, though it might be better to indicate whether you want the declaration rather than whether it is a fragment. Phil :n) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: ant/docs/manual/CoreTasks echoxml.html
It might be nice if you went for option 3 *and* 4 (but not cumbersome!). More
than one "root" element forces no XML declaration and an option to allow the
encoding to be specified for the output of the XML document/fragment when the
encoding is different from the one of the enclosing Ant script.
Phil :n)
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Wed 25/05/2005 18:40
To: Ant Developers List
Cc:
Subject: Re: cvs commit: ant/docs/manual/CoreTasks echoxml.html
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Phil Weighill Smith
> <[EMAIL PROTECTED]> wrote:
> > More along the lines of will it work with
> something
> > like:
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> ha, no, but it should, and will...
Hmm. Currently the task is only writing the first
child as the root element of the output XML document,
and including the XML declaration. AFAIK a
non-well-formed fragment should forego the
declaration. If so, we can do one of the following:
1) Disallow > 1 direct child of
2) Always write fragments, skipping the declaration.
3) Automatically include the declaration when there
is only one direct child element.
4) Add some sort of cumbersome configuration options.
XML not being my forte, I can say that 2) is simplest.
What say any XML gurus out there?
-Matt
__
Do you Yahoo!?
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/
-
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: cvs commit: ant/docs/manual/CoreTasks echoxml.html
More along the lines of will it work with something like: On Wed, 2005-05-25 at 05:04 -0700, Matt Benson wrote: > --- Phil Weighill Smith > <[EMAIL PROTECTED]> wrote: > > Does it support document fragments? > > > Do you mean programmatically? No. > > -Matt > > > Phil :n. > > > > On Wed, 2005-05-25 at 11:38 +0100, Steve Loughran > > wrote: > > > Matt Benson wrote: > > > > --- Alexey Solofnenko <[EMAIL PROTECTED]> wrote: > > > > > > > >>Why not to add this functionality into normal > > > >>? > > > > > > > > > > > > I suppose if you wanted to use entities, > > > > already can do this (clumsily). This task (OUCH > > > > actually doesn't compile b/c I forgot a file) > > was > > > > exceedingly easy and enforces well-formedness of > > the > > > > nested XML due to its being parsed as XML. > > > > > > Nice. I like it! If we ever get round to finishing > > the httpPost task in > > > the sandbox, we have a Rest client system :) > > > > > > > > > - > > > 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] > > > > > > > > __ > Do you Yahoo!? > Yahoo! Small Business - Try our new Resources site > http://smallbusiness.yahoo.com/resources/ > > - > 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: cvs commit: ant/docs/manual/CoreTasks echoxml.html
Does it support document fragments? Phil :n. On Wed, 2005-05-25 at 11:38 +0100, Steve Loughran wrote: > Matt Benson wrote: > > --- Alexey Solofnenko <[EMAIL PROTECTED]> wrote: > > > >>Why not to add this functionality into normal > >>? > > > > > > I suppose if you wanted to use entities, > > already can do this (clumsily). This task (OUCH > > actually doesn't compile b/c I forgot a file) was > > exceedingly easy and enforces well-formedness of the > > nested XML due to its being parsed as XML. > > Nice. I like it! If we ever get round to finishing the httpPost task in > the sandbox, we have a Rest client system :) > > - > 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: [Bug 28444] - Import: Target Handling Bug
Rather than having a specific element, could this not be achieved via a naming convention such as "-target-name" (the leading "-" actually makes the target uninvocable from the command line anyway and therefore pretty good and private from the CLI point-of-view)? Or even a new attribute on target that indicates that it is "private"? Phil :n. On Fri, 2005-05-13 at 17:18 +0100, Peter Reilly wrote: > Jose Alberto Fernandez wrote: > > >Just to put closure in my list of peeves about , > >I really think we need a way to define "private" targets. > > > > > +1, one should be able to write an importable build file that has > some exported targets - but internally uses targets that do not get > overwritten accidently. > > Peter > > >Now, for this to work properly, you need: > > > >1) A way to mark a target as private. > >2) private targets must be ignored by targets of the same names on other > > > >points in the hierarchy. > >3) Depends on a private target must be resolved by the correct instance > >of the target. > > > >So lets assume the following syntax: > > > > ... > > > >foo.xml > > > > >message="compiling"/> > > > > > >bar.xml > > > > > > >message="building"/> > > > > > > > >baz.xml > > > > > > > > > > > >ant compile > > prepare compile > > compiling > > > >ant build > > prepare build > > building > > > >Here: > >foo.xml is like an abstract project which does not define "setup"; > >bar.xml's setup is private to bar1 and will not be used by the > >dependency in foo1 > >baz.xml overrides (defines in this case) the setup target used in foo1 > >but not the one in bar1. > > > >The rewriting rules are a bit tricky, because for every private target > >you need to use a new "private name" for it, and change all the > >occurencies > >in dependencies on that file of the name, for the new name. > > > >Seems actually doable. > > > >Jose Alberto > > > > > > > >- > >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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 28444] - Import: Target Handling Bug
On Fri, 2005-05-13 at 11:38 +0100, Jose Alberto Fernandez wrote: > I would advocate to allow the importer the specify the aliasing name > it > wants to use for the imported things, so one has something like: > > foo.xml > > ... > > > bar.xml > > > ... > +1 to the 'as=""'. Would we still be able to reference "imp1.compile" as just "compile" if the target has not been overridden in the importing build script: I think this is very important to maintain. Phil :n. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 28444] - Import: Target Handling Bug
On Fri, 2005-05-13 at 10:25 +0100, Steve Loughran wrote: > -when you override a target, you dont get access to its dependents. > Workaround: many pseudo-targets that only model dependencies. In fact we have "real" targets that don't have dependencies and it is these that we override. These are also useful, in large projects, when you know you've made a change that doesn't require a complete dependency build to be performed. Again we find this useful as a developer may be updating (internal) code in one subsystem only and this allows us to avoid a four or five minute delay while Ant and Java work out exactly which classes need to be re- built across the whole project. Clearly the developer directly uses "no dependency" targets at their own risk as there could be dependencies that really do need to be processed. > -once you have sub-projects importing ../../common.xml, they are no > longer self contained, which makes it harder to work with outside the > existing build tree. We address this by having a wrapper for (or alias to) ant that specifically sets a property that points to the "common.xml"'s location so as long as that location exists and has "common.xml" in it all is fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bug 28444] - Import: Target Handling Bug
On Fri, 2005-05-13 at 09:00 +0200, Stefan Bodewig wrote: > > But say the importER explicitly depends on bar.foo . Isn't this > > still going to pollute the log in the opposite way my implementation > > would? :) i.e. > > > > [foo]: > > > > [bar.foo]: > > Yes. But this is less likely than having the importer depend on "foo" > IMHO. So in the normal case everything would look the same as today > and in border cases we'll get an additional empty target. If I understand what you're saying correctly, you don't expect importer build scripts to depend explicitly on the renamed imported targets. I'd disagree: we commonly "augment" the standard targets like this: standard.xml: ... build.xml: ... I'm not sure if this is what you're discussing or not. What I can say is that the output of targets and tasks used in our build scripts is very unclear. We generally find it difficult tell actually which target caused a given dependency target to be executed because there are too many "empty" target names being output (we have various targets that operate "if" and "unless" variants, but the target name is output even if the condition fails). In addition, the same "standard" targets are executed multiple times during our build in different contexts since we have the concept of "subsystems" within our build: main-dir/build.xml "ant" executes: main-dir/subsystem-one/build.xml main-dir/subsystem-two/build.xml main-dir/subsystem-.../build.xml from within targets that have dependencies between each other that describe subsystem dependencies. Each subsystem build.xml imports the standard targets and executes them in its context. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 28444] - Import: Target Handling Bug
I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! Phil :n) -Original Message- From: Matt Benson [mailto:[EMAIL PROTECTED] Sent: Thu 12/05/2005 21:43 To: Ant Developers List Cc: Subject: Re: [Bug 28444] - Import: Target Handling Bug --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: [SNIP] > Turning Matt's idea around: > > (1) Target "foo" is in project "bar". > (2a) There already is a target "foo" from the file > that imported > "bar", use the current code, we are ready, > "bar.foo" is there. > (2b) There is no other target "foo" yet. Create an > empty placeholder > target "bar.foo" that depends on "foo". > > If then later a target "foo" is found in the > importing buildfile, > replace the placeholder "bar.foo" with the > initial "foo" target. > > Wouldn't that work, stay backwards compatible and > hide "bar." whenever > possible? You confused me with the "later." Even though this could theoretically happen via 3rd-party API calls, we wouldn't be able to detect it, would we? Our local targets are known before we actually execute a top-level (target "") import, right? So what I take away from the above is that when there is only one "foo", the real work lives in "foo" while "bar.foo" depends on "foo" (my idea turned around). But say the importER explicitly depends on bar.foo . Isn't this still going to pollute the log in the opposite way my implementation would? :) i.e. [foo]: [bar.foo]: -Matt > > Stefan > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html - 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: Company Disclaimer [WAS: RE: [VOTE] Ant 1.6.4 release]
Try GMail... it works pretty well and is a cool web-based e-mail system. Phil :n) On Tue, 2005-05-10 at 08:59 -0500, Dominique Devienne wrote: > And here comes the newly Company-wide instituted automatic > disclaimer inserted at the outbound email gateway... > > I'm really sorry about this. And there's nothing I can do, > I think, except maybe try to post from a different account, > using a different mail client, which would be a bit 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.4 release > > > > ... > > --DD > > -- > > This e-mail, including any attached files, may contain confidential > and > > privileged information for the sole use of the intended recipient. > Any > > review, use, distribution, or disclosure by others is strictly > prohibited. > > If you are not the intended recipient (or authorized to receive > > information for the intended recipient), please contact the sender by > > reply e-mail and delete all copies of this message. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message. > > - > 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: PropertySet.iterator()
On this topic, what do people think of the ability to define a filter
set from a property set, where each filter has the property's name and
the property's value?
Phil :n.
On Wed, 2005-04-20 at 16:48 -0500, Dominique Devienne wrote:
> > 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 I think it could be cool.
>
> Sounds good. I wish we could also implement java.lang.Iterable,
> but since it's a new Java 1.5 interface, I don't know how we
> could do that... --DD
>
> -
> 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: Antlib package names
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) -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wed 20/04/2005 15:28 To: Ant Developers List Cc: Subject:RE: Antlib package names > 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 might have a point. Why not drop antlibs, and to indeed differentiate future extensions from Ant core, then add an explicit org.apache.ant.core package, which opens up the app-top-level org.apache.ant package for antlibs. So we'd have: org.apache.ant.core - Ant Core - explicit enough org.apache.ant.svn - SNV AntLib org.apache.ant.foo - FOO AntLib org.apache.ant.bar - BAR AntLib etc... I think I like this scheme better in fact. Use a more explicit package for Core, while offering shorter names for AntLibs. --DD - 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: Ant symbolic debugger?
Does it debug at the build script source level or at the java code level for the tasks? It's the former I'd really want in this case. Phil :n. -Original Message- From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Sent: Fri 15/04/2005 17:09 To: Ant Developers List Cc: Subject:Re: Ant symbolic debugger? At least some JBuilder 2005 (SE+?) have ANT debugger that allows also debug custom tasks. - Alexey. Phil Weighill-Smith wrote: >I wonder if there's any mileage in developing a symbolic debugger for Ant >scripts? While the debug output is often adequate for simple(ish) scripts I've >had a number of cases where I really could do with a symbolic debugger (like >just now!). > >Phil :n. > > > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > -- / Alexey N. Solofnenko home: http://trelony.cjb.net/ / - 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]
Ant symbolic debugger?
I wonder if there's any mileage in developing a symbolic debugger for Ant scripts? While the debug output is often adequate for simple(ish) scripts I've had a number of cases where I really could do with a symbolic debugger (like just now!). Phil :n. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: junit test runner enhancements
Steve, I've not written any code to help here, but thought the following issue could also be considered: When executing a test class that has no test methods what-so-ever (e.g. someone comments out all tests for some reason) the runner currently barfs instead of ignoring the test class. Phil :n. On Tue, 2005-04-12 at 16:54 +0100, Steve Loughran wrote: > I'm thinking of what would it take to modify JUnitTestRunner to > > -skip anything that is abstract > -skip anything that is not a test case > > I know there are bugs on this; has anyone done the code to do it, and if > not, where should I start. > > I could tweak JUnitTestRunner.run() to probe classes and then just > return if they werent there. > -Should I still fire events, or just skip everything > -Should we print everything (I say, yes, warn but continue) > > -Steve > > - > 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: ResourceCollections
I believe that using an undeclared prefix doesn't make the XML not well-formed it makes the XML "invalid" (i.e. a validating parser will barf) [1]. I think "well formed" simply means all the right syntax (element and attribute declarations are correct, and are all correctly closed/nested). [1] http://java.sun.com/xml/jaxp/dist/1.1/docs/tutorial/glossary.html#wellFormed -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Fri 01/04/2005 20:11 To: Ant Developers List Cc: Subject: RE: ResourceCollections > From: Peter Reilly [mailto:[EMAIL PROTECTED] > Matt Benson wrote: > >I also like the idea of using antlibs, but do we then > >indicate that the user must explicitly set up the > >namespace prefixes or do we assign them automagically? > > If the former, will anybody use them? If the latter, > >what prefixes to use? > > > The user must explicitly set them up. Right. NS prefixes are irrelevant really. The user picks whatever she likes. And you can't automagically assign them. Using an undeclared NS prefix makes the XML document not well-formed, AFAIK. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New COPY granularity breaks builds on Windows 2000
Won't argue with your comment in general, but Xxx Yyy wrote:
>>
>>
>>
which seems to be a case where overwrite is appropriate.
Phil :n)
On Tue, 2005-03-08 at 16:44, Peter Reilly wrote:
> Phil Weighill-Smith wrote:
>
> >An alternative, and far more portable work-around is to just use the
> >overwrite attribute on the second copy task.
> >
> >
> I think that this build file is just an example to show the
> problem, so this work-around may not be suitable for the real build file.
>
> This is the correct way to show problems, remove all the
> stuff that works and make a build file that just show the bit that fails.
>
>
> Peter
>
> >Phil :n)
> >
> >On Tue, 2005-03-08 at 16:11, Xxx Yyy wrote:
> >
> >
> >
> >>I looked, but didn't find any discussion on the new granularity
> >>FileUtils.getFileTimestampGranularity. This is messing up my builds
> >>big-time.
> >>
> >>If you are on Windows and you run two COPY operations within two
> >>seconds of each other, the second COPY will be skipped.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>G:\temp>ant -verbose
> >>Apache Ant version 1.6.2 compiled on July 16 2004
> >>Buildfile: build.xml
> >>Detected Java version: 1.4 in: C:\util\jdk\1.4.2\jre
> >>Detected OS: Windows 2003
> >>parsing buildfile G:\temp\build.xml with URI =
> >>file:///G:/temp/build.xml
> >>Project base dir set to: G:\temp
> >> [property] Loading Environment env.
> >>Build sequence for target `x' is [x]
> >>Complete build sequence is [x, ]
> >>
> >>x:
> >> [copy] Copying 1 file to G:\temp
> >> [copy] Copying G:\temp\aaa to G:\temp\bbb
> >>[sleep] sleeping for 1000 milliseconds
> >> [copy] G:\temp\aaa omitted as G:\temp\bbb is up to date.
> >>
> >>BUILD SUCCESSFUL
> >>Total time: 3 seconds
> >>G:\temp>
> >>
> >>
> >>The problem stems from this code in FileUtils.java.
> >>
> >>public long getFileTimestampGranularity() {
> >>if (Os.isFamily("dos")) {
> >>return FAT_FILE_TIMESTAMP_GRANULARITY;
> >>} else {
> >>return 0;
> >>}
> >>}
> >>
> >>This is a very poor test. I guess there's a limitted granularity of
> >>timestamps on FAT formatted disks. But this test is assuming that any
> >>drive under DOS or Windows is FAT formatted.
> >>
> >>My build files have this pattern:
> >>
> >>
> >>
> >>
> >>
> >>If the work takes more than two seconds (or build is run on other os,
> >>unix for example), then the ANT COPY works. If the work completes in
> >>under two seconds on Windows, ANT COPY fails.
> >>
> >>Temporary work-around is to override the granularity attribute on COPY.
> >> But the root cause of the problem (bad test in FileUtils) needs to be
> >>fixed.
> >>
> >>http://issues.apache.org/bugzilla/show_bug.cgi?id=33906
> >>
> >>-
> >>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]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: New COPY granularity breaks builds on Windows 2000
An alternative, and far more portable work-around is to just use the
overwrite attribute on the second copy task.
Phil :n)
On Tue, 2005-03-08 at 16:11, Xxx Yyy wrote:
> I looked, but didn't find any discussion on the new granularity
> FileUtils.getFileTimestampGranularity. This is messing up my builds
> big-time.
>
> If you are on Windows and you run two COPY operations within two
> seconds of each other, the second COPY will be skipped.
>
>
>
>
>
>
>
>
>
>
>
> G:\temp>ant -verbose
> Apache Ant version 1.6.2 compiled on July 16 2004
> Buildfile: build.xml
> Detected Java version: 1.4 in: C:\util\jdk\1.4.2\jre
> Detected OS: Windows 2003
> parsing buildfile G:\temp\build.xml with URI =
> file:///G:/temp/build.xml
> Project base dir set to: G:\temp
> [property] Loading Environment env.
> Build sequence for target `x' is [x]
> Complete build sequence is [x, ]
>
> x:
> [copy] Copying 1 file to G:\temp
> [copy] Copying G:\temp\aaa to G:\temp\bbb
> [sleep] sleeping for 1000 milliseconds
> [copy] G:\temp\aaa omitted as G:\temp\bbb is up to date.
>
> BUILD SUCCESSFUL
> Total time: 3 seconds
> G:\temp>
>
>
> The problem stems from this code in FileUtils.java.
>
> public long getFileTimestampGranularity() {
> if (Os.isFamily("dos")) {
> return FAT_FILE_TIMESTAMP_GRANULARITY;
> } else {
> return 0;
> }
> }
>
> This is a very poor test. I guess there's a limitted granularity of
> timestamps on FAT formatted disks. But this test is assuming that any
> drive under DOS or Windows is FAT formatted.
>
> My build files have this pattern:
>
>
>
>
>
> If the work takes more than two seconds (or build is run on other os,
> unix for example), then the ANT COPY works. If the work completes in
> under two seconds on Windows, ANT COPY fails.
>
> Temporary work-around is to override the granularity attribute on COPY.
> But the root cause of the problem (bad test in FileUtils) needs to be
> fixed.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33906
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: USE ANT_OPTS RE: OutOfMemoryException when compiling a large project
I personally dislike the requirement for environment variables (or other external inputs) in a build; the build should be self-contained. If another developer comes along without ANT_OPTS set up and attempts to build your project they will get the OoM Exception and waste time tracking the issue down. I recommend building the required sizes into your script and using fork. Phil :n. On Wed, 2005-03-02 at 14:24, Kenneth Wood wrote: > As someone suggested earlier, define ANT_OPTS in your environment > (read the Ant documentation about using ANT_OPTS) > > For example, we use > > ANT_OPTS="-Xmx1024m -Xms256m" > > Then you can compile without the need to use "fork". > > From my build log, compiling more files than your case of 496 files: > > javac: > [javac] Compiling 643 source files to ... > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 01, 2005 6:15 PM > To: [EMAIL PROTECTED] > Subject: DO NOT REPLY [Bug 33162] - OutOfMemoryException when compiling > a large project > > > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG* > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT > <http://issues.apache.org/bugzilla/show_bug.cgi?id=33162>. > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND* INSERTED IN > THE BUG DATABASE. > > http://issues.apache.org/bugzilla/show_bug.cgi?id=33162 > > > [EMAIL PROTECTED] changed: > >What|Removed |Added > > > Status|NEW |RESOLVED > Resolution||FIXED > > > > > --- Additional Comments From [EMAIL PROTECTED] 2005-03-02 01:15 > --- > I used the javac "fork" option with "memoryMaximumSize=800m" and it > worked fine. > Now I feel silly. > > Anyone know how to pass to javac -Xmx800m without forking? > -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: Launching Ant again
-projecthelp will still work since it executes after the entire build.xml has been loaded, including any imports. -Original Message- From: Yves Martin [mailto:[EMAIL PROTECTED] Sent: Wed 02/03/2005 07:32 To: Ant Developers List Cc: Subject: Re: Launching Ant again Phil Weighill-Smith <[EMAIL PROTECTED]> writes: > You could make your build generate a "build-targets.xml" from the > project.xml then have a standard build.xml that: > > 1. invokes a task that will re-generate the build-targets.xml from > project.xml if it is out-of-date > 2. imports build-targets.xml That's an option. I will try. But I think '-projecthelp' command will have difficulty to report all available targets if the default build.xml is used. Thank you for your idea -- Yves Martin - 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: Launching Ant again
You could make your build generate a "build-targets.xml" from the project.xml then have a standard build.xml that: 1. invokes a task that will re-generate the build-targets.xml from project.xml if it is out-of-date 2. imports build-targets.xml This is exactly what our build system does. Phil :n) On Tue, 2005-03-01 at 15:06, Yves Martin wrote: >Hello, > > I'm facing a difficult issue in my build system development. > > The b.s. generates a 'build.xml' from a 'project.xml'. > > When invoking a target 'compile' (for instance) in the current 'build.xml', > the 'build.xml' may be out-of-date compared to the 'project.xml'. > > Here are the possibilities I imagine: > > 1- fail with a clear message asking for a manual configuration and a new run. > > 2- configure to update build.xml and fail asking for a new run of the same > command. > > 3- configure, reload Ant Project from the new 'build.xml' and go on with the > new project > > 4- configure, give up current Ant processing, invoke a new Ant on the new > 'build.xml' with the same command line > > Is case '3' really feasible. If yes, how can I do ? > > I'm almost sure case '4' is feasible. But how can I get the current process > command line to invoke a new Ant ? > > Is there another way to do the complete process or only one step ? > > Thank you in advance for your help > Regards -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: Massively OT, 'Closures in Java' [was Re: AW: [Patch] modifiedselector, style, remove unused code, slightly more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
If you want to iterate through a List that has an unspecified
implementation (at the point of iteration) always use an iterator; this
is the only way to implement performant code without making assumptions
about the implementation of the list.
Phil :n.
On Mon, 2005-02-28 at 11:30, Jose Alberto Fernandez wrote:
> I do not think so, from LinkedList implementation:
>
> /**
> * Return the indexed entry.
> */
> private Entry entry(int index) {
> if (index < 0 || index >= size)
> throw new IndexOutOfBoundsException("Index: "+index+
> ", Size: "+size);
> Entry e = header;
> if (index < size/2) {
> for (int i = 0; i <= index; i++)
> e = e.next;
> } else {
> for (int i = size; i > index; i--)
> e = e.previous;
> }
> return e;
> }
>
> It will iterate on every call.
>
> Enough of this, as I think it is becoming a little out of subject for
> the ANT list :-)
>
> Jose Alberto
>
> > -Original Message-
> > From: Kev Jackson [mailto:[EMAIL PROTECTED]
> > Sent: 28 February 2005 11:19
> > To: Ant Developers List
> > Subject: Re: Massively OT, 'Closures in Java' [was Re: AW:
> > [Patch] modifiedselector, style, remove unused code, slightly
> > more lazy DigestAlgorithm.getValue (now with added source code -doh!)]
> >
> >
> > Jose Alberto Fernandez wrote:
> >
> > >AFAIU, LinkedList.get(N) requires traversing the list to
> > position N on
> > >every call [O(n^2)], so usage of an iteratoe is much cheaper on this
> > >case as there is no array behind the scenes.
> > >
> > >Jose Alberto
> > >
> > >
> > I've just worked out why it's ok to do it this way (with
> > respect to my
> > particular use-case). Basically I *want* to traverse the
> > entire list,
> > I'm not trying to pick out any particular position in the list (yes
> > truly expensive using LinkedList.get(i)). In my method I simply call
> > get(i) from 0..List.size():
> >
> > from docs
> > Operations that index into the list will traverse the
> > list from
> > the begining or the end, whichever is closer to the specified
> > index.
> >
> > So as I'm asking for position 0, the traversal starts at the
> > head of the
> > list, then I simply walk the list with the loop calling get(i), which
> > also happens to be the next element in the list from where the list
> > cursor currently is (ListIterator interface docs). Serendipity I
> > suppose, but my usage is the most efficient for LinkedLists and also
> > happens to be performant with ArrayLists, to do the
> > particular traversal
> > that I'm doing.
> >
> > Kev
> >
> > -
> > 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]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: Proposal
My guess is that, because of backward compatibility, the "ant" startup scripts won't get changed to unset it (which they could do easily enough). Some people use the classpath to actually add extra libraries to Ant because of historical needs (yes, there are better means of doing so now). Some documentation stating that there can be issues, and that people should check what their class path is if they have trouble running Ant, would be a good thing. Other than that, use a crutch or persuade someone that backwards compatibility isn't so critical in this case (or to add a special "use environment's class path" option to Ant's invocation to allow for backwards compatibility). Phil :n. On Tue, 2005-01-25 at 09:37, Kev Jackson wrote: > Phil Weighill-Smith wrote: > > >On Tue, 2005-01-25 at 09:22, Erik Hatcher wrote: > > > > > > > >>You may consider creating a custom ant command script which unsets > >>CLASSPATH before invoking the executable class. > >> > >> > >> > > > > > >Exactly what we do! > > > > > My point was that it shouldn't be set in the first place, > unsetting it before running is good, but it's a crutch. The developers > shouldn't have it set in the first place Oh and Oracle setting > it is no excuse as they have been told to uninstall the damn Oracle > client on many many occasions > > Kev > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Re: Proposal
On Tue, 2005-01-25 at 09:22, Erik Hatcher wrote: > You may consider creating a custom ant command script which unsets > CLASSPATH before invoking the executable class. > Exactly what we do! -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Re: local properties
Or use perl's "local" or even "my" (the latter suggestion being a joke - which is likely to back-fire as usual). ;n) Phil :n) On Tue, 2005-01-11 at 11:52, Kev Jackson wrote: > > Sounds good, but is it possible to get a different name than "let" ? > > > > Peter > > Following the VBness of "let", how about "dim"? ;) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: [Patch] StringInputStream
If we require an object parameter to be non-null our methods test for this and throw an IllegalArgumentException (note that we don't throw a NullPointerException). Perhaps the same could apply in Ant? -Original Message- From: Kev Jackson [mailto:[EMAIL PROTECTED] Sent: Tue 28/12/2004 10:25 To: Ant Developers List Cc: Subject: [Patch] StringInputStream - removed unused imports - changed to On a related note: Parameter x must not be null Wouldn't it make sense to throw some kind of exception if parameter x was null? At the beginning of the method, not later on when some other method tries something and gets hit with a NullPointerException. Some thoughts Kev - 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: [RT] Define common project properties and tasks
> > It seems to me that there are as many completely different ways of > > using Ant as there are projects in this world. If you were to supply a > > "standard" build script, ready for customization, what input file > > structure would it expect? What language would be compiled (if any)? > > What distribution structure should be created and what files should be > > used to populate it? What configuration control system should be > > accessed to obtain the "input files" (if any)? What common properties > > would exist? etc. > > Actually, I have not seen *that* many java project structures. I assume from that comment you're limiting the "sample" builds to simple, Java only projects? What properties and targets are you thinking of being supplied? > I mean, there is a source dir, a build dir, a tests dir... We may do things differently to everyone else (though this is the second time I've seen this type of project decomposition structure in a build) but we have the concept of "subsystems" in our build as our source base is fairly large... Each subsystem has up to four source directories (hand-coded API and implementation code plus the option for auto-generated API and implementation code) and up to two test directories (unit and integration test). Each subsystem also has a "build" directory that contains two generated "source" class structures (API and implementation separately) and two generated "test" class structures (unit and integration). Each subsystem has its own build.xml (which imports a standard set of subsystem build targets that can be overridden or augmented as required for the given subsystem, e.g. to generate code from an XML schema etc.). There is then an over-all product build.xml (which imports a standard set of product build targets that again can be overridden or augmented as required, e.g. to create the JARs from the subsystem outputs). Subsystems can depend on each other and on "external" resources such as JARs etc., based on simple to use XML files that are used to just-in-time generate Ant scripts that not only fetch the external resources from a repository but also define the build and runtime classpaths. You could argue that we have a "standard" build (since we have standard subsystem and product build imports) but I'm quite sure that a lot of what we do is specific to our environment (e.g. how and why we interact with our SCM - AccuRev - during the build process). > > While I agree that there is some commonality across many Java > > projects (in that Java has a packaging mechanism that utilizes > > directories etc. and that these projects commonly produce one or more > > JAR files) it seems to me that this approach would either be too > > restrictive on the type of project that could utilize it or that so > > much customization would be required as to negate the usefulness of > > it. > > Netbeans thinks otherwise, and in fact *does* include a basic build. > All IDEs have their layout, and tons of projects have used it without > customizations. One wonders just how scalable this basic build is (having not seen it I can't pass any further comment). > > Perhaps better to provide some more sophisticated example build > > scripts covering the use of Ant on client side and server (multi-JAR) > > Java projects (and other languages if any contributions could be > > taken for these). I'd especially like to see examples that: > > > > * split the build into several sections (perhaps using subant) in > > order to generate multiple, "tree dependent" JARs (i.e. one JAR > > depends on another but there are no cyclic dependencies) > > > > * utilize > > something like XSLT to generate Ant scripts from simple XML files > > that define the inter-dependencies within such a multi-part build > > > > * use a repository accessor (along the lines of the "get libraries" > > stuff that has recently been discussed a lot on this list) to obtain > > dependency JARs from other projects > > Krysalis Centipede did this years ago, but the project failed. Shame. Possibly because its of most use to large developments like ours which are perhaps fewer and further between? Phil :n. -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: [RT] Define common project properties and tasks
I'm not trying to rain on anyone's parade, but have you considered... It seems to me that there are as many completely different ways of using Ant as there are projects in this world. If you were to supply a "standard" build script, ready for customization, what input file structure would it expect? What language would be compiled (if any)? What distribution structure should be created and what files should be used to populate it? What configuration control system should be accessed to obtain the "input files" (if any)? What common properties would exist? etc. While I agree that there is some commonality across many Java projects (in that Java has a packaging mechanism that utilizes directories etc. and that these projects commonly produce one or more JAR files) it seems to me that this approach would either be too restrictive on the type of project that could utilize it or that so much customization would be required as to negate the usefulness of it. Perhaps better to provide some more sophisticated example build scripts covering the use of Ant on client side and server (multi-JAR) Java projects (and other languages if any contributions could be taken for these). I'd especially like to see examples that: * split the build into several sections (perhaps using subant) in order to generate multiple, "tree dependent" JARs (i.e. one JAR depends on another but there are no cyclic dependencies) * utilize something like XSLT to generate Ant scripts from simple XML files that define the inter-dependencies within such a multi-part build * use a repository accessor (along the lines of the "get libraries" stuff that has recently been discussed a lot on this list) to obtain dependency JARs from other projects Phil :n. -Original Message- From: news on behalf of Nicola Ken Barozzi Sent: Sat 18/12/2004 11:16 To: [EMAIL PROTECTED] Cc: Subject: [RT] Define common project properties and tasks If Ant defines a name for common project properties, then each task could have a parallel typedef that configures it with these values. In this way, a basic user would only need to write a property file and call the extended tasks without attributes, and have them work correctly OOTB. Same thing for tasks: if Ant provides a basic buildfile with the common targets, then users would only need to import it and customize the parts it needs to customize. WDOT? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - 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: Question Title: ANT -->> Directory access problem
Don't specify basedir in the sub-project build.xml and invoke it via from a build.xml in the c:\MyProject directory (with basedir "."): the sub-project will inherit the main project's basedir (i.e. c:\MyProject). Alternatively, access your source directory via ../src (which seems a bit duff, but workable). Finally, look at the and tasks' documentation. Phil :n. On Fri, 2004-12-17 at 05:48, IndianAtTech wrote: > Hi All, > > I know the following is valid syntax and also works fine in my case. > > > > > simple example build file > > > > > But i have different scenario. > Say I have a project called in MyProect in root direectory and it > contains sub directory called MyTest, something like > c:/MyProject/MyTest > > and also it contains c:/MyProject/src > > now placing my build.xml in c:/MyProject/MyTest foloder I wanted to > compile tje files of c:/MyProject/src > > By giving explicitly the value of basedir as /MyProject, I can make > build.xml to work. > > But I wanted to access the value of /MyProject/src dynamically. > > I have tried basedir"./" and basedir="/./" both doesnot work. > > So, Please let me know other solutions, if it is possible > > Thanks > sudhakar > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: About in the trenches
I've never used macrodef in Ant, but would say that I'd find a
"template" definition easiest to understand with the following
structure:
... (gives default value)
...
and usage of the form:
(maps to a parameter)
... (gives actual value)
or something like that.
You might even want to indicate that a given "parameter" is mandatory by
not specifying a default for the parameter.
How does that relate to macrodef? Can this approach be used? Is it worth
it? Just my tuppence worth. ;n)
Phil
On Fri, 2004-12-10 at 15:58, Dominique Devienne wrote:
> Thanks for the feedback Peter. I'll be off line most of Dec, so for now I'll
> just attach my modified MacroDef/Instance files in bugzilla until I can
> properly try to integrate it to Ant (it's not very tested yet, and not unit
> tested at all either). I worked off the 1.6 branch anyway, and this would
> need to happen in the HEAD I guess, no?
>
> About (1), you're right. I used my which is more like
> than , because it has no or block. 90% of the
> time, I don't need if/then/else, just if. I find having conditions on
> very natural and the Ant way ;-)
>
> (2) I initialy thought about putting it in the declaration, but I didn't
> think I could pull it off. And after using it, I thought it was easier to
> read the macro code with the defaults inside the macro impl instead of in the
> element declaration.
>
> (3) I agree it requires to get used to, but for the client code actually
> looks more 'normal' and task-like. Like (4), one doesn't have to use it.
>
> (4) Again, it's a question of reuse. I don't deny using @{attr} in the macro
> instance looks strange, but I did naturally try to use it with the regular
> Ant to learn it didn't work. I wanted to avoid duplicate some info
> I had already entered in a macro attribute. I'd say it's a nice to have
> thing, and one doesn't have to use it.
>
> BTW, after droping this code in my Antlib, my checkstyle Javadocs error count
> jumped from 0 to 35 ;-) I'll try to fix this too. (I have a checkstyle config
> for Javadocs only). --DD
>
>
>
> From: Peter Reilly [mailto:[EMAIL PROTECTED]
> Sent: Fri 12/10/2004 9:15 AM
> To: Ant Developers List
> Subject: Re: About in the trenches
>
>
>
> All these features sould great.
>
> 1) this attribute is good.
> however, it is only really usefull in combination with the iftrue
> attribute,
> or with ant-contrib "if" task
>
> 2) a default value for the element is good. The default value should
> be in the declaration, but it is ok to have it the body of the
> macrodef.
>
> 3) this sounds good if a little stange initially.
>
> 4) this is good as well, if one is useing elements with macrodefs a lot.
> It may
> be a bit confusing.
>
> I would say go for it!
>
> Peter
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: [Patch] style of UpToDate
I personally think the use of "final" for method parameters is "a good thing" - it reminds me of that great C++ feature "const" (which was actually far more sophisticated and useful, and strangely is a Java reserved keyword). Just because people haven't previously adopted a practice doesn't mean that it can't become best practice; this is a definite candidate for the latter. Phil :n. On Thu, 2004-12-02 at 15:54, Peter Reilly wrote: > Kevin Jackson wrote: > > > Peter Reilly wrote: > > > >> Kevin Jackson wrote: > >> > >>> Just removed the C++ style private variables > >> > >> > >> > >> cool, but... > >> 1) why place a "final" in the arguments > >> 2) you should only use the "this." in the setter > > > > > > 1) I was reading hardcore java - www.oreilly.com/catalog/*hardcore*jv/ > > > > The arguments made in favour of declaring variables to methods as > > final far outweighed (in my mind), the hassle of typing a few extra > > characters. The chapter on final being used in this (and a variety of > > other manners) is available as a pdf and I thoroughly recommend > > reading it, just to see what you think, but I couldn't disagree with > > his reasoning. > > Mmmm. > declaring method parameters as final may reduce a number of silly bugs, > however I cannot think of any > bugs in the ant code that has been caused by setting method parameters. > It is not normal java style to use > final method parameters and it > is not normal ant coding style (although some of Magesh's code does do > this).** > > > > > 2) yeah, sorry, I got carried away I think - in other methods there > > should be no need to use this - doh! > > > > The main reason I did this was that I've been trying to contribute for > > the last few days and I haven't found anything that I felt I had the > > time to start on and this looked like a quick contribution, > > An ongoing project is making the ant source code pass a checkstyle > audit. There is check.xml at the top level in the ant source code. > The top offending files are the moment are: > > taskdefs/Rmic.java > taskdefs/Zip.java > taskdefs/optional/vss/MSVSS.java > taskdefs/optional/javacc/JavaCC.java > taskdefs/optional/NetRexxC.java > taskdefs/optional/junit/JUnitTestRunner.java > types/Path.java > taskdefs/repository/Library.java > taskdefs/optional/jsp/JspC.java > > Peter > <cid:[EMAIL PROTECTED]> > > > > > Kev > > > > - > > 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] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Re: using jar element with includesfile
I assume you've tried: or or or Phil :n. On Fri, 2004-11-12 at 10:13, [EMAIL PROTECTED] wrote: > Hi all > I try to jar all the lines contained in text file.Each line describes a > WINDOWS NT path plus filename. > I used this build xml but does not jar.It's jar just the manifest. > Have a look! Please help > > ... > ="E:/automaticPackager/fileSet.txt" update="true"> > > ... > where E:/automaticPackager/fileSet.txt contains these lines: > e:/automaticPackager/tradeex/ec4/control/contentintegration/CxmlCatalogImportController.class > e:/automaticPackager/tradeex/ec4/control/contentintegration/CxmlExportFileListController$1.class > e:/automaticPackager/tradeex/ec4/control/contentintegration/CxmlExportFileListController.class > > > > > > > > > > Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. > Abbonati subito su http://www.libero.it > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Re: getting files name by a text file and doing a jar
Sorry, I think someone else who uses Ant on NT will have to help from
this point on...
Don't know why you should have trouble with "/" (Ant leverages Java's
file name management feature that automatically adapts filenames between
UNIX and Windows forms).
I can only guess that this problem is due to the directory scanner in
the fileset being initialized with "/" or "E:/" then finding that the
include patterns also start with "E:/".
Not sure how to get round this issue without doing something nasty like
using to remove the "E:/" (or "E:\") from the list file
filenames. Maybe there's some form of "selector" that you can use
instead...?
Phil :n.
On Thu, 2004-11-11 at 15:44, [EMAIL PROTECTED] wrote:
> i'm working on windos NT .It does not recognize "/"
> It does not work.If I add E: (the volume where all the file paths starts)does
> not work as well
> Help
>
> -- Initial Header ---
>
> From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> To : "Ant Developers List" [EMAIL PROTECTED]
> Cc :
> Date : Thu, 11 Nov 2004 14:46:51 +
> Subject : Re: getting files name by a text file and doing a jar
>
> > Sorry, I misread your example (didn't spot the includesfile attribute on
> > the jar element and just saw the fileset! Assuming that all your
> > filenames in the ${file.set.toJar} file are absolute filenames you
> > probably need to change basedir:
> >
> > > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > On Thu, 2004-11-11 at 14:33, [EMAIL PROTECTED] wrote:
> > > sorry I'm not sure to understand you
> > > a line like that > > includesfile="${file.set.toJar}" >
> > > is not what u mean?
> > > Could you write me the xml line please
> > > Regards
> > >
> > >
> > >
> > > -- Initial Header ---
> > >
> > > From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> > > To : "Ant Developers List" [EMAIL PROTECTED]
> > > Cc :
> > > Date : Thu, 11 Nov 2004 14:26:40 +
> > > Subject : Re: getting files name by a text file and doing a jar
> > >
> > > > You must use the includesfile attribute, not the file attribute. You
> > > > will also have to specify a dir attribute that the files in the
> > > > includesfile are relative to... if they aren't relative, you could try
> > > > "/" as the directory for the fileset.
> > > >
> > > > On Thu, 2004-11-11 at 14:17, [EMAIL PROTECTED] wrote:
> > > >
> > > > > get problem!! It does a jar but does not include all the files
> > > > > described in file.set.toJar.Take a look please!
> > > > > I post you my build xml
> > > > >
> > > > >
> > > > > > > > > ]>
> > > > >
> > > > >
> > > > >
> > > > > > > > > value="${jar.name}"/>
> > > > > > > > > value="${jar.base.dir}"/>
> > > > >
> > > > > > > > > value="${build.by.jar}"/>
> > > > > > > > > value="${jar.classpath.dir}"/>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >> > > > includesfile="${file.set.toJar}" >
> > > > >
> > > > >
> > > > >> > > > value="${build.by.jar}"/>
> > > > >> > > > value="1.0"/>
> > > > >> > > > value="${jar.classpath.dir}"/>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -- Initial Header ---
> > > > >
> > > > > From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> > > > > To : "Ant Developers List" [EMAIL PROTEC
Re: getting files name by a text file and doing a jar
Sorry, I misread your example (didn't spot the includesfile attribute on
the jar element and just saw the fileset! Assuming that all your
filenames in the ${file.set.toJar} file are absolute filenames you
probably need to change basedir:
> On Thu, 2004-11-11 at 14:33, [EMAIL PROTECTED] wrote:
> sorry I'm not sure to understand you
> a line like that includesfile="${file.set.toJar}" >
> is not what u mean?
> Could you write me the xml line please
> Regards
>
>
>
> ------ Initial Header ---
>
> From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> To : "Ant Developers List" [EMAIL PROTECTED]
> Cc :
> Date : Thu, 11 Nov 2004 14:26:40 +
> Subject : Re: getting files name by a text file and doing a jar
>
> > You must use the includesfile attribute, not the file attribute. You
> > will also have to specify a dir attribute that the files in the
> > includesfile are relative to... if they aren't relative, you could try
> > "/" as the directory for the fileset.
> >
> > On Thu, 2004-11-11 at 14:17, [EMAIL PROTECTED] wrote:
> >
> > > get problem!! It does a jar but does not include all the files described
> > > in file.set.toJar.Take a look please!
> > > I post you my build xml
> > >
> > >
> > > > > ]>
> > >
> > >
> > >
> > >
> > > > > value="${jar.base.dir}"/>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >> > includesfile="${file.set.toJar}" >
> > >
> > >
> > >> > value="${build.by.jar}"/>
> > >
> > >> > value="${jar.classpath.dir}"/>
> > >
> > >
> > >
> > >
> > >
> > > -- Initial Header ---
> > >
> > > From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> > > To : "Ant Developers List" [EMAIL PROTECTED]
> > > Cc :
> > > Date : Thu, 11 Nov 2004 13:47:23 +
> > > Subject : Re: getting files name by a text file and doing a jar
> > >
> > > > Can't you just use a task with a nested with the
> > > > includesfile attribute set to point to your file containing the list of
> > > > filenames?
> > > >
> > > > Phil :n.
> > > >
> > > > On Thu, 2004-11-11 at 13:42, [EMAIL PROTECTED] wrote:
> > > >
> > > > > Hi all
> > > > > I'd like to read from a text file a sequence of files to add to a
> > > > > jar.Actually I do not know how ant can help me.
> > > > > What I want is a build.xml that real all the lines of a text file
> > > > > (each rows describe a file name to jar)
> > > > > and doing a unique jar.
> > > > > Is it possible?
> > > > > Regards
> > > > > Giovanni
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di
> > > > > attivazione.
> > > > > Abbonati subito su http://www.libero.it
> > > > >
> > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > > --
> > > > Phil Weighill-Smith <[EMAIL PROTECTED]>
> > > > Volantis Systems
> > > >
> > >
> > >
> > >
> > >
> > > Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di
> > > attivazione.
> > > Abbonati subito su http://www.libero.it
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Phil Weighill-Smith <[EMAIL PROTECTED]>
> > Volantis Systems
> >
>
>
>
>
> Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione.
> Abbonati subito su http://www.libero.it
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: getting files name by a text file and doing a jar
You must use the includesfile attribute, not the file attribute. You
will also have to specify a dir attribute that the files in the
includesfile are relative to... if they aren't relative, you could try
"/" as the directory for the fileset.
On Thu, 2004-11-11 at 14:17, [EMAIL PROTECTED] wrote:
> get problem!! It does a jar but does not include all the files described in
> file.set.toJar.Take a look please!
> I post you my build xml
>
>
> ]>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>includesfile="${file.set.toJar}" >
>
>
>value="${build.by.jar}"/>
>
>value="${jar.classpath.dir}"/>
>
>
>
>
>
> -- Initial Header ---
>
> From : "Phil Weighill-Smith" [EMAIL PROTECTED]
> To : "Ant Developers List" [EMAIL PROTECTED]
> Cc :
> Date : Thu, 11 Nov 2004 13:47:23 +
> Subject : Re: getting files name by a text file and doing a jar
>
> > Can't you just use a task with a nested with the
> > includesfile attribute set to point to your file containing the list of
> > filenames?
> >
> > Phil :n.
> >
> > On Thu, 2004-11-11 at 13:42, [EMAIL PROTECTED] wrote:
> >
> > > Hi all
> > > I'd like to read from a text file a sequence of files to add to a
> > > jar.Actually I do not know how ant can help me.
> > > What I want is a build.xml that real all the lines of a text file (each
> > > rows describe a file name to jar)
> > > and doing a unique jar.
> > > Is it possible?
> > > Regards
> > > Giovanni
> > >
> > >
> > >
> > > ____
> > > Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di
> > > attivazione.
> > > Abbonati subito su http://www.libero.it
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > Phil Weighill-Smith <[EMAIL PROTECTED]>
> > Volantis Systems
> >
>
>
>
>
> Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione.
> Abbonati subito su http://www.libero.it
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: getting files name by a text file and doing a jar
Can't you just use a task with a nested with the includesfile attribute set to point to your file containing the list of filenames? Phil :n. On Thu, 2004-11-11 at 13:42, [EMAIL PROTECTED] wrote: > Hi all > I'd like to read from a text file a sequence of files to add to a > jar.Actually I do not know how ant can help me. > What I want is a build.xml that real all the lines of a text file (each rows > describe a file name to jar) > and doing a unique jar. > Is it possible? > Regards > Giovanni > > > > > Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. > Abbonati subito su http://www.libero.it > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
JAVA_HOME, JAVACMD, javac and junit
Firstly, apologies if this seems off list: the general point might be better addressed to the user list, but I have an issue with the "javac" task's default value for the "executable" attribute and the "junit" task's default value for the "jvm" attribute that probably relates better to this list. I've been looking at how to run Ant using 1.4 (we have Ant tasks that use 1.4 specific features) while have it use a 1.3 compiler for the "javac" task (and 1.3 runtime for "junit" test execution task). We need to do this to ensure that our developed software is 1.3 compatible. I *had* assumed that all I needed to do was set JAVACMD to point to the 1.4 java executable and have JAVA_HOME point to a 1.3 JDK. Sadly, this doesn't appear to be the case. I don't understand why the "javac" task requires the "executable" attribute to be specified when attempting to do this (the documentation says it defaults to the compiler for the JDK that Ant is run by... surely this *should* default to the one found in JAVA_HOME instead). I assume that I will have to explicitly use the "jvm" attribute on the "junit" task invocation (again, it would seem sensible if this task used JAVA_HOME to resolve the executable by default). What do people think about the defaults for javac executable and junit jvm? Has anyone tried to do this sort of thing (different Ant and javac/junit Javas)? If so, any hints or tips welcome! Phil :n. -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Conditional (Target) Execution
A while back there was a discussion about having a syntax for use in the if and unless attributes of targets. It has occurred to me that perhaps we just need a task akin to "sequential" that can have a condition data type as its first "child". This condition would determine whether the further content of the task would be "executed". This might look like: ... This example would be equivalent to using the if attribute, but the full power of condition could be applied. In addition, this would allow any sub-part of a target (including the default target) to be made conditional without resorting to the use of properties. Have I missed an existing Ant capability, or would this be a worthy enhancement? Phil Weighill-Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copy, Mapper and the Composite and Chained Mappers
Thanks Matt. Sorry folks. Another RTFM moment. :n( Phil On Fri, 2004-08-27 at 14:49, Matt Benson wrote: > This is really more of a user question. Anyway, per > the manual, if you use nested mappers of any type the > element will behave as a composite mapper, > which unions any child mapper elements. So the answer > is you would nest this way for a composite: > > > > > > > > > and this way for a chained mapper: > > > > > > > > > > HTH, > Matt > > --- Phil Weighill-Smith > <[EMAIL PROTECTED]> wrote: > > > I noticed that Ant 1.6.x has added composite mapper > > and chained mapper > > options as implementations of the FileNameMapper. > > > > I can't see how to use these with the copy task > > since copy seems to only > > support the "mapper" nested element and the latter > > doesn't list > > "composite" and "chained" as appropriate types. > > > > Have I missed something or is this a bug with the > > Mapper.MapperType > > enumeration? > > > > Phil :n. > > -- > > Phil Weighill-Smith > > <[EMAIL PROTECTED]> > > Volantis Systems > > > > > > > ___ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Copy, Mapper and the Composite and Chained Mappers
I noticed that Ant 1.6.x has added composite mapper and chained mapper options as implementations of the FileNameMapper. I can't see how to use these with the copy task since copy seems to only support the "mapper" nested element and the latter doesn't list "composite" and "chained" as appropriate types. Have I missed something or is this a bug with the Mapper.MapperType enumeration? Phil :n. -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: Bug in the "glob" file mapper?
Having got to this point in the conversation, it seems to me that the documentation and the implementation do not match. So, is this a bug or should the documentation be updated? Phil :n. -Original Message- From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Sent: Fri 13/08/2004 22:45 To: Ant Developers List Cc: Subject: Re: Bug in the "glob" file mapper? Sometimes you do not know exact path, because some products like to put version number into base directory name (I really hate it, but it is just common practice). If you know that there is exactly one file with a given name, sometimes it is easier to use instead of specifying full file name and change it every time somebody decides to change library build number. - Alexey. Dominique Devienne wrote: > >I think I misunderstood what you wanted to do. To copy a single file >from one place to another, just use . --DD > >- >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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug in the "glob" file mapper?
(Sorry if this message is HTML: having to use Outlook Web Access and don't know
how to control the mail format!)
Thanks for the info. Note that the documentation for the file mappers states
that "to" and "from" can "contain at most one '*'", which implies to me that
they can legitimately have zero stars. In this particular case the fileset
defined selects just one file, ant.jar, which is what I want to copy to a
different directory. The problem is that I don't know (in the Ant script) the
exact path to the ant.jar so I'm using "**/ant.jar":
What I want to do is copy the one and only "${source}/.../ant.jar" to
"${dest}/internal/ant.jar". Because the Ant script is itself generated
(generically) such that the copy "todir" attribute is fixed as "${dest}" I
can't simply set that to "${dest}/internal" and use a flatten mapper which is
what I'd otherwise do.
If you can think of a way of doing this processing with just changing the body
content of the copy element and not the copy element itself I'd love to know
the solution! Perhaps the regexp mapper would do this?
Phil :n(
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Fri 13/08/2004 19:07
To: Ant Developers List
Cc:
Subject: RE: Bug in the "glob" file mapper?
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> The "glob" file mapper is exhibiting a behaviour I didn't expect:
>
>
>
>
> Assuming that "*" matches "env/apache-ant-1.6.2/lib" I expected this
to
> copy the ant.jar to a destination of copy's todir + /internal/ant.jar.
> What it actually does is copy it to copy's todir +
> /internal/ant.jarenv/apache-ant-1.6.2/lib.
>
> I.e. if you don't use a "*" in the to attribute of the mapper, the "*"
> match is suffixed onto the "to". This seems wrong to me. Is this a
bug?
It's wrong in the sense that the glob mapper should most likely throw an
error when the "*" is missing in the 'to' attribute.
You can't use the glob mapper to concatenate files like this, and even
if it worked, plain concatenation wouldn't work with .jar files.
Use for plain concatenation.
Use or with for concatenation of JAR/ZIP files.
--DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug in the "glob" file mapper?
The "glob" file mapper is exhibiting a behaviour I didn't expect: Assuming that "*" matches "env/apache-ant-1.6.2/lib" I expected this to copy the ant.jar to a destination of copy's todir + /internal/ant.jar. What it actually does is copy it to copy's todir + /internal/ant.jarenv/apache-ant-1.6.2/lib. I.e. if you don't use a "*" in the to attribute of the mapper, the "*" match is suffixed onto the "to". This seems wrong to me. Is this a bug? Phil :n. -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mutex tasks
David, You're far better (from the atomicity and portability points-of-view) creating a directory instead of a file - directories can't be re-created on any filesystem I've used while files can be (so you might think you created the lock file but didn't due to a race condition). Phil :n. On Thu, 2004-07-29 at 13:11, [EMAIL PROTECTED] wrote: > I've just dome some testing in XP. The locks are simply zero length files and > nothing more. Also, because of the random backoff approach, I think it would > be > pretty robust. To clean up any locks left over from previous attempts, a > mastster scheduler could simply remove all files in the locks directory. > Should > I post code, and a build file example? I could also submit a patch to bugzilla > with all the stuff attached. > > David > > Quoting Steve Loughran <[EMAIL PROTECTED]>: > > > > > This is interesting. File locks worry me as they can be quirky on > > platforms and across shared file systems. And on winnt workstation, > > locks never seem to get released when an app crashes (unlike winnt server). > > > > What have you tested on? > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: new Task subclass
XPath is a language that handles complex expressions that *can* include
document navigation and "query" paths but also contains a lot of other
capabilities (consider what you can do with expressions in XSLT: these
expressions use XPath with extension functions).
My suggestion is to have Ant register extension functions with the
*XPath* context so that they are callable from XPath; however, in my
original message I suggested a single (standardized) "call" method that
can be used to call any registered Ant task as a catch-all. I also
suggested that you *might* want to invoke a target (for some reason)
within the expression and that this could be achieved using the document
navigation features of the XPath "language" (though what a return value
is from a target I don't know other than "success" or "BuildException
thrown").
Following your example we could register (again as I suggested) special
functions for the "standard" conditionals, so the expression could look
like:
${cond: available("file", $myFile, "type", "file")}
(XPath variable reference syntax is a bit different from Ant's property
reference syntax: it simply uses a "$" to prefix the QName of a
registered variable: all Ant properties would have to be registered as
variables with the XPath context/infrastructure in some way, with
"illegal" characters translated into legal ones).
Having thought about it a bit more, it strikes me that we could have a
means of automatically generating appropriate functions, in the
appropriate namespaces (if needed), for *any* and *all* registered
tasks. E.g. a task "myTask" in a namespace defined for
"http://example.org/namespace"; with a prefix of "x" could be
automatically provided with an expression function that would understand
the possible attributes just like Ant does. This would then be callable
like:
${cond: x:myTask("myAttr", $example)}
XPath allows function calls to be nested, so the following is legal (and
easy to implement):
${cond: condition(and(available("file", $myFile), available("file",
$myDir, "type", "dir")))}
Finally, functions can also be defined that generate "data types" other
than booleans. That way it would even be possible to handle nested
elements (as implied by the above example). Another example (this isn't
really conditional, but you should get the idea):
${cond: copy("todir", $myDir, fileset("dir", $fromDir, include("name",
"**/*.java"), include("name", "**/*.jj")))}
Following this example it can be seen that the parameters to the
function are either a string (in which case it's an attribute name and
therefore followed by an attribute value - which must also resolve to a
string), or are a data type (in which case it corresponds to a nested
element and has no following value).
(I assume that an expression that uses a task that doesn't effectively
return a boolean value would return true if the task executed
successfully and false if the task threw a BuildException).
Anyway, that's my tuppence worth.
Phil :n)
On Mon, 2004-07-26 at 16:48, Jose Alberto Fernandez wrote:
> OK, I been giving some more background thinking on this issue.
>
> And at this point, I cannot find any reason why to use Xpath
> as the language for condition evaluation. The reason being that
> on most builds (if not all) how the execution flow goes does not depend
> on how the XML build file looks like but on external factors
> "Is such class available?", "Are this files uptodate?", "Is this file
> bigger that that one",
> "Is the value of this property the same as this or that?"
>
> So I fail to see what good does it do to use a language designed to
> simplify
> talking about the structure of a document (attributs and elements) where
> that is the least of our concerns.
>
> With this in mind, I have been thinking on Velocity as a better glue for
> this
> language. The idea being to provide access to the current conditionals
> via the Velocity context, for example, and hence allow callong them from
>
> Velocity. The context will provide a bridge between the Velocity syntax
> and the most common conditionals by means of, for example, velocimacros.
>
> I am also thinking on Conditionals providing a subinterface that allows
> simpler glueing into the evaluation engine. So we would be able to say
> something like:
>
> if="${cond: $available.att("file",
> ${myFile}).att("type","file")}" or
> if="${cond: $available.file(myFile).type("file")}"
>
> or something like that. This will require us going ahead with addig
Re: new Task subclass
My vote for a "language" within if/unless elements is to use XPath (1 or
2). Pretty powerful and standard within the XML domain! You could even
think of supporting path expressions that access the entities (targets,
properties, types etc.) within the current Ant build file and could
provide some supporting functions that allow tasks and/or targets (in
the current build) to be invoked or other ant-specific operations to be
performed.
To maintain backwards compatibility, all that is needed is a delimiter
that indicates that an XPath expression is being used. E.g.
... if="debugmode" ...
for backwards compatibility or
... if="@call("available", "file", ${file}) == true()" ...
to indicate that the "available" task should be called with the
specified property set as the "file" attribute (XPath supports "varargs"
so having name/value pairs of parameters to define the attributes of the
invoked task is easy to implement). Explicit functions could be made
available for the most common task invocations in conditions.
Finally, it would even be possible to drop the delimiter and evaluate
the expression as an XPath instead of as a property name if there are
any "illegal" property name characters (such as "(", "/" or whitespace)
in the expression.
Phil :n)
On Thu, 2004-07-22 at 11:47, Stefan Bodewig wrote:
> On Thu, 22 Jul 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > As per if/unless itself, I really would like to explore more what
> > some people have suggested about having a richer language than just
> > set/unset.
>
> PropertyHelper?
>
> IOW, I think we already have the infrastructure needed to do that in
> Ant's core.
>
> Stefan
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: Notify about using the e-mail account.
I assume this is a trojan virus. It is impossible that I've been generating windows virus output from my e-mail account since I run LINUX! On Wed, 2004-03-03 at 15:03, [EMAIL PROTECTED] wrote: > -- Virus Warning Message (on the network) > > Found virus WORM_BAGLE.J in file Attach.pif > The file Attach.pif is moved to /var/spool/quarantine/virFIHIbuz.U. > > This is a machine-generated message, please do not reply via email. If you > have questions, please contact the Lucent Help Desk at +1 888 300 0770. > > - > > > __ > > Dear user of "Apache.org" mailing system, > > Our antivirus software has detected a large ammount of viruses outgoing > from your email account, you may use our free anti-virus tool to clean up > your computer software. > > Further details can be obtained from attached file. > > Have a good day, >The Apache.org teamhttp://www.apache.org > > > __ > > -- Virus Warning Message (on the network) > > Attach.pif is removed from here because it contains a virus. > > - > > > __ > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
Re: Extension of
w BuildException("Missing attribute name");
> }
> if (definitionString == null && definitionFile == null) {
> throw new BuildException("Missing beanshell script or file");
> }
> Interpreter i = new Interpreter(); // Construct an interpreter
> if (definitionFile != null) {
> try {
> i.source(definitionFile.getAbsolutePath());
> } catch (Throwable t) {
> throw new BuildException(t);
> }
> }
> try {
> if (definitionString != null) {
> i.eval(definitionString);
> }
> Object o = i.eval("new " + classname + "()");
> Class cl = o.getClass();
> AntTypeDefinition def = new AntTypeDefinition();
> def.setName(ProjectHelper.genComponentName(getURI(), name));
> def.setClassName(classname);
> def.setClass(cl);
> ComponentHelper.getComponentHelper(getProject())
> .addDataTypeDefinition(def);
> } catch (BuildException ex) {
> throw ex;
> } catch (Throwable t) {
> throw new BuildException(t);
> }
> }
> }
>
> Peter
>
> On Thursday 09 October 2003 17:38, Dominique Devienne wrote:
> > Cool and thanks for the link. I saw it, but it slipped my mind and I didn't
> > fully comprehend the possibilities. I also was made recently aware of
> > BeanShell 2.0b, and again there I don't grasp the new possibilities.
> >
> > Please keep me appraise with anything you learn on this front, if you don't
> > mind. There's something just outside our reach here that would be
> > tremendously powerful. --DD
> >
> > > -Original Message-
> > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, October 09, 2003 11:31 AM
> > > To: Dominique Devienne
> > > Subject: Re: Extension of
> > >
> > > No, it is not too easy. One would
> > > need to mess around with dynamic proxies.
> > >
> > > However using BeanShell 2.0 with a mod to Dawid's code it
> > > should be very easy.
> > >
> > > See
> > > http://marc.theaimsgroup.com/?l=ant-user&m=105523577505707&w=2
> > >
> > > Peter
> > >
> > > On Thursday 09 October 2003 16:48, you wrote:
> > > > Hi Peter,
> > > >
> > > > I haven't looked at in details, but I'm wondering if it
> > >
> > > could
> > >
> > > > be adapted to implement arbitrary interfaces instead of just a task?
> > > >
> > > > With such a facility, a COBOL filename case changing mapper could be
> > > > implemented on the fly (and easily posted to the ML), and have to code
> > >
> > > in
> > >
> > > > Java a bunch of tiny classes, and suffer from the overhead associated
> > >
> > > for
> > >
> > > > most users (compiling and packaging and declaring it the build file).
> > > >
> > > > Scripted Mappers, FilterReaders, Selectors, property manipulators,
> > >
> > > etc...
> > >
> > > > would simply things tremendously, and give unlimited power to Ant the
> > >
> > > world
> > >
> > > > ;-) --DD
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: Fw: Java Add On for Ant to fix filename + extension case issues
Paul,
This task would be improved by making the attributes use meaningful
names rather than numbers (as it is, every usage of the task in a build
file would probably have to be commented to state what is being done).
Ant provides a useful enumerated type mechanism for just this purpose,
called EnumeratedAttribute. Take a look at the source for Echo for an
example of its use.
Phil :n)
On Thu, 2003-10-09 at 16:18, [EMAIL PROTECTED] wrote:
>
>
> ---Original Message---
>
> From: Ant Users List
> Date: 08 October 2003 18:03:45
> To: user@ant.apache.org
> Subject: Java Add On for Ant to fix filename + extension case issues
>
>
> Notes:
>
> This code expects a filename.ext format because we are dealing with
> PeopleSoft
> cobol source that needs to be in the format FILENAME.cbl and SQR
> source that
> needs to be lower case. Now we can use ant to convert Windows based
> source
> to unix thanks to ant + a bit of java code added.
>
> You need this your build.xml file
>
>
>
> Then for COBOL:
>
>
>
>
>
> For SQR:
>
>
>
>
> And the source:
>
> package AntXtra;
>
> import org.apache.tools.ant.taskdefs.MatchingTask;
> import org.apache.tools.ant.BuildException;
> import org.apache.tools.ant.DirectoryScanner;
>
> import java.io.File;
> import java.io.IOException;
>
> /**
> * Converts file names providing lowercase/uppercase functionality.
> *
> * This task can take the following arguments:
> *
> * srcdir
> * mask
> * action
> *
> *
> *
> * @author Paul Gilligan href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
> net
> * @version 1.0
> */
>
> public class FixFileCase extends MatchingTask {
>
> public static final int FILENAME = 1;
> public static final int EXTENSION = 2;
> public static final int BOTH = 3;
>
> public static final int UPPER = 1;
> public static final int LOWER = 2;
>
> private File srcDir = null;
> private int mask = BOTH;
> private int action = UPPER;
>
> /**
> * Set the source dir to find the source text files.
> */
> public void setSrcdir(File srcDir) {
> this.srcDir = srcDir;
> }
>
> /**
> * Set the mask for processing file names and or extensions
> */
> public void setMask(int mask) {
> this.mask = mask;
> }
>
> /**
> * Set the action for processing file names and or extensions
> */
> public void setAction(int action) {
> this.action = action;
> }
>
>
> /**
> * Executes the task.
> */
> public void execute() throws BuildException {
> // Make sure that we've got a good srcdir
>
> if (srcDir == null) {
> throw new BuildException("srcdir attribute must be set!");
> }
> if (!srcDir.exists()) {
> throw new BuildException("srcdir does not exist!");
> }
> if (!srcDir.isDirectory()) {
> throw new BuildException("srcdir is not a directory!");
> }
>
> // Check the for vaild mask
> switch (mask) {
> case FILENAME: log("Fixing Filename only"); break;
> case EXTENSION: log("Fixing Extension only"); break;
> case BOTH: log("Fixing Filename and Extension"); break;
> default: throw new BuildException("invalid mask, must be 1, 2 or 3!");
> }
>
> // Check the for vaild action
> switch (action) {
> case UPPER: log("with upper case action"); break;
> case LOWER: log("with lower case action"); break;
> default: throw new BuildException("invalid action, must be 1 or 2!");
> }
>
> DirectoryScanner ds = super.getDirectoryScanner(srcDir);
> String[] files = ds.getIncludedFiles();
>
> for (int i = 0; i < files.length; i++) {
>
> // try for an extension
> String n = files[i].substring(0, files[i].lastIndexOf("."));
> String e = files[i].substring(files[i].lastIndexOf(".")+1);
>
> switch(action)
> {
> case UPPER:
> {
> switch(mask) {
> case FILENAME: n = n.toUpperCase(); break;
> case EXTENSION: e = e.toUpperCase(); break;
> case BOTH: n = n.toUpperCase(); e = e.toUpperCase(); break;
> }
> }
> break;
>
> case LOWER:
> {
> switch(mask) {
> case FILENAME: n = n.toLowerCase(); break;
> case EXTENSION: e = e.toLowerCase(); break;
> case BOTH: n = n.toLowerCase(); e = e.toLowerCase(); break;
> }
> }
> break;
> }
>
> File src = new File(srcDir, files[i]);
> File dst = new File(srcDir, n+"."+e);
>
> boolean renamed = src.renameTo(dst);
>
> if(!renamed) {
> log("source "+src+" destination "+dst+" not renamed!");
> }
> } // (int i = 0; i < files.length; i++) {
> }
> }
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> .
>
>
>
>
> IncrediMail - Email has finally evolved - Click Here
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: Can´t understand message
"Read-only"?
On Wed, 2003-10-08 at 13:02, [EMAIL PROTECTED] wrote:
> When using -debug a message is printed when properties are set.
> E.g.
>
> Setting ro project property: ant.version -> Apache Ant version 1...
> ^^
>
> What should the "ro" mean?
>
>
> oata.PropertyHelper.setUserProperty():line 406
>
> public synchronized void setUserProperty(String ns, String name,
> Object value) {
> project.log("Setting ro project property: " + name + " -> "
> + value, Project.MSG_DEBUG);
> userProperties.put(name, value);
>
>
>
>
> Jan
>
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Phil Weighill-Smith <[EMAIL PROTECTED]>
Volantis Systems
Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
We comment (with descriptions) all targets. Descriptions for targets that are not public are there for build file maintenance. However, we could always just remove descriptions and put them in as XML comments I guess. But this conversation's really for a different forum now! Phil :n) On Thu, 2003-09-25 at 18:00, Steve Loughran wrote: > Phil Weighill-Smith wrote: > > This attribute would be rather handy for tools such as IntelliJ IDEA > > which allows the graphical display of available targets for invocation > > (within its Ant integration). It would be great if IDEA could know which > > targets are "entry points" to the build file and only display those for > > execution. For it to do this, the "public/private" attribute would be > > needed. > > It does this. things without a description are shown as greyed > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
RE: AW: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
This attribute would be rather handy for tools such as IntelliJ IDEA which allows the graphical display of available targets for invocation (within its Ant integration). It would be great if IDEA could know which targets are "entry points" to the build file and only display those for execution. For it to do this, the "public/private" attribute would be needed. Phil Weighill-Smith On Thu, 2003-09-25 at 17:02, [EMAIL PROTECTED] wrote: > I don´t see the need for such an attribute. And if introduced it should work > not only from commandline. It should work too, if invoked by other java > applications. > > > Jan > > > > -Original Message- > > From: Gus Heck [mailto:[EMAIL PROTECTED] > > Sent: Thursday, September 25, 2003 5:58 PM > > To: Ant Developers List > > Subject: Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target > > tag to indicate hidden/internal target > > > > > > In fact I would be even more interested to hear the opinons of both > > commiters and non-commiters :). > > > > -Gus > > > > Gus Heck wrote: > > > > > Antoine Levy-Lambert wrote: > > > > > >> What you would like would be useful to prevent the "wrong" > > targets from > > >> being called. But I wonder whether this change would not make ant > > >> unnecessary complex. > > >> > > >> > > > The default (atribute omitted) state should behave as > > always. This is > > > necessary for back compatability, and to keep the learning > > curve from > > > getting too steep. The import task gives me the same sort of worry > > > about complexity, but I keep reiminding myself... You don't have to > > > use it if you don't want it ;). So at least from the user > > side, there > > > is no obligatory complexity increase. The addition of > > another atribute > > > in the documentation for target would be the only brain drain :)... > > > > > > As for the development side, it may lead to increased > > complexity if we > > > add access modifiers with more complex meanings. As it is > > now, however > > > the only meaning of public/private is "do we reject it when invoked > > > from the command line" and the only time we need to check that is > > > already included in the patch. > > > > > > I too would be interested to hear what other commiters think. > > > > > > - Gus > > > > > > > > > > > - > > > 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] > > -- Phil Weighill-Smith Tech Lead Volantis Systems Limited 1 Chancellor Court, Occam Road Surrey Research Park Guildford, Surrey GU2 7YT mailto:[EMAIL PROTECTED] http://www.volantis.com tel: +44 1483 739 778 mob: +44 7803 498 603 This message may contain confidential information and will be protected by copyright. If you receive it in error notify us, delete it and do not make use of, nor copy it. Any reply may be read by the recipient to whom you send it and others within Volantis Systems Ltd. Although we aim to use efficient virus checking procedures we accept no liability for viruses and recipients should use their own virus checking procedures. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [NOT PATCH] Possible new optional task for file modification
Thanks for letting me know... How do I go about creating a "patch" (bearing in mind I've not used CVS before)? That way perhaps I can get the stuff through to you... Do you think the summary of what this task does sounds useful? Phil :n. On Wed, 2003-09-17 at 18:54, Shatzer, Larry wrote: > Unfortunately your attachment was stripped. > > -- Larry > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, September 16, 2003 5:42 AM > > To: [EMAIL PROTECTED] > > Subject: [NOT PATCH] Possible new optional task for file modification > > > > > > (Sorry if this doesn't follow the standard "patch" way of > > doing things. I'm new to this Open Source experience!) > > > > Please find attached a submission for consideration as an > > additional optional Ant (1.5.x+) task. > > > > The Javadoc describes what it does, but as a summary: > > > > The task allows a (common) file to be updated with (multiple) > > content "fragments" where the fragments should be inserted at > > one or more tagged locations within the file. > > > > This is handy, for example, when adding sub-system specific > > configuration information into an application-wide > > configuration file formatted (for example) as an XML or > > properties file. > > > > I can supply my example Ant/test files if you'd like. In > > addition, I can supply a JUnit test case if you think it's > > worth having as a new optional task. > > > > ----- > > Email provided by http://www.ntlhome.com/ > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Weighill-Smith <[EMAIL PROTECTED]> Volantis Systems
