> 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.
I think you are correct on this Simon. While we have everyone focused on Maven we might figure out a solution to this. > 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... True. The one issue to be aware of is when commons changes. If containers ship with an older version of MyFaces (including the commons jar) there could be conflicts. No big deal though. We just make sure to remind people to upgrade commons if they are downloading the "tomahawk only" release. (We should probably include the commons.jar in the tomahawk release as well.) > 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. +1 for minimizing externals. As we see from the poor user trying to access 1.1.1 source code, the externals can really make a mess of things. There are 2 easy steps we can take to reduce usage of externals. 1.) Get rid of the shared build directory. (Already done - maven makes it easier to do recursive builds so we don't need the "one file to build them all" ant script.) 2.) Use svn copy for the "release" directory (instead of using externals.) > 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. 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. The tags are the only place where I believe externals make sense at all (and that's all we would use them for now that we have maven.) I guess you are suggesting we make a tags module and use the "assembly" step to pull things together? That might work. I'm not sure how the XSLT step would go though ... > Regards, > > Simon Sean
