[myfaces-builder-plugin] can we do a release of it?

[Leonardo Uribe]

Hi

I think that myfaces-builder-plugin has been very well tested so we can release a first version of this tool.

Is there any task left?

regards

Leonardo Uribe

Leonardo Uribe schrieb:
> Hi
>
> I think that myfaces-builder-plugin has been very well tested so we
> can release a first version of this tool.
>
> Is there any task left?
I think there is still a fair bit of work that could be done on the
plugin. However I don't see any reason why we can't make a release now.

Hmm..by the way, I just noticed that the pom does not specify a
<version> tag. So it is inheriting that from its parent, and therefore
existing snapshots are all 1.0.1-SNAPSHOT which is rather odd for a
project that has never been released. What version number will be used
for the first release?

The parent pom does need to be released first, and that currently
depends on the new myfaces-master-pom which depends on the new
checkstyle module. The release process for the master pom and checkstyle
is currently in progress; there are now enough +1s so I will finish the
release of these tonight. That's a little short of the recommended 72
hours since the RC announcement (only 48 hours), but these modules are
really only internal so I hope no-one will be annoyed by that.


Regards,
Simon

[Leonardo Uribe]

On Fri, Jul 11, 2008 at 2:56 AM, simon.kitching@... <simon.kitching@...> wrote:

Leonardo Uribe schrieb:

Hi

I think that myfaces-builder-plugin has been very well tested so we can release a first version of this tool.

Is there any task left?

I think there is still a fair bit of work that could be done on the plugin. However I don't see any reason why we can't make a release now.

Hmm..by the way, I just noticed that the pom does not specify a <version> tag. So it is inheriting that from its parent, and therefore existing snapshots are all 1.0.1-SNAPSHOT which is rather odd for a project that has never been released. What version number will be used for the first release?

Since there was only one release of myfaces build tools, maybe we can release individually myfaces-builder-plugin and myfaces-builder-annotations, so the release number could be 1.0.0. But I feel better is we release all plugins buildtools plugin (1.0.1). A version number is just a number, no?.
 

The parent pom does need to be released first, and that currently depends on the new myfaces-master-pom which depends on the new checkstyle module. The release process for the master pom and checkstyle is currently in progress; there are now enough +1s so I will finish the release of these tonight. That's a little short of the recommended 72 hours since the RC announcement (only 48 hours), but these modules are really only internal so I hope no-one will be annoyed by that.


Regards,
Simon

On Fri, 2008-07-11 at 13:46 -0500, Leonardo Uribe wrote:

>
>
> On Fri, Jul 11, 2008 at 2:56 AM, simon.kitching@...
> <simon.kitching@...> wrote:
>         Leonardo Uribe schrieb:
>        
>                 Hi
>                
>                 I think that myfaces-builder-plugin has been very well
>                 tested so we can release a first version of this tool.
>                
>                 Is there any task left?
>         I think there is still a fair bit of work that could be done
>         on the plugin. However I don't see any reason why we can't
>         make a release now.
>        
>         Hmm..by the way, I just noticed that the pom does not specify
>         a <version> tag. So it is inheriting that from its parent, and
>         therefore existing snapshots are all 1.0.1-SNAPSHOT which is
>         rather odd for a project that has never been released. What
>         version number will be used for the first release?
>
> Since there was only one release of myfaces build tools, maybe we can
> release individually myfaces-builder-plugin and
> myfaces-builder-annotations, so the release number could be 1.0.0. But
> I feel better is we release all plugins buildtools plugin (1.0.1). A
> version number is just a number, no?.

I don't think it makes any sense to release the whole set of myfaces
plugins. Code shouldn't be released that hasn't been tested, and there
is no way that we can retest every one of those plugins now.

I'm *guessing* that the original argument for releasing all these at
once is that they were all needed for a trinidad release, and that if
the trinidad release built and ran ok, then that was sufficient testing
to prove that the plugins were ok.

That's a reasonable arguments for plugins that have only one purpose
(build trinidad), and are never expected to be used in any other
situation. But that's certainly not the case for the
myfaces-builder-plugin. It is:
(a) used by a number of different myfaces projects, and
(b) theoretically useable by non-myfaces projects

