You are right, the runtime problem with share persists... I assume you are proposing something like Sun does in its JWSDP - packaging Xerces along and refactoring it to com.sun.* classes?
And you are only proposing it for the deployed jar-files, not for development? That would be a workable solution, I would say. regards, Martin On 6/8/05, John Fallows <[EMAIL PROTECTED]> wrote: > 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. > >
