incubator-easyant-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Louis Boudart (JIRA)" <j...@apache.org>
Subject [jira] [Created] (EASYANT-46) Define high level targets
Date Thu, 26 Jul 2012 11:48:34 GMT
Jean-Louis Boudart created EASYANT-46:
-----------------------------------------

             Summary: Define high level targets
                 Key: EASYANT-46
                 URL: https://issues.apache.org/jira/browse/EASYANT-46
             Project: EasyAnt
          Issue Type: New Feature
            Reporter: Jean-Louis Boudart
             Fix For: 0.9


As you should know we removed the concept of phases in favor of extensionPoint in EasyAnt.
This allow us to have a much more flexible and dynamic lifecycle.

But i'm still convinced we need to keep "high level targets". 
What the hell is that?
"high level targets" is a set of target usually called by end users. This should be common
to every buildtypes.
No ambiguity examples :

    clean : delete any artifacts from previous builds
    compile : compile the source code of the project (usually invoked by IDE)
    package : take the compiled code and package it in its distributable format, such as a
JAR
    test : run tests using a suitable unit testing framework. These tests should not require
the code be packaged or deployed

The idea is to have a very limited common target.


Do you see some other high level targets candidate ?

To answer you can check the old lifecycle [1].

I think we should add the following ones :

    integration-test : process and deploy the package if necessary into an environment where
integration tests can be run
    verify  : run any checks to verify the package is valid and meets quality criteria (test
+ integration-test)
    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 reports (checkstyle, cobertura, etc...)
    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

I'm not sure about publish-local and publish-shared names.

What do you think ?

[1] http://svn.apache.org/repos/asf/incubator/easyant/plugins/trunk/phases-std/src/main/resources/phases-std.ant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message