myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <>
Subject Re: [maven] Latest maven changes
Date Thu, 05 Jan 2006 12:59:21 GMT

Simon Kitching schrieb:
> Hi,
> Sooner or later, the MyFaces core will stabilise while tomahawk charges
> ahead. So at *some* time the release cycles will have to separate. I
> think it's beneficial to split them sooner rather than later, so I'd
> like to see a structure set up now that makes that easier.

> Sooner or later, real "bugfix" releases should also be supported;
> MyFaces has just ignored that issue so far. Again, this is much easier
> to do when the libraries have separate release cycles; I'd hate to see a
> new myfaces-impl.jar release just because a nasty bug was found in
> t:dataTable...
Yes :-)
> On the subject of externals, I dislike them a lot. Sometimes they are
> necessary, but I'd prefer to see them kept to a minimum.
> Note that it's perfectly possible in SVN to copy several dirs into a
> tags dir, eg
>     svn cp myfaces/trunk/commons tags/spec/x.y.z/commons
>     svn cp myfaces/trunk/api     tags/spec/x.y.z/api
> to make a tag dir containing the two parts of MyFaces required to
> implement the specification (commons and core). In other words, how the
> subprojects are grouped for releases doesn't have to mirror their
> repository layout.
Yes, this is possible.
But the current stucture is:


Do you mean:

svn cp myfaces/commons/trunk tags/spec/x.y.z/commons
svn cp myfaces/api/trunk     tags/spec/x.y.z/api

Why do you want to change the layout in a branch or tag only?

You only need some svn moves and some changes in the poms. Every user 
can see the current state of the structure and what he can expect in the 
next release cycle.

And I don't think this works with the release-plugin from maven.
Maven provides some little help for performing a release.
If we decide to use maven we should go the maven way.


But I never try it.

It makes creating a tag fractionally more complicated
> (it *is* nicer just to be able to copy some common root dir) but I would
> still prefer this over externals.

This would be correct. if svn doesn't support move.
And if externals are a common use case, why I never see it?

> Regards,
> Simon



View raw message