I wanted to jump in here and see if we can't resolve the problem of the shared (or core) code so we can get started on the reorg.
I'm definitely -1 on having a separate core.jar/share.jar file. I'm not sure if anyone is proposing that but I'm against that idea. We don't have that now and IMO this would add to the confusion. Craig has been suggesting we continue to maintain the two jar approach: one for api, one for impl. I agree we should stick with that pattern. We will also have the myfaces-all.jar as a matter of convenience to the users. Recall the easrlier discussion where we talked about the "artifacts" of the process (http://wiki.apache.org/myfaces/MyFaces_Artifacts). Its hard to imagine a scenario where we would release a new version of tomahawk but now release a new version of myfaces (because of the shared code.) Those using the RI with Tomahawk, however, need only to download the new tomahawk.jar. As for Maven and svn:externals I would say we still definitely need svn:externals even if we ultimately move to Maven. I feel pretty strongly that everything needs to be buildable using Ant since that is the industry standard right now (not Maven.) We can of course builld our releases, run tests, publish the website, etc. using Maven but the average user needs to be able to checkout myfaces/current and get everything. I'd like to get started on the svn reorg ASAP. Are there any major issues with the original proposal I outlined? I can't think of a change to the way we handle the share/core code that would be an improvement over what we have already discussed. sean On 6/9/05, John Fallows <[EMAIL PROTECTED]> wrote: > > I didn't mean the act of the generation, I know this is but executing > > a command - but if I need to develop on the implementation or the > > components source code and have to execute the command whenever I > > change something in the share classes, I promise this makes developing > > much more tedious, and this is probably not what we should encourage. > > We make heavy use of code generation in ADF Faces, and do not find it > to be a huge issue in practice. That might well be due to the fact > that, in practice, the source of those generated files have a low > frequency of update. > > When such an update is necessary, and we run the command line build > tool, the generated files are still part of the IDE experience, so the > overall development impact is slight. > > > Rather than imposing this on the developers, I would impose on the > > users to either download and use myfaces-all.jar if they use > > components and implementation or myfaces-components.jar if they just > > use the components (and implicitly package share along with that). > > > > Not so much more inconvenience for the users, a lot more convenient > > for us developers! > > I might be missing something, but this proposal doesn't seem to > address the runtime eclipsing of shared classes, which looks to still > be an issue because core and extensions are released independently. > > Given the choice of whether to impose upon developers who understand > the implications of their decisions or upon users who often do not > understand the subtleties, IMHO, I would suggest the former, since > developers are better equipped to deal with it. > > Kind Regards, > John Fallows >