So IMO it needs its own release cycle. And I would suggest that the
other plugins be managed the same way to; in the next version of
trinidad, a few of these plugins might need modifications but not all,
and it would be just crazy to re-release plugins that have not changed
at all.

This is consistent with what we do elsewhere. Myfaces Core api+impl are
released together because it makes no sense to do anything else. But
Orchestra core and core15 are released independently, as they are NOT
tightly coupled.

Just for reference, the plugins that currently have 1.0.0 releases are:
  myfaces-faces-plugin
  myfaces-i18n-plugin
  myfaces-javacc-plugin
  myfaces-javascript-plugin
  myfaces-jdev-plugin
  myfaces-tagdoc-plugin
  myfaces-wagon-plugin
  myfaces-xrts-plugin
and were all released simultaneously on 2008-04-20.

I would suggest we do this:
* do a 1.0.1 release of the parent pom
* add an explicit <version> to the pom of every plugin (initially set to
1.0.1-SNAPSHOT) (and also set parent pom version to 1.0.1).
* create a RELEASE-NOTES.txt file for myfaces-builder-plugin explaining
why the first release is numbered 1.0.1
* do a first release of myfaces-builder-plugin as version 1.0.1

Any other plugins that need to be modified and released should then be
released individually as needed.

(NB: we should use 1.0.1 as the first release number for
myfaces-builder-plugin because we have already been creating
1.0.1-SNAPSHOT versions in the apache snapshot repo, as the version
number was being inherited from the parent pom).

>  
>        
>         The parent pom does need to be released first, and that
>         currently depends on the new myfaces-master-pom which depends
>         on the new checkstyle module. The release process for the
>         master pom and checkstyle is currently in progress; there are
>         now enough +1s so I will finish the release of these tonight.
>         That's a little short of the recommended 72 hours since the RC
>         announcement (only 48 hours), but these modules are really
>         only internal so I hope no-one will be annoyed by that.

Regards,
Simon

>

[Leonardo Uribe]

On Sat, Jul 12, 2008 at 5:24 PM, simon <simon.kitching@...> wrote:

On Fri, 2008-07-11 at 13:46 -0500, Leonardo Uribe wrote:
>
>
> On Fri, Jul 11, 2008 at 2:56 AM, simon.kitching@...
> <simon.kitching@...> wrote:
>         Leonardo Uribe schrieb:
>
>                 Hi
>
>                 I think that myfaces-builder-plugin has been very well
>                 tested so we can release a first version of this tool.
>
>                 Is there any task left?
>         I think there is still a fair bit of work that could be done
>         on the plugin. However I don't see any reason why we can't
>         make a release now.
>
>         Hmm..by the way, I just noticed that the pom does not specify
>         a <version> tag. So it is inheriting that from its parent, and
>         therefore existing snapshots are all 1.0.1-SNAPSHOT which is
>         rather odd for a project that has never been released. What
>         version number will be used for the first release?
>
> Since there was only one release of myfaces build tools, maybe we can
> release individually myfaces-builder-plugin and
> myfaces-builder-annotations, so the release number could be 1.0.0. But
> I feel better is we release all plugins buildtools plugin (1.0.1). A
> version number is just a number, no?.

I don't think it makes any sense to release the whole set of myfaces
plugins. Code shouldn't be released that hasn't been tested, and there
is no way that we can retest every one of those plugins now.

I'm *guessing* that the original argument for releasing all these at
once is that they were all needed for a trinidad release, and that if
the trinidad release built and ran ok, then that was sufficient testing
to prove that the plugins were ok.

That's a reasonable arguments for plugins that have only one purpose
(build trinidad), and are never expected to be used in any other
situation. But that's certainly not the case for the
myfaces-builder-plugin. It is:
(a) used by a number of different myfaces projects, and
(b) theoretically useable by non-myfaces projects

So IMO it needs its own release cycle. And I would suggest that the
other plugins be managed the same way to; in the next version of
trinidad, a few of these plugins might need modifications but not all,
and it would be just crazy to re-release plugins that have not changed
at all.

This is consistent with what we do elsewhere. Myfaces Core api+impl are
released together because it makes no sense to do anything else. But
Orchestra core and core15 are released independently, as they are NOT
tightly coupled.

