myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manfred Geiler <>
Subject Re: Proposed SVN Reorg
Date Tue, 31 May 2005 09:06:18 GMT
Thanks, Sean, for your spirit, I'm flabbergasted.

Only a few questions to be sure I understand everything:
* The proposed directories are meant to reside in the current myfaces
root, right? So we would get
and so on. Correct?
* What about the current directories "branches", "tags", "trunck" and
"trunk". Any chance to get rid of them later?
* How is the current link functioning? What exactly do I get when I
check out? Isn't there an awkward overlap between the examples,
sandbox and tomahawk src dir?
* How will the build-script(s) be organized? Some ant targets will
only function properly when I check out the "current" tree, so that
everything is on the right place. Is that correct? Or is there a way
to make the targets function regardless of that.
* The xdocs subproject will need a (virtual) build dir, too, I think.

Regarding share: I also have the feeling that the "right" place is the
core subproject. So I agree that the "physical" dirs should go there
and the tomahawk share should be the "virtual" dir (i.e. a link).

All in all, I'm very happy about this proposal. Thanks again, Sean.


2005/5/30, Sean Schofield <>:
> 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
> First let me summarize the svn:externals.  The "current" subproject is
> really just a convenience link for getting the latest and greatest of
> everything.  So you would use
> and you would end up
> checking out everything you see in the above list (minus current which
> is not really anything but a link to these projects.)  Try the same
> thing with struts to see how this works.
> 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
> ( 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.)
> 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
> ( 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.)
> 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
> 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.
> sean

View raw message