On 5/31/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Thanks - looks great, share issues are resolved with that proposal. > > John?
Sorry for the late response, have been very busy lately. :-) See responses inline below. > On 5/30/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Here is a first pass at a SVN reorg plan. The idea is to reorg svn > > into subprojects making it easier for those interested in specific > > subprojects to find the relevant code. Struts recently reorganized > > along simliar lines and I find it to be very useful. For instance, > > right now I'm not interested in struts core so I can use svn to > > checkout just the shale stuff. > > > > current*** > > build > > conf > > core > > api > > api/src > > api/src/java > > api/src/test > > build* > > impl > > impl/src > > impl/src/java > > impl/src/test > > share > > share/src > > share/src/java > > share/src/test > > lib > > examples > > build* > > src/java > > src/test > > sandbox > > build* > > src > > src/java > > src/test > > site > > tomahawk > > build* > > src/java > > src/test > > share/src > > share/src/java > > share/src/test > > xdocs > > > > * = svn:external link to the build subrproject > > ** = svn:external link to the shared source code (original maintained > > inside core subrpoject) > > ***= svn:external link to the trunk of all subprojects > > > > The build directory would also be available in each project even > > though there is really only one master copy. The idea is that if you > > checked out only the sandbox project > > (http://svn.apache.org/respos/asf/myfaces/sandbox) you would have a > > build directory with the same build.xml used by all subprojects (and > > the project as a whole.) So you could perform the builds with no > > problem. I still need to give some thought as to how we could pull > > this off without also sharing the dependencies in lib (I have a > > feeling this could be where Maven comes into play.) You are right about Maven having an impact here. In fact, with Maven in the picture, there would be no need for svn:externals to deliver a managed duplication of build code across projects. Instead, common tasks would be factored into Maven plugins, fostering reuse. Maven will also manage the dependencies automatically, as you indicated. Btw, one of the focus areas for Maven2 is making it really simple to write plugins, so I'd recommend taking a look at M2 at the same time you investigate M1. > > The core subproject would consist of api + impl stuff. I thought > > about calling this implementation but I didn't want to confuse that > > with the impl.jar code. Struts has a subproject called core so I > > thought I would suggest it. The core subproject also contains the > > "share" code used by tomahawk. I am proposing a svn:external link in > > the tomahawk project so that when you check out tomahawk > > (http://svn.apache.org/repos/asf/myfaces/tomahawk) you automatically > > get a directory called share with the shared code in it. BTW, commits > > against this "linked" directory are commited to the actual directory > > and updates against the link work against the real directory. I think > > this is a nice way to share the code but still allow tomahawk to be > > checked out as a complete project and compiled (without having to > > checkout the core stuff.) This solution nicely solves the management of the share source code across projects. However, it does not appear to address the runtime aspect. Given that "core" and "tomahawk" will be released independently (right?), then upgrading to a new version of "tomahawk" would implicitly change the code used by the "core" runtime, even though that version has not been upgraded. The implicit WEB-INF/lib JAR ordering in the classpath might cause either instance of the share package to be eclipsed, but we do know that one will definitely eclipse the other. I believe there can be no shared packages across "core" and "tomahawk" that are not explicitly called out as a versioned project, with a public API commitment across releases. Since we've been trying very hard to avoid creating an independent project, and we don't want to pollute the MyFaces API JAR, we might consider repackaging the share code into a tomahawk-specific Java package automatically during build to avoid the eclipsing problems described above. The "tomahawk" project should also be split into "api" and "impl" otherwise it is all effectively "api". > > Most of the directories would also have a trunk, branches and tags > > folders (not shown in the list for simplicity's sake.) Take a look at > > how this works in struts. If you wanted to check out the latest > > version of the core you would use > > http://svn.apache.org/repos/asf/myfaces/core/trunk. > > > > James Mitchell and I are hoping to experiment with a backup copy of > > the repository before anything is attempted. Also of course we will > > need to get PMC approval for this kind of a change. If this is close > > to what we want, it might be possible to setup an external svn server > > for people to evaluate the new scheme. I'd rather have agreement on > > 90% of this though before doing all of the work to move things around. > > > > Ultimately this won't change things much for developers who use the > > entire myfaces project. You would checkout myfaces/current and get > > everything. The build file would point to new directories, etc. and > > would generate the jars that we talked about on the earlier thread. > > Of course there would probably be some tweaks to your IDE project > > file. I think we should revisit the need for "current" after assessing the dependency management facilities in Maven / Maven2. Kind Regards, John Fallows.