Just for reference, the plugins that currently have 1.0.0 releases are:
 myfaces-faces-plugin
 myfaces-i18n-plugin
 myfaces-javacc-plugin
 myfaces-javascript-plugin
 myfaces-jdev-plugin
 myfaces-tagdoc-plugin
 myfaces-wagon-plugin
 myfaces-xrts-plugin
and were all released simultaneously on 2008-04-20.

I would suggest we do this:
* do a 1.0.1 release of the parent pom
* add an explicit <version> to the pom of every plugin (initially set to
1.0.1-SNAPSHOT) (and also set parent pom version to 1.0.1).

I don't know how  to release a parent pom only. Should this be done manually?

* create a RELEASE-NOTES.txt file for myfaces-builder-plugin explaining
why the first release is numbered 1.0.1
* do a first release of myfaces-builder-plugin as version 1.0.1

Any other plugins that need to be modified and released should then be
released individually as needed.

It's ok, since in that case the parent pom is already released.
 

(NB: we should use 1.0.1 as the first release number for
myfaces-builder-plugin because we have already been creating
1.0.1-SNAPSHOT versions in the apache snapshot repo, as the version
number was being inherited from the parent pom).

>
>
>         The parent pom does need to be released first, and that
>         currently depends on the new myfaces-master-pom which depends
>         on the new checkstyle module. The release process for the
>         master pom and checkstyle is currently in progress; there are
>         now enough +1s so I will finish the release of these tonight.
>         That's a little short of the recommended 72 hours since the RC
>         announcement (only 48 hours), but these modules are really
>         only internal so I hope no-one will be annoyed by that.

Regards,
Simon

>

Leonardo Uribe schrieb:

>
>
> On Sat, Jul 12, 2008 at 5:24 PM, simon <simon.kitching@...
> <mailto:simon.kitching@...>> wrote:
>
>
>     On Fri, 2008-07-11 at 13:46 -0500, Leonardo Uribe wrote:
>     >
>     >
>     > On Fri, Jul 11, 2008 at 2:56 AM, simon.kitching@...
>     <mailto:simon.kitching@...>
>     > <simon.kitching@... <mailto:simon.kitching@...>> wrote:
>     >         Leonardo Uribe schrieb:
>     >
>     >                 Hi
>     >
>     >                 I think that myfaces-builder-plugin has been
>     very well
>     >                 tested so we can release a first version of this
>     tool.
>     >
>     >                 Is there any task left?
>     >         I think there is still a fair bit of work that could be done
>     >         on the plugin. However I don't see any reason why we can't
>     >         make a release now.
>     >
>     >         Hmm..by the way, I just noticed that the pom does not
>     specify
>     >         a <version> tag. So it is inheriting that from its
>     parent, and
>     >         therefore existing snapshots are all 1.0.1-SNAPSHOT which is
>     >         rather odd for a project that has never been released. What
>     >         version number will be used for the first release?
>     >
>     > Since there was only one release of myfaces build tools, maybe
>     we can
>     > release individually myfaces-builder-plugin and
>     > myfaces-builder-annotations, so the release number could be
>     1.0.0. <http://1.0.0.> But
>     > I feel better is we release all plugins buildtools plugin (1.0.1). A
>     > version number is just a number, no?.
>
>     I don't think it makes any sense to release the whole set of myfaces
>     plugins. Code shouldn't be released that hasn't been tested, and there
>     is no way that we can retest every one of those plugins now.
>
>     I'm *guessing* that the original argument for releasing all these at
>     once is that they were all needed for a trinidad release, and that if
>     the trinidad release built and ran ok, then that was sufficient
>     testing
>     to prove that the plugins were ok.
>
>     That's a reasonable arguments for plugins that have only one purpose
>     (build trinidad), and are never expected to be used in any other
>     situation. But that's certainly not the case for the
>     myfaces-builder-plugin. It is:
>     (a) used by a number of different myfaces projects, and
>     (b) theoretically useable by non-myfaces projects
>
>     So IMO it needs its own release cycle. And I would suggest that the
>     other plugins be managed the same way to; in the next version of
>     trinidad, a few of these plugins might need modifications but not all,
>     and it would be just crazy to re-release plugins that have not changed
>     at all.
>
>     This is consistent with what we do elsewhere. Myfaces Core
>     api+impl are
>     released together because it makes no sense to do anything else. But
>     Orchestra core and core15 are released independently, as they are NOT
>     tightly coupled.
>
>     Just for reference, the plugins that currently have 1.0.0 releases
>     are:
>      myfaces-faces-plugin
>      myfaces-i18n-plugin
>      myfaces-javacc-plugin
>      myfaces-javascript-plugin
>      myfaces-jdev-plugin
>      myfaces-tagdoc-plugin
>      myfaces-wagon-plugin
>      myfaces-xrts-plugin
>     and were all released simultaneously on 2008-04-20.
>
>     I would suggest we do this:
>     * do a 1.0.1 release of the parent pom
>     * add an explicit <version> to the pom of every plugin (initially
>     set to
>     1.0.1-SNAPSHOT) (and also set parent pom version to 1.0.1).
>
>
> I don't know how  to release a parent pom only. Should this be done
> manually?

