myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Proposed SVN Reorg
Date Wed, 08 Jun 2005 16:41:05 GMT
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 <john.r.fallows@gmail.com> wrote:
> On 5/31/05, Martin Marinschek <martin.marinschek@gmail.com> 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 <sean.schofield@gmail.com> 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.
> 
>

Mime
View raw message