ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Louis BOUDART" <jeanlouis.boud...@gmail.com>
Subject Re: target-group committed
Date Thu, 20 Nov 2008 23:26:50 GMT
>
> > 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message