I don't know how to use the maven-release-plugin, so can't comment :-).

But releasing manually is easy enough, esp. for a pom.

An alternative is to split things up so that the parent pom (the pom
that other modules inherit from) is not the "module pom" (the one used
to drive "bulk builds" of nested directories). A subdirectory can be
created, the existing pom moved down into it, and a new trivial pom
created in the base directory that just has <module> tags in it. I don't
see any need to change the artifactId for the parent pom, so AFAIK
simply moving it within svn should not break anything.

For example, the main myfaces pom is in its own subdir, and has no
<module> tags.

The Orchestra code is also set up like this, with the parent pom in the
"myfaces/orchestra/maven" dir, and the "myfaces/orchestra/pom.xml" file
(which is never released) just contains module tags.

Setting things up like this makes sense when the various subdirs have
different release cycles, as is the case for Myfaces in general (core,
core12, tomahawk, trinidad, etc have different release cycles) and
Orchestra (core, core15, flow have different release cycles). Of course
thinks like (core/api, core/impl) do not have independent release
cycles, so having the "module" pom also be the parent pom makes sense there.

I think that the build-tools modules do (or should) have independent
release cycles, so pushing the parent pom into a subdir makes sense there.

And if it is pushed down into its own dir, then you could also use the
maven-release-plugin to release it :-)

Comments, anyone?

>
>
>     * create a RELEASE-NOTES.txt file for myfaces-builder-plugin
>     explaining
>     why the first release is numbered 1.0.1
>     * do a first release of myfaces-builder-plugin as version 1.0.1
>
>     Any other plugins that need to be modified and released should then be
>     released individually as needed.
>
>
> It's ok, since in that case the parent pom is already released.
>  
>
>
>     (NB: we should use 1.0.1 as the first release number for
>     myfaces-builder-plugin because we have already been creating
>     1.0.1-SNAPSHOT versions in the apache snapshot repo, as the version
>     number was being inherited from the parent pom).
>
>     >
>     >
>     >         The parent pom does need to be released first, and that
>     >         currently depends on the new myfaces-master-pom which
>     depends
>     >         on the new checkstyle module. The release process for the
>     >         master pom and checkstyle is currently in progress;
>     there are
>     >         now enough +1s so I will finish the release of these
>     tonight.
>     >         That's a little short of the recommended 72 hours since
>     the RC
>     >         announcement (only 48 hours), but these modules are really
>     >         only internal so I hope no-one will be annoyed by that.
>
>     Regards,
>     Simon
>
>     >
>
>

simon.kitching@... schrieb:

