You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-commits@incubator.apache.org by "Jean-Louis Boudart (JIRA)" <ji...@apache.org> on 2012/07/26 11:48:34 UTC

[jira] [Created] (EASYANT-46) Define high level targets

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