Hi Jaikiran
I cannot reproduce the error so your sample would be really helpful,
following is my attempt to reproduce on head
without source / target, cannot be run on 1.8:
jkf@zelfbouwasuscm:~/testje$ cat build.xml
jkf@zelfbouwasuscm:~/testje$ java --version
openjdk 11.0.3 2019-04
a 8.
>
> Br Martijn
>
>
> On 25-08-19 09:18, Jaikiran Pai wrote:
>> Hello Martijn,
>>
>> I was in the process of running some tests to decide if we are in a
>> state to do a release of Ant project. While doing so, I ran into an
>> issue where our proj
java 8.
Br Martijn
On 25-08-19 09:18, Jaikiran Pai wrote:
Hello Martijn,
I was in the process of running some tests to decide if we are in a
state to do a release of Ant project. While doing so, I ran into an
issue where our project build no longer honours the source, target and
release
Hello Martijn,
I was in the process of running some tests to decide if we are in a
state to do a release of Ant project. While doing so, I ran into an
issue where our project build no longer honours the source, target and
release attributes of the javac task for versions of javac that support
it
But, there is one definite bug: the original name of the default target has
its location set to line rather than the actual
line.
Gintas
2013/9/30 Gintautas Grigelionis
> I must correct myself again... the short names are there, too, and one may
> use getLocation() to get rid of the d
The
> middle paragraph should read:
>
> Now getName() of a Target returns the original name prepended by the name
> of the *imported* project (the same as corresponding key in getTargets()
> in a Project), *but* getProject() returns the top project name, so there
> is no way
Sorry for double post, my description of the problem is incorrect. The
middle paragraph should read:
Now getName() of a Target returns the original name prepended by the name
of the *imported* project (the same as corresponding key in getTargets() in
a Project), *but* getProject() returns the top
I have noticed (belatedly) a change in Ant API, namely, that there
seems to be no way to find out
what the original target names in an imported project are. Previously,
original names were returned by
getName() in a corresponding Target, which was consistent with
getDependencies().
Now getName
On Sun, Dec 2, 2012 at 5:51 PM, Gábor Guta wrote:
> If I list the target names of a project from the build node, there
> is an extra target with name "". Is this target represents the global
> declarations?
from http://ant.apache.org/manual/using.html :
"since
Hi,
If I list the target names of a project from the build node, there
is an extra target with name "". Is this target represents the global
declarations?
I have also noticed that the targets in the imported projects appear
in duplicated form (targetName and projectName.target
Hey!
I'm wondering if it's possible to have a fixed default target, which
always executes instead of what's put on the command-line?
The reason for this is we use the depends feature of ant to be able to
for instance publish to an ivy repository with a better flow. ant local
mi
On 06/25/2010 08:20 AM, Jesse Glick wrote:
I'm not an admin so I can't see the job configuration.
I am now. I think I finally managed to get all the Ant-related (not Ivy-related) jobs at least "succeeding", though there remain various test failures. Building on JDK
1.4 across various slave nod
On 06/25/2010 06:52 AM, jan.mate...@rzf.fin-nrw.de wrote:
Building modules in parallel.
Good luck there... these are only "modules" by fiat; they share some source and target dirs. The include/exclude definitions very likely do not form a disjoint union of
all source files, so I ha
om the poms, right?
Jan
>-Ursprüngliche Nachricht-
>Von: Jesse Glick [mailto:jesse.gl...@oracle.com]
>Gesendet: Donnerstag, 24. Juni 2010 18:16
>An: dev@ant.apache.org
>Betreff: Re: AW: AW: Hudson target to build Ant via Maven
>
>On 06/24/2010 10:17 AM, jan.mate...@rzf.
then include
target/*/surefire-reports/TEST-*.xml
in Hudson's test report patternset.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Hudson target to build Ant via Maven
>
>On 06/24/2010 08:30 AM, jan.mate...@rzf.fin-nrw.de wrote:
>> Configuration:
>
>Looks like the build node is misconfigured:
>
>Unable to locate the Javac Compiler in:
> C:\java\jre6\..\lib\tools.jar
>
>If you have admin
On 06/24/2010 08:30 AM, jan.mate...@rzf.fin-nrw.de wrote:
Configuration:
Looks like the build node is misconfigured:
Unable to locate the Javac Compiler in:
C:\java\jre6\..\lib\tools.jar
If you have admin access you can set the job to use JDK 1.4.2_19 or whatever
you like.
--
ed @hourly
* Builder: Maven:
- version: latest
- pom: src/etc/poms/pom.xml
- goals: clean package
Jan
>-Ursprüngliche Nachricht-
>Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de]
>Gesendet: Dienstag, 22. Juni 2010 12:27
>An: dev@ant.apache.org
>B
I'll try that ...
Jan
>-Ursprüngliche Nachricht-
>Von: Jesse Glick [mailto:jesse.gl...@oracle.com]
>Gesendet: Dienstag, 15. Juni 2010 02:19
>An: dev@ant.apache.org
>Betreff: Re: Hudson target to build Ant via Maven
>
>On 06/11/2010 08:44 PM, Antoine Levy-
On 06/11/2010 08:44 PM, Antoine Levy-Lambert wrote:
we could contact the maven team and ask them to build ant in continuum.
Possible. I just suggested using the existing Hudson server to keep everything
together. (Hudson has good Maven support.)
--
Jesse Glick wrote:
> There appears to be a Hudson server which builds Ant periodically
> using bootstrap.sh, I presume. (I cannot access the server even to
> look at it, much less configure it.)
>
> Shouldn't there be an analogous job which runs Maven on
> src/etc/pom.xml? The POMs are tricky to ma
There appears to be a Hudson server which builds Ant periodically using
bootstrap.sh, I presume. (I cannot access the server even to look at it, much
less configure it.)
Shouldn't there be an analogous job which runs Maven on src/etc/pom.xml? The POMs are tricky to maintain - well, actually eas
e build and packaging a tree
> of dependent modules.
>
> Question:
> Is there a way to retrieve dependencies declared in Ivy config files from
> Ant target during the build so that Ant can rebuild dependent modules?
>
> To my understanding Ivy just fetches prebuilt versions of modu
there a way to retrieve dependencies declared in Ivy config files
from Ant target during the build so that Ant can rebuild dependent
modules?
To my understanding Ivy just fetches prebuilt versions of modules and
can not be used from Ant
like
depends="get_dependenc
Le 6 janv. 2010 à 22:09, Antoine Levy Lambert a écrit :
> Hello Jesse,
>
> true, extension-of would have looked nicer together with extension-point.
> Maybe Eclipse uses "extensionOf" too ?
When I mentioned that in Eclipse world they use "extension of", it was talking
about the vocabulary mor
Hello Jesse,
true, extension-of would have looked nicer together with
extension-point. Maybe Eclipse uses "extensionOf" too ?
I wish you would have chimed in before I did the RC1 build.
Regards,
Antoine
Jesse Glick wrote:
Antoine Levy Lambert wrote:
extension-point/extensionOf is the winn
Antoine Levy Lambert wrote:
extension-point/extensionOf is the winning ticket.
Why the hyphenated-name in one and camelCase in the other? Would expect
'extension-of'.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
Hello Steve,
there will be for sure several release candidates. And afterwards
several 1.8.x builds.
Regards,
Antoine
Steve Loughran wrote:
Antoine Levy Lambert wrote:
I am thinking of building the first ant 1.8.0 release candidate
tomorrow.
I need to get my docs together; won't be abl
Antoine Levy Lambert wrote:
I am thinking of building the first ant 1.8.0 release candidate tomorrow.
I need to get my docs together; won't be able to do it today
in EU working hours. what is the timetable for getting doc patches into
the release chain?
I am thinking of building the first ant 1.8.0 release candidate tomorrow.
Regards,
Antoine
Stefan Bodewig wrote:
On 2009-12-29, Antoine Levy Lambert wrote:
extension-point/extensionOf is the winning ticket.
svn revision 895567 has been adapted to it.
Stefan
---
mar,
C.T.O
www.tejasoft.com
Martijn Kruithof-2 wrote:
>
> I would be in favour of using
>
> and or even
> and
> the dash in the name is not something we usually do in ant
>
> Martijn
>
> Antoine Levy Lambert wrote:
>> Hi,
>>
>> I would like to start a f
On 2009-12-29, Antoine Levy Lambert wrote:
> extension-point/extensionOf is the winning ticket.
svn revision 895567 has been adapted to it.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional command
[ ] for the group and extensionOf="foo" ... for members of the group
- 4 binding votes for extension-point. (Nicolas, Matt, Bruce, Stefan)
Stefan wrote that he prefers extension-point and would go with the
majority. So I am counting him here.
- 2 binding votes for
Stefan Bodewig wrote:
Currently I don't have strong feelings either way, I prefer
extension-point slightly, but can certainly live with target-group.
I'll go with the majority.
Exactly my feeling. +1 for extension-point/extensionOf, happy with
target-group (with or without the das
Coming into this thread I didn't really have an opinion, but I like this
reasoning. +1 for both.
Nicolas Lalevée wrote:
Well, the main use case I see of target groups is about using them between
different build scripts, as also noted in the documentation Stefan just
wrote. So the "
I would be in favour of using
and or even
and
the dash in the name is not something we usually do in ant
Martijn
Antoine Levy Lambert wrote:
Hi,
I would like to start a formal vote on the name of target-group.
[ ] for the group and ... for the members of the group
this is the current
On Dec 22, 2009, at 10:47 AM, Antoine Levy Lambert wrote:
Hi,
I would like to start a formal vote on the name of target-group.
[ ] for the group and group="foo" ... for the members of the group
this is the current codebase
Allow me to be the first:
[X] for the group and e
On Tue, 22 Dec 2009 11:47:17 -0500, Antoine Levy Lambert
wrote:
> Hi,
>
> I would like to start a formal vote on the name of target-group.
>
> [ ] for the group and for the members of the group
> this is the current codebase
>
> [ ] for the group and extensionOf=
+1 for
[X] for the group and
> for the group and the members of the group
>
> IMO, group just fine. maybe later group other elements. If so just
> group again/too.
>
> Regards,
> qinxian
>
> -
> To unsubscribe, e-mail: dev-u
for the group and
On 2009-12-22, Antoine Levy Lambert wrote:
> I would like to start a formal vote on the name of target-group.
Currently I don't have strong feelings either way, I prefer
extension-point slightly, but can certainly live with target-group.
I'll go with the majority.
> [ ] f
M, Antoine Levy Lambert wrote:
> Hi,
>
> I would like to start a formal vote on the name of target-group.
>
> [ ] for the group and the members of the group
> this is the current codebase
>
> [ ] for the group and extensionOf="foo" ... for members of
[ x] for the group and for the group and
> Antoine Levy Lambert wrote:
>
>>
>> [ x] for the group and > for the members of the group
>>
>> this is the current codebase
>>
>> Let me start with +1 for the current codebase.
>
>
> Antoine
>
> --
Antoine Levy Lambert wrote:
[ x] for the group and ... for the members of the group
this is the current codebase
Let me start with +1 for the current codebase.
Antoine
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.o
Hi,
I would like to start a formal vote on the name of target-group.
[ ] for the group and for the members of the group
this is the current codebase
[ ] for the group and extensionOf="foo" ... for members of the group
[ ] others
Regards
hink a more explicit term that has the word target in it would work
> better.
Well, the main use case I see of target groups is about using them between
different build scripts, as also noted in the documentation Stefan just
wrote. So the "extension point" is more an extension point
On the other hand the term extension point sounds generic and appears
to accept anything the system operates on, like tasks, types, targets,
dependencies etc.
In this case we're only talking about targets.
I think a more explicit term that has the word target in it would work better.
On Mon
On Dec 20, 2009, at 11:10 PM, Stefan Bodewig wrote:
On 2009-12-19, Gilles Scokart wrote:
But still I would take the risk to turn this thread into a
brainstorming :
absolutely.
What about extension-point ?
Sounds good.
I don't think I weighed in on "extension-point" yet, but I like
at achieve the same effect?
It would make things less explicit, in particular on the side of targets
"joining" the depends list; and there could be a risk of joining such a
depends list by accident (i.e. naming your target with a prefix by pure
coincidence).
Apart from
On 2009-12-19, Gilles Scokart wrote:
> But still I would take the risk to turn this thread into a brainstorming :
absolutely.
> What about extension-point ?
Sounds good.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant
Hi all,
I'm wondering if introducing a new name can be avoided alltogether.
What if depends="prefix*" meant depends on all targets that start with "prefix"?
For example:
Wouldn't that achieve the same effect?
Regards,
Sandu
---
hoices may not be good
anyway.
I understand that (2) is very dependent on (1).
(1) What do we want to call the new element that behaves quite a bit
like a target but has a dependency list that can be extended?
(a) target-group
(b) phase
(c) goal
(d - z) anything else
I like ta
>
> I understand that (2) is very dependent on (1).
>
> (1) What do we want to call the new element that behaves quite a bit
>like a target but has a dependency list that can be extended?
>
>(a) target-group
>
>(b) phase
>
>(c) goal
>
>(d - z
How about some thing like
or
--
View this message in context:
http://old.nabble.com/Naming-of-target-group-tp26844828p26854047.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail
may not be good
> anyway.
>
> I understand that (2) is very dependent on (1).
>
> (1) What do we want to call the new element that behaves quite a bit
> like a target but has a dependency list that can be extended?
>
> (a) target-group
no objection for me
&
On 2009-12-18, Kevin Jackson wrote:
>> I understand that (2) is very dependent on (1).
>> (1) What do we want to call the new element that behaves quite a bit
>> like a target but has a dependency list that can be extended?
> - moving-target (very familiar for
with something new here. I've collected the names that I recall being
proposed, but I may have missed some and the choices may not be good
anyway.
I understand that (2) is very dependent on (1).
(1) What do we want to call the new element that behaves quite a bit
like a target but has a
dent on (1).
(1) What do we want to call the new element that behaves quite a bit
like a target but has a dependency list that can be extended?
(a) target-group
I am fine with target-group. We can explain in the doc whether this
concept is similar to maven goals.
(b) phase
> I understand that (2) is very dependent on (1).
>
> (1) What do we want to call the new element that behaves quite a bit
> like a target but has a dependency list that can be extended?
- moving-target (very familiar for people working in IT)
or
- mutable-target ?
>
>
do we want to call the new element that behaves quite a bit
like a target but has a dependency list that can be extended?
(a) target-group
(b) phase
(c) goal
(d - z) anything else
(2) What do we want to call the attribute of that is used to
add a target to a depends-
On Thu, 17 Dec 2009 09:42:11 +0100, Stefan Bodewig
wrote:
> On 2009-12-16, Bruce Atherton wrote:
>
>> To me, only two of the options are seriously being discussed right now:
>
>> 1) the current target-group codebase
>> 2) moving the behaviour of target-group
On 2009-12-17, Bruce Atherton wrote:
> You've convinced me. Just because we can't think of a problem doesn't
> mean that one doesn't exist, and it is a little late in the day to
> start monkeying around if we want to get a new release out the door.
> So Stefan, as far as your poll is concerned,
On 2009-12-16, Dominique Devienne wrote:
> Sorry to hijack your POLL thread Stefan ;)
Thank you for doing so
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.
On 2009-12-16, Bruce Atherton wrote:
> To me, only two of the options are seriously being discussed right now:
> 1) the current target-group codebase
> 2) moving the behaviour of target-group into all targets through a
> marker attribute
Nobody is more surprised by this
On 2009-12-16, Bruce Atherton wrote:
> Sorry if the previous thread was hijacked by naming issues, but I'm
> not sure I'm ready to vote in a poll yet.
That's why it only is a poll and not a vote 8-)
To be honest I was hoping to get away from the naming issue and to a
discussion of the feature i
e
current code base.
Dominique Devienne wrote:
On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton wrote:
Can anyone give a concrete example where there would be a problem treating a
target-group as if it were a target?
Can't. But my thinking is that we should ere on the conservati
Dominique Devienne wrote:
This allows to release sooner (1.7.1 is 18 months old), without rushing what is
admittedly a more radical change to Ant's target dependency handling.
Agreed. More broadly, I would like to deflate discussions of this kind a bit. How many users are really clamorin
Pandora's box
just yet on target dependencies, and provide a useful yet limited
extensible target (target-group), along with all the fixes Antoine
mentions. Lets see how it fairs in the wild and what users are
claiming for to make it more useful. This allows to release sooner
(1.7.1 is 18 month
On Wed, 16 Dec 2009 08:51:27 -0600, Dominique Devienne
wrote:
> On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton
> wrote:
>> Can anyone give a concrete example where there would be a problem
>> treating a
>> target-group as if it were a target?
>
> Can't. But m
Dominique Devienne wrote:
On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton wrote:
Can anyone give a concrete example where there would be a problem treating a
target-group as if it were a target?
Can't. But my thinking is that we should ere on the conservative side
when we intr
On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton wrote:
> Can anyone give a concrete example where there would be a problem treating a
> target-group as if it were a target?
Can't. But my thinking is that we should ere on the conservative side
when we introduce such a feature, an
On Tue, 15 Dec 2009 17:53:25 -0800, Bruce Atherton
wrote:
> Sorry if the previous thread was hijacked by naming issues, but I'm not
> sure I'm ready to vote in a poll yet.
>
> To me, only two of the options are seriously being discussed right now:
>
> 1) the c
On Mon, 14 Dec 2009 13:19:55 +0100, Stefan Bodewig
wrote:
> before we get carried away with naming discussions ...
>
> Currently I don't feel there is consensus of what we'd like to see with
> target-group (if anything at all). The options I see are
>
> * ha
Sorry if the previous thread was hijacked by naming issues, but I'm not
sure I'm ready to vote in a poll yet.
To me, only two of the options are seriously being discussed right now:
1) the current target-group codebase
2) moving the behaviour of target-group into all targets
On Mon, Dec 14, 2009 at 6:19 AM, Stefan Bodewig wrote:
> * have some special construct that has a depends list similar to
> target. targets can depend on such a construct and add themselves
> to the depends list (the current code base).
+1, modulo the terminology.
> * allo
Hi,
I am fine with the current code base. In fact, I never experienced the
need for target-group(s), but I can imagine myself using them if they
are available.
Regards,
Antoine
Stefan Bodewig wrote:
before we get carried away with naming discussions ...
Currently I don't feel the
before we get carried away with naming discussions ...
Currently I don't feel there is consensus of what we'd like to see with
target-group (if anything at all). The options I see are
* have some sort of composite of targets that other targets can add
themselves to
* have so
On 2009-12-10, Jeff Sinclair wrote:
> We've implemented a common build template which other groups at the
> firm build upon. One issue we have had is providing a simple way for
> our users to plug in custom logic without having to copy Target
> definitions. We went about this b
Hi Stefan,
We've implemented a common build template which other groups at the firm build
upon. One issue we have had is providing a simple way for our users to plug in
custom logic without having to copy Target definitions. We went about this by
providing macro hooks which people
Hi,
this is just a description of what target-group in trunk currently is
and what it is not. I'll describe the implementation rather than the
initial phase concept as it is implemented in EasyAnt which uses a
custom ProjectHelper to implement its slightly different concept.
This mail serv
Regards,
Antoine
naresh123 wrote:
Hi All,
I am Writing automated Build script for running DBScript using ant .I
am Using ant apache-ant-1.7.1 and MYSQL5.1 .I wrote a target for running
the Triggers on the tables like this
Hi All,
I am Writing automated Build script for running DBScript using ant .I
am Using ant apache-ant-1.7.1 and MYSQL5.1 .I wrote a target for running
the Triggers on the tables like this
XXX.sql is the Script for
how to call a predefined target or macroin
>build.xml from Custom Ant task
>
>
>Thank You Jon, this rocks..
>
>instead of createTask() every time, is there a way to reuse the already
>existing one (either may be created by xml files or with in
>other script
>file..)
&
many times).
Regards,
Raja Nagendra Kumar
TejaSoft
--
View this message in context:
http://www.nabble.com/how-to-call-a-predefined-target-or-macroin-build.xml-from-Custom-Ant-task-tp25260761p25271525.html
Sent from the Ant - Dev mailing list archive at Nabble.com
Kumar [mailto:nagendra.r...@tejasoft.com]
>Gesendet: Mittwoch, 2. September 2009 20:25
>An: dev@ant.apache.org
>Betreff: Re: how to call a predefined target or macroin
>build.xml from Custom Ant task
>
>
>Hi,
>
>I see there is a way to execut target using
>getProje
Hi,
I see there is a way to execut target using getProject().executeTarget()..
but don't find a way to execute the macro. Any pointers pl.
Regards,
Nagendra
--
View this message in context:
http://www.nabble.com/how-to-call-a-predefined-target-or-macroin-build.xml-from-Custom-Ant
Hi,
I am looking to call a Macro defined in the project though custom task.
Similarly calling of target.
Both macro and target are defined the build.xml and my java based custom
task should be able to call it with min overhead.. i.e with the same
overhead as calling the macro from build.xml or
On Sat, Aug 1, 2009 at 9:55 AM, Raja Nagendra
Kumar wrote:
> in such context, I was expecting it show on the console skipping the target
> call copyPrepocessingFiles etc.
There's two parts to a target: its "body", and its dependencies.
A target's if/unless attributes
Ant 1.7.1 is printing the name of the target like this
copyPrepocessingFiles:
for a call to a target copyPrepocessingFiles, which is defined as
the target name gets printed as above even when the property
porting.friendly.enabled is not defined.
in such context, I was expecting it show on
My 2 cents:
I think it makes the structure more clear. Personally I do not like the (in
my opinion) bogus targets only for evaluating if a target should be executed
or not. I can see the principle design argument, but it feels like they
bloat my ant scripts and make them less easy to understand
On Thu, Apr 23, 2009 at 8:13 AM, Jeffrey E Care wrote:
> Off and on we've discussed more robust ways of determining target
> enablement, such as adding some type of EL syntax to if/unless.
>
> It dawned on me yesterday that we might already have the makings of a very
> robust
Off and on we've discussed more robust ways of determining target
enablement, such as adding some type of EL syntax to if/unless.
It dawned on me yesterday that we might already have the makings of a very
robust system: why not use conditions nested in targets to determine if
the targ
On 2008-11-28, Jean-Louis BOUDART <[EMAIL PROTECTED]> wrote:
> Any news on this point?
I've still not seen any argument that convinced me that the naming
rules for should be different, but that's just me.
On the target-group as composite side, I may start to understand it,
Any news on this point?
2008/11/24 Xavier Hanin <[EMAIL PROTECTED]>
> On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART <
> [EMAIL PROTECTED]> wrote:
>
> > >
> > > > In addition, as we use target-group to have more "genericity" we
>
I'm +1 for this solution
2008/11/26 Dominique Devienne <[EMAIL PROTECTED]>
> On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton <[EMAIL PROTECTED]>
> wrote:
> > Or you could just live with the verbosity of the target list, like I did,
> > and use naming convent
On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> Or you could just live with the verbosity of the target list, like I did,
> and use naming conventions in EasyAnt. I'm sure there are many other ways to
> address the issue.
One possible way would
Right. I see a "part-of" relationship of arbitrary depth as being best
implemented using a Composite design pattern. A target-group is a
composite for targets but is itself also a target.
The level idea was only an example off the top of my head, but in
thinking about it you are
I was asking to myself the same question : why only 2 levels?
I think you are right, we don't need different type of targets, what
we should have is a new type of relationship between targets : the
PartOf relationship that allow to plug a 'lower' level target INTO an
other targe
I am in the same boat as Stefan. I also don't understand yet why
target-groups are not just targets to the person running Ant.
What you appear to be arguing here is that there should be two levels to
Ant targets. But why just two? Why not three or four or five?
I've written bui
>> > > In addition, as we use target-group to have more "genericity" we
>> doesn't
>> > > want to have prefix on those "generic" targets.
>> >
>> > I'm afraid I don't understand this.
>> >
>> >
1 - 100 of 686 matches
Mail list logo
