Leonardo Uribe schrieb:
On Sat, Jul 12, 2008 at 5:24 PM, simon <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Fri, 2008-07-11 at 13:46 -0500, Leonardo Uribe wrote:
>
>
> On Fri, Jul 11, 2008 at 2:56 AM, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
>
