tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: svn commit: r332806 - in /tomcat/jasper/tc5.5.x: .classpath .project
Date Sun, 13 Nov 2005 00:23:58 GMT
Costin Manolache wrote:
> I'll fix this, sorry - I think I have made few changes to my properties.
> 
> What is "svn co .../current" doing - I was using this before realizing
> that current doesn't work in eclipse, never used resources/build.xml

It is using svn:externals to bring the various modules together under 
a single directory. See the svn manual for an explanation of what 
externals are and how they work.

resources/build.xml is the source for the TC5 build.xml that is linked 
to on http://tomcat.apache.org/tomcat-5.5-doc/building.html

> In the top level build.xml - jasper project is still called "jasper" -
> are we supposed to co jasper2 as jasper ? This is all so confusing and
> painfull...

Agreed this is painful but the build script does all this for you. 
build.xml and Subclipse are not totally interchangeable. They will 
work together if you do the initial checkout using build.xml as per 
the directions I wrote for Henri.

Removing the jasper2 directory would be best but I didn't have the 
time to fix everything this might break.

> Is it too late to just move everything in one directory - and avoid
> all this forest ?

The current directory does exactly this using externals.

> I think we allways tag and branch all the components
> ( jasper, container, connectors, etc ), it is so much easier to work
> with a single tree. Really - there are historic reasons why we had
> this in CVS, but they are long gone..

I did look at other structures when we moved to SVN. Our current 
structure is the one that:
- enabled us to migrate in stages
- required minimal changes to our build scripts
- made little/no difference to the effort required to create a release
- required minimal manual (actually scripted) intervention to do the 
migration
- enabled us to maintain the traceability of our previous releases

All the other options I considered caused big problems in one or more 
of these areas and offered little benefit. That being said, if you 
have a proposal for an alternative structure then I would love to see it.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message