You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2008/11/19 13:47:43 UTC
target-group committed
Hi all,
svn revision 718943 contains target-group (without documentation) as a
special kind of target that must always be empty.
targets and target-groups have a new attribute target-group that can
be used to add the target(-group) to a named target-group that must
have been defined already[1]. Maybe this should be a comma-separeted
list of traget-groups to add to instead.
Dependenices are always appended.
I think I got the naming conventions of include right, but there will
be some import scenarios that haven't been covered (like the imporitng
build file naming a plain target the same as an imported
target-group).
Shout if I shall pull it again or if you don't like the
implementation.
Stefan
[1] sounds complex, but isn't. Take a look at
http://svn.apache.org/repos/asf/ant/core/trunk/src/tests/antunit/core/target-group-test.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-19, Stefan Bodewig <bo...@apache.org> wrote:
> Maybe this should be a comma-separeted list of traget-groups to add
> to instead.
[Maybe I should proof-read my mails before I hit C-c C-c.]
The target-group attribute now accepts a comma-separated list in svn
revision 719198.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
I'm +1 for this solution
2008/11/26 Dominique Devienne <dd...@gmail.com>
> On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton <br...@callenish.com>
> 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 be to provide an in-build-file hook to
> intercept the -p switch, and this hook (I envision a target) would
> then be responsible to display the help. Couple that with a new
> configurable task to generate the -p output, and then it's up to the
> user to select (via some kind of include/exclude) whatever targets are
> going to be listed.
>
> My builds used to all have a help target which <java>'d back into Ant
> on the same build file with the -p switch added. It's the same idea,
> but exposing a builtin task instead, and allowing to run that target
> when -p is specified, if it's hooked via for example a <project
> help-target="help">.
>
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: target-group committed
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton <br...@callenish.com> 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 be to provide an in-build-file hook to
intercept the -p switch, and this hook (I envision a target) would
then be responsible to display the help. Couple that with a new
configurable task to generate the -p output, and then it's up to the
user to select (via some kind of include/exclude) whatever targets are
going to be listed.
My builds used to all have a help target which <java>'d back into Ant
on the same build file with the -p switch added. It's the same idea,
but exposing a builtin task instead, and allowing to run that target
when -p is specified, if it's hooked via for example a <project
help-target="help">.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Bruce Atherton <br...@callenish.com>.
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 right that numeric levels would be a bad
choice. The reason I thought of using numbers was so that the lower
layers would implicitly contain the higher ones but it really is obscure
and arbitrary from the users perspective.
Another solution would be to create different "interfaces" onto the
build file for different types of users running Ant. A "visibility"
attribute on targets could be set to the names of interfaces that could
be requested and would list that target if you ran Ant with the
interface specified, e.g. "-p=developer". You would need some new tag if
you wanted "extends" behaviour, though.
Yet another solution would be to add an attribute to allow stripping
descriptions from imported and included targets. Then the user could
write different top-level build files for different classes of users,
each choosing which imported targets got to keep their descriptions.
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.
Gilles Scokart wrote:
> 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 target.
>
> But for the idea of numerical level, I think it is going too far into
> a strict layer decomposition. This might be too restrictive. Having
> a PartOf relationship allow to do strict layering elegantly, but there
> might be other usage to partOf.
> If the only benefits of a numerical layer is to hava a -p1 .. -pn
> options, then I think the benfit is too limited.
>
> Gilles
>
>
> 2008/11/25 Bruce Atherton <br...@callenish.com>:
>
>> 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 build systems this way in the past. Here is an example:
>>
>> Level 1 = top level targets that span multiple modules, depend on level 2
>> targets and add timestamps to logs. Description defined.
>> Level 2 = top level targets for a specific module, depend on level 3 targets
>> and add timestamps to logs. Description defined.
>> Level 3 = more granular targets that encapsulate reusable sets of
>> behaviour, depend on level 3 and 4 targets. No description.
>> Level 4 = fine-grained targets, depend only on initialization targets. Used
>> when you know exactly the state of your environment and want to do something
>> specific with no time wasted, like in a developer sandbox. Description
>> defined.
>> Level 5 = initialization targets. No description.
>>
>> I used naming conventions for targets to differentiate the levels. For
>> example, level 4 targets all ended with "-only" to indicate there were few
>> dependencies being run. There are other solutions, though. Perhaps targets
>> could have a "level" attribute and -projecthelp could take an optional
>> numeric parameter to indicate the level you want to see. Someone building a
>> module could run "ant -p2" to find out which targets were available to them.
>> A developer could run "ant -p4". To make things more user-friendly, EasyAnt
>> could define a standard set of levels and name them rather than using
>> numbers.
>>
>> That is just one idea. Regardless, I think a more general solution would be
>> better than treating target-groups in a special way, or even worse by adding
>> target-parts to the mix. But then again, I may be missing something.
>>
>> Jean-Louis BOUDART wrote:
>>
>>> I agree with Xavier a target-group is something at a higher level than a
>>> target.
>>>
>>> I think that the key feature of target-group is dependency injection but
>>> as
>>> Xavier says "if thread-group is the only way to have target dependency
>>> injection, then people may use it only for that, and complain about the
>>> distinction in project help".
>>> The fact is target-group is not only a way to have dependency management,
>>> but a "new way" to think your build-script.
>>>
>>> I guess for us target-group is useful to make build modules easily
>>> reusable
>>> in a standard build (with standard target-group), without requiring any
>>> specific orchestration.
>>> This means target-group allow you to have a kind of "generic target",
>>> that's
>>> why in EasyAnt we want to have separated help for generic targets
>>> (target-group) and specific target (normal target).
>>>
>>> In addition, as we use target-group to have more "genericity" we doesn't
>>> want to have prefix on those "generic" targets.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Gilles Scokart <gs...@gmail.com>.
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 target.
But for the idea of numerical level, I think it is going too far into
a strict layer decomposition. This might be too restrictive. Having
a PartOf relationship allow to do strict layering elegantly, but there
might be other usage to partOf.
If the only benefits of a numerical layer is to hava a -p1 .. -pn
options, then I think the benfit is too limited.
Gilles
2008/11/25 Bruce Atherton <br...@callenish.com>:
> 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 build systems this way in the past. Here is an example:
>
> Level 1 = top level targets that span multiple modules, depend on level 2
> targets and add timestamps to logs. Description defined.
> Level 2 = top level targets for a specific module, depend on level 3 targets
> and add timestamps to logs. Description defined.
> Level 3 = more granular targets that encapsulate reusable sets of
> behaviour, depend on level 3 and 4 targets. No description.
> Level 4 = fine-grained targets, depend only on initialization targets. Used
> when you know exactly the state of your environment and want to do something
> specific with no time wasted, like in a developer sandbox. Description
> defined.
> Level 5 = initialization targets. No description.
>
> I used naming conventions for targets to differentiate the levels. For
> example, level 4 targets all ended with "-only" to indicate there were few
> dependencies being run. There are other solutions, though. Perhaps targets
> could have a "level" attribute and -projecthelp could take an optional
> numeric parameter to indicate the level you want to see. Someone building a
> module could run "ant -p2" to find out which targets were available to them.
> A developer could run "ant -p4". To make things more user-friendly, EasyAnt
> could define a standard set of levels and name them rather than using
> numbers.
>
> That is just one idea. Regardless, I think a more general solution would be
> better than treating target-groups in a special way, or even worse by adding
> target-parts to the mix. But then again, I may be missing something.
>
> Jean-Louis BOUDART wrote:
>>
>> I agree with Xavier a target-group is something at a higher level than a
>> target.
>>
>> I think that the key feature of target-group is dependency injection but
>> as
>> Xavier says "if thread-group is the only way to have target dependency
>> injection, then people may use it only for that, and complain about the
>> distinction in project help".
>> The fact is target-group is not only a way to have dependency management,
>> but a "new way" to think your build-script.
>>
>> I guess for us target-group is useful to make build modules easily
>> reusable
>> in a standard build (with standard target-group), without requiring any
>> specific orchestration.
>> This means target-group allow you to have a kind of "generic target",
>> that's
>> why in EasyAnt we want to have separated help for generic targets
>> (target-group) and specific target (normal target).
>>
>> In addition, as we use target-group to have more "genericity" we doesn't
>> want to have prefix on those "generic" targets.
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Bruce Atherton <br...@callenish.com>.
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 build systems this way in the past. Here is an example:
Level 1 = top level targets that span multiple modules, depend on level
2 targets and add timestamps to logs. Description defined.
Level 2 = top level targets for a specific module, depend on level 3
targets and add timestamps to logs. Description defined.
Level 3 = more granular targets that encapsulate reusable sets of
behaviour, depend on level 3 and 4 targets. No description.
Level 4 = fine-grained targets, depend only on initialization targets.
Used when you know exactly the state of your environment and want to do
something specific with no time wasted, like in a developer sandbox.
Description defined.
Level 5 = initialization targets. No description.
I used naming conventions for targets to differentiate the levels. For
example, level 4 targets all ended with "-only" to indicate there were
few dependencies being run. There are other solutions, though. Perhaps
targets could have a "level" attribute and -projecthelp could take an
optional numeric parameter to indicate the level you want to see.
Someone building a module could run "ant -p2" to find out which targets
were available to them. A developer could run "ant -p4". To make things
more user-friendly, EasyAnt could define a standard set of levels and
name them rather than using numbers.
That is just one idea. Regardless, I think a more general solution would
be better than treating target-groups in a special way, or even worse by
adding target-parts to the mix. But then again, I may be missing something.
Jean-Louis BOUDART wrote:
> I agree with Xavier a target-group is something at a higher level than a
> target.
>
> I think that the key feature of target-group is dependency injection but as
> Xavier says "if thread-group is the only way to have target dependency
> injection, then people may use it only for that, and complain about the
> distinction in project help".
> The fact is target-group is not only a way to have dependency management,
> but a "new way" to think your build-script.
>
> I guess for us target-group is useful to make build modules easily reusable
> in a standard build (with standard target-group), without requiring any
> specific orchestration.
> This means target-group allow you to have a kind of "generic target", that's
> why in EasyAnt we want to have separated help for generic targets
> (target-group) and specific target (normal target).
>
> In addition, as we use target-group to have more "genericity" we doesn't
> want to have prefix on those "generic" targets.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-28, Jean-Louis BOUDART <je...@gmail.com> wrote:
> Any news on this point?
I've still not seen any argument that convinced me that the naming
rules for <include> should be different, but that's just me.
On the target-group as composite side, I may start to understand it,
but feel that we've been tackling the wrong way. Instead of madifying
depends, target-group should have a parts attribute that targets can
append to. Or something like that.
I haven't made up my mind on any of this. But like I said, it is just
me, don't wait for me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Any news on this point?
2008/11/24 Xavier Hanin <xa...@gmail.com>
> On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART <
> jeanlouis.boudart@gmail.com> wrote:
>
> > >
> > > > 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.
> > >
> > > One of your selling points for <include> was that the included build is
> > > self-contained and remains that way by prefixing all traget names and
> > > rewriting the depends lists.
> > >
> > > If we break that rule for some kind of target, the included build is
> > > suddenly open for modifications from the outside - including overrides
> > > of target-groups.
> > >
> > Again if we consider target-group as JUST a way to have target dependency
> > injection, this doesn't make sens.
> > In opposite if we consider that target-groups are toplevel target does't
> it
> > make sens to have prefix on target-group?
> > Example (using current HEAD revision):
> > Suppose you want to have a generic task called report
> > a.xml
> > <project name="A">
> > <target name="javadoc" target-group="report" description="generate
> > javadoc">
> > <echo>javadoc</echo>
> > </target>
> > ...
> > </project>
> >
> > b.xml
> > <project name="B">
> > <target name="junitreport" target-group="report" description="generate
> > junit
> > report">
> > <echo>junitreport</echo>
> > </target>
> > ...
> > </project>
> >
> > c.xml
> > <project name="C">
> > <target name="emma-report" description="generate emma report"
> > target-group="report">
> > <echo> emma report</echo>
> > </target>
> > ...
> > </project>
> >
> > phases.xml
> > <project name="phases">
> > <target-group name="report" description="generate all report for your
> > project" />
> > </project>
> >
> > build.xml
> > <project name="generic-build">
> > <import file="phase.xml"/>
> > <include file="a.xml" as="javadoc"/>
> > <include file="b.xml" as="junit"/>
> > <include file="c.xml" as="emma"/>
> > </project>
> >
> >
> > If you try to use "ant report" :
> > you have this message
> > "can't add target javadoc.javadoc to target-group javadoc.report because
> > the
> > target-group is unknown."
> >
> > IMHO a target-group should NEVER be prefixed, in a module it's possible
> to
> > assign a target to a phase which is not declared in the build module. It
> > makes the module dependent on the caller to declare the phase prior to
> the
> > use call, and as such becomes a requirement of the module.
> >
> >
> I would like to bring more attention to this, because I think Jean-Louis
> makes a very good point here.
> IMO joining a target group for a target should be possible for a target
> group which is defined in a build file "including" the build file in which
> the target itself is defined.
>
> So maybe name resolution of a target-group when a target declares to join a
> target-group (with <target name="foo" target-group="bar" />) in an included
> file should first look for the prefixed name (as it is currently
> implemented) and then if it doesn't exist, try to look for the non prefixed
> name.
>
> WDYT?
>
> --
> Xavier Hanin - 4SH France
> BordeauxJUG co leader - http://www.bordeauxjug.org/
> Blogger - http://xhab.blogspot.com/
> Apache Ivy Creator - http://ant.apache.org/ivy/
>
Re: target-group committed
Posted by Xavier Hanin <xa...@gmail.com>.
On Fri, Nov 21, 2008 at 12:26 AM, Jean-Louis BOUDART <
jeanlouis.boudart@gmail.com> wrote:
> >
> > > 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.
> >
> > One of your selling points for <include> was that the included build is
> > self-contained and remains that way by prefixing all traget names and
> > rewriting the depends lists.
> >
> > If we break that rule for some kind of target, the included build is
> > suddenly open for modifications from the outside - including overrides
> > of target-groups.
> >
> Again if we consider target-group as JUST a way to have target dependency
> injection, this doesn't make sens.
> In opposite if we consider that target-groups are toplevel target does't it
> make sens to have prefix on target-group?
> Example (using current HEAD revision):
> Suppose you want to have a generic task called report
> a.xml
> <project name="A">
> <target name="javadoc" target-group="report" description="generate
> javadoc">
> <echo>javadoc</echo>
> </target>
> ...
> </project>
>
> b.xml
> <project name="B">
> <target name="junitreport" target-group="report" description="generate
> junit
> report">
> <echo>junitreport</echo>
> </target>
> ...
> </project>
>
> c.xml
> <project name="C">
> <target name="emma-report" description="generate emma report"
> target-group="report">
> <echo> emma report</echo>
> </target>
> ...
> </project>
>
> phases.xml
> <project name="phases">
> <target-group name="report" description="generate all report for your
> project" />
> </project>
>
> build.xml
> <project name="generic-build">
> <import file="phase.xml"/>
> <include file="a.xml" as="javadoc"/>
> <include file="b.xml" as="junit"/>
> <include file="c.xml" as="emma"/>
> </project>
>
>
> If you try to use "ant report" :
> you have this message
> "can't add target javadoc.javadoc to target-group javadoc.report because
> the
> target-group is unknown."
>
> IMHO a target-group should NEVER be prefixed, in a module it's possible to
> assign a target to a phase which is not declared in the build module. It
> makes the module dependent on the caller to declare the phase prior to the
> use call, and as such becomes a requirement of the module.
>
>
I would like to bring more attention to this, because I think Jean-Louis
makes a very good point here.
IMO joining a target group for a target should be possible for a target
group which is defined in a build file "including" the build file in which
the target itself is defined.
So maybe name resolution of a target-group when a target declares to join a
target-group (with <target name="foo" target-group="bar" />) in an included
file should first look for the prefixed name (as it is currently
implemented) and then if it doesn't exist, try to look for the non prefixed
name.
WDYT?
--
Xavier Hanin - 4SH France
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-21, Jean-Louis BOUDART <je...@gmail.com> wrote:
> Suppose you have a build with 10 target-group which represent 10 different
> generic step of your build process (like compile / package/ test/ etc...)
Then I'd consider this to be the public API and <import> it.
> And behind you have 30 submodules that have one or many target associated
> (or not) to that target-groups
> (compile-java,compile-scala,compile-whatever,javadoc,etc....)
They'd be implementation details of the public API and I'd <include>
them.
> As target-group are "top-level target", as a user i would prefer to see
> target-group separated instead of having to lookup at ALL target available.
So you are really asking for a way to suppress the targets that are
merely implementation details, or to de-emphasize them. What you
really want is a distinction between "public" targets and their
implementations.
This distiction isn't necessarily the same as the one between targets
and target-groups. I coud very well envision "public" targets and
"not-so-public" target-groups.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
>
> > The fact is target-group is not only a way to have dependency management,
> > but a "new way" to think your build-script.
>
> Yes, but only for the person who writes the build file, not the one
> who uses it. -projecthelp is for the user.
>
> > I guess for us target-group is useful to make build modules easily
> reusable
> > in a standard build (with standard target-group), without requiring any
> > specific orchestration.
> > This means target-group allow you to have a kind of "generic target",
> that's
> > why in EasyAnt we want to have separated help for generic targets
> > (target-group) and specific target (normal target).
>
> Why would the user care whether she invokes a generic or specific
> target?
>
Suppose you have a build with 10 target-group which represent 10 different
generic step of your build process (like compile / package/ test/ etc...)
And behind you have 30 submodules that have one or many target associated
(or not) to that target-groups
(compile-java,compile-scala,compile-whatever,javadoc,etc....)
As target-group are "top-level target", as a user i would prefer to see
target-group separated instead of having to lookup at ALL target available.
In the case where target and target-group are mixed how would you (as a
user) make the difference of what is a TOP level target (ie a generic task)
and a specific target? I guess usign "ant compile" has MORE consequences
than using "ant compile-java".
Maybe my example is not enough revelent :'(
Here is a short example of EasyAnt project help :
Main phases:
compile compile the source code of the project
generate-resources generate resources for inclusion in the package
generate-sources generate any source code for inclusion in
compilation
integration-test process and deploy the package if necessary
into an environment where integration tests can be run
package take the compiled code and package it in its
distributable format, such as a JAR.
post-integration-test perform actions required after integration
tests have been executed. This may including cleaning up the environment
pre-integration-test perform actions required before integration
tests are executed. This may involve things such as setting up the required
environment
prepare-package perform any operations necessary to prepare a
package before the actual packaging. This often results in an unpacked,
processed version of the package
process-classes post-process the generated files from
compilation, for example to do bytecode enhancement on Java classes
process-resources copy and process the resources into the
destination directory, ready for packaging
process-sources process the source code, for example to filter
any values
provision supply provision required by this project
publish-local publish the package into the local repository,
for use as a dependency in other projects locally
publish-shared done in an integration environment, copies the
final package to the remote repository for sharing with other developers and
projects
release done in an integration or release environment,
copies the final package to the remote repository for sharing with other
developers and projects
report generate report
test run tests using a suitable unit testing
framework. These tests should not require the code be packaged or deployed
test-compile compile the test source code into the test
destination directory
test-generate-resources create resources for testing
test-generate-sources generate any test source code for inclusion in
compilation
test-process-resources copy and process the resources into the test
destination directory
test-process-sources process the test source code, for example to
filter any values
test-provision supply provision required to test this project
validate validate the project is correct and all
necessary information is available
verify run any checks to verify the package is valid
and meets quality criteria
Main targets:
checkstyle:checkstyle generate checkstyle report
clean:clean clean project
doc:documentation generate documentation
emma:emma generate emma covera report
jar:jar package project as a JAR
javadoc:javadoc generate javadoc report for main classes and
test classes
lib-resolve resolve and retrieve dependencies with ivy
lib:common-ivy:clean-cache clean the ivy cache
lib:common-ivy:clean-lib clean the project libraries directory
lib:common-ivy:report generate dependencies report
publish:clean-local cleans the local repository
run:run run the application
source:main package main source as a JAR
source:test package test source as a JAR
test/skip skip tests
In this example there is more target-group than "public" target but this
could give you an idea of WHY i don't want to have targets and phase mixed
:)
Maybe this i more pertinent to be in EasyAnt instead of ant-core, but i
think we should consider it :p
>
>
> > 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.
>
> One of your selling points for <include> was that the included build is
> self-contained and remains that way by prefixing all traget names and
> rewriting the depends lists.
>
> If we break that rule for some kind of target, the included build is
> suddenly open for modifications from the outside - including overrides
> of target-groups.
>
Again if we consider target-group as JUST a way to have target dependency
injection, this doesn't make sens.
In opposite if we consider that target-groups are toplevel target does't it
make sens to have prefix on target-group?
Example (using current HEAD revision):
Suppose you want to have a generic task called report
a.xml
<project name="A">
<target name="javadoc" target-group="report" description="generate javadoc">
<echo>javadoc</echo>
</target>
...
</project>
b.xml
<project name="B">
<target name="junitreport" target-group="report" description="generate junit
report">
<echo>junitreport</echo>
</target>
...
</project>
c.xml
<project name="C">
<target name="emma-report" description="generate emma report"
target-group="report">
<echo> emma report</echo>
</target>
...
</project>
phases.xml
<project name="phases">
<target-group name="report" description="generate all report for your
project" />
</project>
build.xml
<project name="generic-build">
<import file="phase.xml"/>
<include file="a.xml" as="javadoc"/>
<include file="b.xml" as="junit"/>
<include file="c.xml" as="emma"/>
</project>
If you try to use "ant report" :
you have this message
"can't add target javadoc.javadoc to target-group javadoc.report because the
target-group is unknown."
IMHO a target-group should NEVER be prefixed, in a module it's possible to
assign a target to a phase which is not declared in the build module. It
makes the module dependent on the caller to declare the phase prior to the
use call, and as such becomes a requirement of the module.
What do you think about this? :p
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Jean-Louis BOUDART <je...@gmail.com> wrote:
> The fact is target-group is not only a way to have dependency management,
> but a "new way" to think your build-script.
Yes, but only for the person who writes the build file, not the one
who uses it. -projecthelp is for the user.
> I guess for us target-group is useful to make build modules easily reusable
> in a standard build (with standard target-group), without requiring any
> specific orchestration.
> This means target-group allow you to have a kind of "generic target", that's
> why in EasyAnt we want to have separated help for generic targets
> (target-group) and specific target (normal target).
Why would the user care whether she invokes a generic or specific
target?
> 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.
One of your selling points for <include> was that the included build is
self-contained and remains that way by prefixing all traget names and
rewriting the depends lists.
If we break that rule for some kind of target, the included build is
suddenly open for modifications from the outside - including overrides
of target-groups.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
I agree with Xavier a target-group is something at a higher level than a
target.
I think that the key feature of target-group is dependency injection but as
Xavier says "if thread-group is the only way to have target dependency
injection, then people may use it only for that, and complain about the
distinction in project help".
The fact is target-group is not only a way to have dependency management,
but a "new way" to think your build-script.
I guess for us target-group is useful to make build modules easily reusable
in a standard build (with standard target-group), without requiring any
specific orchestration.
This means target-group allow you to have a kind of "generic target", that's
why in EasyAnt we want to have separated help for generic targets
(target-group) and specific target (normal target).
In addition, as we use target-group to have more "genericity" we doesn't
want to have prefix on those "generic" targets.
Re: target-group committed
Posted by Gilles Scokart <gs...@gmail.com>.
I think if you want to show nice dynamic help, with rich (understand
specific) logic to select what to display, you should probably use an
help module in EasyAnt, (I mean an imported help build file exposing
an help target ot target-group).
Gilles
2008/11/20 Xavier Hanin <xa...@gmail.com>:
> On Thu, Nov 20, 2008 at 6:22 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2008-11-19, Jean-Louis BOUDART <je...@gmail.com> wrote:
>>
>> > I just have two questions :
>>
>> I knew I didn't reproduce all of EasyAnt's patch 8-)
>>
>> > - Does prefix of <import> / <include> make sense on target-group? Or
>> > should we consider target-group as an "abstract target" that is never
>> > prefixed?
>>
>> To me target-groups should be treated just like targets by import and
>> include so I made the same prefix rules apply. Why would you want to
>> have different rules? Wouldn't that defeat the purpose of include?
>>
>> > - When displaying projecthelp should we have target and target-group
>> > mixed? or should we have a distinction?
>>
>> From the user's (the one running the build not writing the build file)
>> there shouldn't really be any difference so I wouldn't report them
>> separately. That may be just me.
>
> I'm not sure if it's directly related to thread-group, or to the usage made
> of thread-group in EasyAnt: when using thread-groups as "phases", it is
> better to have them isolated in project help, even from a user point of
> view. But when used only as a way to inject target dependencies, the user
> doesn't have to know about that.
>
> But maybe the point is that we should isolate the thread-group concept from
> target dependency injection. IMO a thread-group is something at a higher
> level than a target (as the name implies), something which was missing in
> Ant IMO, especially for large build systems based on Ant. As such I think it
> deserves isolation in project help. But if thread-group is the only way to
> have target dependency injection, then people may use it only for that, and
> complain about the distinction in project help. So maybe we should introduce
> target dependency injection for regular targets too? I'm not sure how useful
> it is though, just throwing ideas.
>
> Xavier
>
>
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Xavier Hanin - 4SH France
> BordeauxJUG co leader - http://www.bordeauxjug.org/
> Blogger - http://xhab.blogspot.com/
> Apache Ivy Creator - http://ant.apache.org/ivy/
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
I think this is a typo he wanted to say target-group IMHO :p
2008/11/20 Stefan Bodewig <bo...@apache.org>
> On 2008-11-20, Xavier Hanin <xa...@gmail.com> wrote:
>
> > I'm not sure if it's directly related to thread-group, or to the usage
> made
> > of thread-group in EasyAnt:
>
> could you please explain what a thread-group in EasyAnt is/does?
>
> Thanks
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Xavier Hanin <xa...@gmail.com> wrote:
> I'm not sure if it's directly related to thread-group, or to the usage made
> of thread-group in EasyAnt:
could you please explain what a thread-group in EasyAnt is/does?
Thanks
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Nov 20, 2008 at 6:22 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-19, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
> > I just have two questions :
>
> I knew I didn't reproduce all of EasyAnt's patch 8-)
>
> > - Does prefix of <import> / <include> make sense on target-group? Or
> > should we consider target-group as an "abstract target" that is never
> > prefixed?
>
> To me target-groups should be treated just like targets by import and
> include so I made the same prefix rules apply. Why would you want to
> have different rules? Wouldn't that defeat the purpose of include?
>
> > - When displaying projecthelp should we have target and target-group
> > mixed? or should we have a distinction?
>
> From the user's (the one running the build not writing the build file)
> there shouldn't really be any difference so I wouldn't report them
> separately. That may be just me.
I'm not sure if it's directly related to thread-group, or to the usage made
of thread-group in EasyAnt: when using thread-groups as "phases", it is
better to have them isolated in project help, even from a user point of
view. But when used only as a way to inject target dependencies, the user
doesn't have to know about that.
But maybe the point is that we should isolate the thread-group concept from
target dependency injection. IMO a thread-group is something at a higher
level than a target (as the name implies), something which was missing in
Ant IMO, especially for large build systems based on Ant. As such I think it
deserves isolation in project help. But if thread-group is the only way to
have target dependency injection, then people may use it only for that, and
complain about the distinction in project help. So maybe we should introduce
target dependency injection for regular targets too? I'm not sure how useful
it is though, just throwing ideas.
Xavier
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - 4SH France
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: target-group committed
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-19, Jean-Louis BOUDART <je...@gmail.com> wrote:
> I just have two questions :
I knew I didn't reproduce all of EasyAnt's patch 8-)
> - Does prefix of <import> / <include> make sense on target-group? Or
> should we consider target-group as an "abstract target" that is never
> prefixed?
To me target-groups should be treated just like targets by import and
include so I made the same prefix rules apply. Why would you want to
have different rules? Wouldn't that defeat the purpose of include?
> - When displaying projecthelp should we have target and target-group
> mixed? or should we have a distinction?
>From the user's (the one running the build not writing the build file)
there shouldn't really be any difference so I wouldn't report them
separately. That may be just me.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Hum little mistake in my explanation :
By typing "ant -p"
1) Case of target and target-group mixed project help will display something
like :*Available target :*
compile --> compile the current projet
org.apache.ant#jar.compile-java --> compile java classes on the current
project
package --> package the current project
org.apache.ant#jar.package-jar --> package this project as a jar
2) Case when target and target-group are separated
*Available target-group :*
compile-java --> compile java classes on the current project
package-jar --> package this project as a jar
*Available target :*
compile --> compile the current projet
package --> package the current project
2008/11/19 Jean-Louis BOUDART <je...@gmail.com>
>
> svn revision 718943 contains target-group (without documentation) as a
>> special kind of target that must always be empty.
>
> targets and target-groups have a new attribute target-group that can
>> be used to add the target(-group) to a named target-group that must
>> have been defined already[1]. Maybe this should be a comma-separeted
>> list of traget-groups to add to instead.
>>
>> Dependenices are always appended.
>
> Nice !
>
>
>
>> I think I got the naming conventions of include right, but there will
>> be some import scenarios that haven't been covered (like the imporitng
>> build file naming a plain target the same as an imported
>> target-group).
>
> I just have two questions :
>
> - Does prefix of <import> / <include> make sense on target-group? Or
> should we consider target-group as an "abstract target" that is never
> prefixed?
> - When displaying projecthelp should we have target and target-group
> mixed? or should we have a distinction?
>
> Exemple :
> <project name="org.apache.ant#jar">
> <target name="compile-java" target-group="compile"
> description="compile java classes on the current project" >
> ....
> </target>
> <target name="package-jar" target-group="package"
> description="package this project as a jar">
> ....
> </target>
> </project>
> <project name="generic">
> <target-group name="compile" description="compile the current
> projet"/>
> <target-group name="package description="package the current
> project" depends="compile"/>
> <include file="/path/to/jar.xml" as="jar" />
> </project>
> By typing "ant -p"
> 1) Case of target and target-group mixed project help will display
> something like :*Available target :*
> compile --> compile the current projet
> compile-java --> compile java classes on the current project
> package --> package the current project
> package-jar --> package this project as a jar
>
> 2) Case when target and target-group are separated
> *Available target-group :*
> compile-java --> compile java classes on the current project
> package-jar --> package this project as a jar
> *Available target :*
> compile --> compile the current projet
> package --> package the current project
>
>
> Regards
> Jean Louis
>
Re: target-group committed
Posted by Jean-Louis BOUDART <je...@gmail.com>.
> svn revision 718943 contains target-group (without documentation) as a
> special kind of target that must always be empty.
targets and target-groups have a new attribute target-group that can
> be used to add the target(-group) to a named target-group that must
> have been defined already[1]. Maybe this should be a comma-separeted
> list of traget-groups to add to instead.
>
> Dependenices are always appended.
Nice !
> I think I got the naming conventions of include right, but there will
> be some import scenarios that haven't been covered (like the imporitng
> build file naming a plain target the same as an imported
> target-group).
I just have two questions :
- Does prefix of <import> / <include> make sense on target-group? Or
should we consider target-group as an "abstract target" that is never
prefixed?
- When displaying projecthelp should we have target and target-group
mixed? or should we have a distinction?
Exemple :
<project name="org.apache.ant#jar">
<target name="compile-java" target-group="compile"
description="compile java classes on the current project" >
....
</target>
<target name="package-jar" target-group="package"
description="package this project as a jar">
....
</target>
</project>
<project name="generic">
<target-group name="compile" description="compile the current
projet"/>
<target-group name="package description="package the current
project" depends="compile"/>
<include file="/path/to/jar.xml" as="jar" />
</project>
By typing "ant -p"
1) Case of target and target-group mixed project help will display something
like :*Available target :*
compile --> compile the current projet
compile-java --> compile java classes on the current project
package --> package the current project
package-jar --> package this project as a jar
2) Case when target and target-group are separated
*Available target-group :*
compile-java --> compile java classes on the current project
package-jar --> package this project as a jar
*Available target :*
compile --> compile the current projet
package --> package the current project
Regards
Jean Louis