>
> An alternative is to split things up so that the parent pom (the pom
> that other modules inherit from) is not the "module pom" (the one used
> to drive "bulk builds" of nested directories). A subdirectory can be
> created, the existing pom moved down into it, and a new trivial pom
> created in the base directory that just has <module> tags in it. I
> don't see any need to change the artifactId for the parent pom, so
> AFAIK simply moving it within svn should not break anything.
>
> For example, the main myfaces pom is in its own subdir, and has no
> <module> tags.
>
> The Orchestra code is also set up like this, with the parent pom in
> the "myfaces/orchestra/maven" dir, and the "myfaces/orchestra/pom.xml"
> file (which is never released) just contains module tags.
>
> Setting things up like this makes sense when the various subdirs have
> different release cycles, as is the case for Myfaces in general (core,
> core12, tomahawk, trinidad, etc have different release cycles) and
> Orchestra (core, core15, flow have different release cycles). Of
> course thinks like (core/api, core/impl) do not have independent
> release cycles, so having the "module" pom also be the parent pom
> makes sense there.
>
> I think that the build-tools modules do (or should) have independent
> release cycles, so pushing the parent pom into a subdir makes sense
> there.
>
> And if it is pushed down into its own dir, then you could also use the
> maven-release-plugin to release it :-)
>
> Comments, anyone?

Are there any objections if I move the parent pom for the maven2-plugins
into its own subdir? If not, I'll try to find time to do that tonight...

[Leonardo Uribe]

On Tue, Jul 22, 2008 at 11:33 AM, simon.kitching@... <simon.kitching@...> wrote:

simon.kitching@... schrieb:

An alternative is to split things up so that the parent pom (the pom that other modules inherit from) is not the "module pom" (the one used to drive "bulk builds" of nested directories). A subdirectory can be created, the existing pom moved down into it, and a new trivial pom created in the base directory that just has <module> tags in it. I don't see any need to change the artifactId for the parent pom, so AFAIK simply moving it within svn should not break anything.

For example, the main myfaces pom is in its own subdir, and has no <module> tags.

The Orchestra code is also set up like this, with the parent pom in the "myfaces/orchestra/maven" dir, and the "myfaces/orchestra/pom.xml" file (which is never released) just contains module tags.

Setting things up like this makes sense when the various subdirs have different release cycles, as is the case for Myfaces in general (core, core12, tomahawk, trinidad, etc have different release cycles) and Orchestra (core, core15, flow have different release cycles). Of course thinks like (core/api, core/impl) do not have independent release cycles, so having the "module" pom also be the parent pom makes sense there.

I think that the build-tools modules do (or should) have independent release cycles, so pushing the parent pom into a subdir makes sense there.

And if it is pushed down into its own dir, then you could also use the maven-release-plugin to release it :-)

Comments, anyone?

Are there any objections if I move the parent pom for the maven2-plugins into its own subdir? If not, I'll try to find time to do that tonight...

+1, we need to make more modular this part for release plugins

[Leonardo Uribe]

On Tue, Jul 22, 2008 at 11:19 AM, Leonardo Uribe <lu4242@...> wrote:

On Tue, Jul 22, 2008 at 11:33 AM, simon.kitching@... <simon.kitching@...> wrote:

simon.kitching@... schrieb:

An alternative is to split things up so that the parent pom (the pom that other modules inherit from) is not the "module pom" (the one used to drive "bulk builds" of nested directories). A subdirectory can be created, the existing pom moved down into it, and a new trivial pom created in the base directory that just has <module> tags in it. I don't see any need to change the artifactId for the parent pom, so AFAIK simply moving it within svn should not break anything.

For example, the main myfaces pom is in its own subdir, and has no <module> tags.

The Orchestra code is also set up like this, with the parent pom in the "myfaces/orchestra/maven" dir, and the "myfaces/orchestra/pom.xml" file (which is never released) just contains module tags.

Setting things up like this makes sense when the various subdirs have different release cycles, as is the case for Myfaces in general (core, core12, tomahawk, trinidad, etc have different release cycles) and Orchestra (core, core15, flow have different release cycles). Of course thinks like (core/api, core/impl) do not have independent release cycles, so having the "module" pom also be the parent pom makes sense there.

I think that the build-tools modules do (or should) have independent release cycles, so pushing the parent pom into a subdir makes sense there.

And if it is pushed down into its own dir, then you could also use the maven-release-plugin to release it :-)

Comments, anyone?

Are there any objections if I move the parent pom for the maven2-plugins into its own subdir? If not, I'll try to find time to do that tonight...

+1, we need to make more modular this part for release plugins

The change was applied, so I'll start the procedure for release myfaces-builder-plugin, myfaces-builder-annotations and the moved myfaces-plugin-parent.