You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2012/07/26 10:36:31 UTC
Defining easyant's high level target
Hi,
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
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: Defining easyant's high level target
Posted by Dridi Boukelmoune <dr...@zenika.com>.
Hi,
Indeed Maven doesn't have a "release" phase, I was talking about the
release plugin (which actually defaults to nothing).
But Maven has a specific scm tag in the pom which is used by the scm
plugin (which is used by the release plugin).
If you have a high level target named "release" I wouldn't agree with
a "release" plugin that would *automatically* perform some sort of
tagging *by convention*...
Dridi
On Fri, Aug 17, 2012 at 10:32 PM, Jean-Louis Boudart
<je...@gmail.com> wrote:
> The release target is a generic step where you can plug YOUR stuff.
> This "phase" doesn't exist in maven.
>
> By default, in easyant only a specific kind of ivypublish is preconfigured
> to this step.
> This ivy publication will set ivy status to release, and fix all variables,
> and dynamic revision in your ivy file.
>
> But you can still attach your custom targets to this phase.
>
> Like maven we will provide a plugin for doing SCM tags and branches, this
> plugin will be optionnal and could be plugged to release "phase". But you
> have no obligation to use it :).
>
> <troll>
> We find it more convenient to name it scm-svn or scm-git rather that
> release plugin :)
> </troll>
> Le 16 août 2012 18:43, "Dridi Boukelmoune" <dr...@zenika.com> a
> écrit :
>
>> Hi,
>>
>> Is the release target you describe bound to some sort of SCM process
>> (like maven does) ?
>> It seems like it's not the case, and it's fine. I would object to
>> explicit SCM in the build...
>>
>> Dridi
>>
>> On Wed, Aug 15, 2012 at 3:08 PM, Jean-Louis Boudart
>> <je...@gmail.com> wrote:
>> > I assume there is no objection :)
>> >
>> > 2012/7/26 Jean-Louis Boudart <je...@gmail.com>
>> >
>> >> Hi,
>> >>
>> >> 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
>> >> --
>> >> Jean Louis Boudart
>> >> Independent consultant
>> >> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>> >>
>> >
>> >
>> >
>> > --
>> > Jean Louis Boudart
>> > Independent consultant
>> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>>
>>
>> --
>> Dridi Boukelmoune
>> Développeur/Formateur
>>
>> GSM : +33 (0)6 17 91 14 23
>>
--
Dridi Boukelmoune
Développeur/Formateur
GSM : +33 (0)6 17 91 14 23
Re: Defining easyant's high level target
Posted by Jean-Louis Boudart <je...@gmail.com>.
The release target is a generic step where you can plug YOUR stuff.
This "phase" doesn't exist in maven.
By default, in easyant only a specific kind of ivypublish is preconfigured
to this step.
This ivy publication will set ivy status to release, and fix all variables,
and dynamic revision in your ivy file.
But you can still attach your custom targets to this phase.
Like maven we will provide a plugin for doing SCM tags and branches, this
plugin will be optionnal and could be plugged to release "phase". But you
have no obligation to use it :).
<troll>
We find it more convenient to name it scm-svn or scm-git rather that
release plugin :)
</troll>
Le 16 août 2012 18:43, "Dridi Boukelmoune" <dr...@zenika.com> a
écrit :
> Hi,
>
> Is the release target you describe bound to some sort of SCM process
> (like maven does) ?
> It seems like it's not the case, and it's fine. I would object to
> explicit SCM in the build...
>
> Dridi
>
> On Wed, Aug 15, 2012 at 3:08 PM, Jean-Louis Boudart
> <je...@gmail.com> wrote:
> > I assume there is no objection :)
> >
> > 2012/7/26 Jean-Louis Boudart <je...@gmail.com>
> >
> >> Hi,
> >>
> >> 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
> >> --
> >> Jean Louis Boudart
> >> Independent consultant
> >> Apache EasyAnt commiter http://incubator.apache.org/easyant/
> >>
> >
> >
> >
> > --
> > Jean Louis Boudart
> > Independent consultant
> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
>
>
> --
> Dridi Boukelmoune
> Développeur/Formateur
>
> GSM : +33 (0)6 17 91 14 23
>
Re: Defining easyant's high level target
Posted by Dridi Boukelmoune <dr...@zenika.com>.
Hi,
Is the release target you describe bound to some sort of SCM process
(like maven does) ?
It seems like it's not the case, and it's fine. I would object to
explicit SCM in the build...
Dridi
On Wed, Aug 15, 2012 at 3:08 PM, Jean-Louis Boudart
<je...@gmail.com> wrote:
> I assume there is no objection :)
>
> 2012/7/26 Jean-Louis Boudart <je...@gmail.com>
>
>> Hi,
>>
>> 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
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
--
Dridi Boukelmoune
Développeur/Formateur
GSM : +33 (0)6 17 91 14 23
Re: Defining easyant's high level target
Posted by Jean-Louis Boudart <je...@gmail.com>.
I assume there is no objection :)
2012/7/26 Jean-Louis Boudart <je...@gmail.com>
> Hi,
>
> 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
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/