You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Will Hartung <wi...@msoft.com> on 2003/01/07 19:05:05 UTC
Re: How to organize your software in proper version control structure?
> From: "Timo Riikonen" <ti...@donesolutions.com>
> Sent: Tuesday, January 07, 2003 3:46 AM
> Subject: How to organize your software in proper version control
structure?
> Hello,
>
> Here ia a question that may not have only one correct answer,
> but I hope you will try to give me your answer still.
>
> How to organize your software in proper version control structure?
There are certainly a gazillion answers, but I'll throw in my 2 cents.
One thing to consider is that your end product should simply be a single WAR
file, with all of the assorted bits and pieces assembled within.
The web.xml file has a lot of flexibility on how the various portions of the
WAR are exposed to the client, and this is where most of your high level
configurations should go. This also helps eliminate, as you mentioned, the
potential conflicts between related, yet distinct, WAR applications on the
same server. It also helps maintain container portability, as its the least
common denominator of all the webapps (in theory).
With this in mind, then the task of creating a client application and
tracking it falls into a task of creating and managing the appropriate
sub-components and assembling a final, cohesive WAR representing the whole
thing.
This leads to a configuration where you have a single directory for each
client application, and this essentially manages the build and integration
process. From the root of this directory is where it would be appropriate to
have the client specific build.xml file.
When you build your WAR, the build.xml would be tasked with pulling the
appropriate core code, classes and beans by simply copying jar files into
your WEB-INF/lib directory.
If you have common jsps and content, you can copy those as well into their
appropriate places.
Another thing you can do is have a "shared" content directory between the
core and client application. With this shared directory, you have the
build.xml copy down the files from the core code area, and then copy over
that with the client code. This gives you a crude form of inheritance where
you only specialize the appropriate content. For example, in your core
directory you might have logo.gif, left-arrow.gif, right-arrow.gif. In your
client directory, you only have logo.gif. When copied to their final
destination, you end up having the client logo with the stock arrow gifs.
Don't do this with Java classes, though, you can use Javas inheritance for
that.
In the end, what you end up with is several "stand alone" application
fragments that can be readily merged and customized for your clients.
And certainly, you don't rebuild a WAR for every trivial JSP change during
development. You simply make those changes in place. The key though is that
everything ends up in this kind of structure.
In the end, when you want to build a WAR for you client, you get the
appropriate version of the core application tree, get your clients
application tree, go into the client directory and then: ant build-war, as
it goes through and builds your final app.
What's nice about this is it helps keep you core generic code seperated. If
you end up building other "generic" modules, they can easily be integrated
into the final WAR in the same ways.
So, just because a WAR is one big single rooted tree does not mean you
really need to have all of your source code organized the same way. Only the
final result needs to be in the WAR structure.
It's not perfect, but it helps isolate your client specific stuff from your
generic stuff. It gives you some ability to continue to develop your generic
code while snapshotting your clients if necessary, yet still able to bring
them "up to date" later if appropriate.
Making custom changes for clients is always a mess for source code. Use your
source code controls branching and versioning tools to help keep the pieces
together.
Regards,
Will Hartung
(willh@msoft.com)
Here's a sample:
/CoreClasses -> creates core.jar
build.xml
/com
/company
/pkg1
class1.java
/pkg2
class2.java
/GenericApp
build.xml
/content
x.jsp
y.html
/images
logo.gif
left-arrow.gif
right-arrow.gif
/WEB-INF
web.xml
/code -- these classes end up in WEB-INF/classes
/com
/company
/GenericAppPkg
localClass.java
/OptionalFeature
build.xml -- builds a webapp with GenericApp and OptionalFeature
/content
/optionalFeature
feature.jsp
/images
/optionalFeature
feature.gif
/WEB-INF
web.xml -- feature specific bits
/code
/com
/company
/OptionalFeaturePkg
feature.java
/ClientABC
build.xml -- builds a webapp with GenericApp, OptionalFeature, and
ClientABC
/content
x.jsp
z.jsp
/images
logo.gif
/WEB-INF
web.xml - essentially a copy of GenericApps web.xml and edited
appropriately to include ClientABC and OptionalFeature
/code -- these classes end up in WEB-INF/classes
/com
/company
/ClientABCPkg
clientSpecificClass.java
Now, you "simply" merge these trees together to build the final webapp.
Ending up looking like this:
x.jsp -- (from ClientABC)
y.html -- (from GenericApp)
z.jsp -- (from ClientABC)
/optionalFeature
feature.jsp
/images
logo.gif -- (from ClientABC)
left-arrow.gif
right-arrow.gif
/optionalFeature
feature.gif
/WEB-INF
web.xml -- (from ClientABC)
/classes
/com
/company
/ClientABCPkg
clientSpecificClass.class
/GenericAppPkg
localClass.class
/OptionalFeaturePkg
feature.class
/lib
core.jar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to organize your software in proper version control structure?
Posted by Charles Baker <ra...@yahoo.com>.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Tue, 7 Jan 2003, Will Hartung wrote:
>
> > Date: Tue, 7 Jan 2003 10:05:05 -0800
> > From: Will Hartung <wi...@msoft.com>
> > Reply-To: Tomcat Users List
> <to...@jakarta.apache.org>
> > To: Tomcat Users List
> <to...@jakarta.apache.org>
> > Subject: Re: How to organize your software in
> proper version control
> > structure?
> >
> > > From: "Timo Riikonen"
> <ti...@donesolutions.com>
> > > Sent: Tuesday, January 07, 2003 3:46 AM
> > > Subject: How to organize your software in proper
> version control
> > structure?
> >
> >
> > > Hello,
> > >
> > > Here ia a question that may not have only one
> correct answer,
> > > but I hope you will try to give me your answer
> still.
> > >
> > > How to organize your software in proper version
> control structure?
> >
>
> The "Application Developer's Guide" that ships with
> Tomcat describes,
> among other things, the directory structures I
> recommend for webapp
> development:
>
>
>
http://jakarta.apache.org/tomcat/tomcat-4.1-dev/appdev/
>
That link didn't work for me, but this one did:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/appdev/index.html
{{SNIP}}
=====
rascharles@yahoo.com
http://www.charleshbaker.com/~chb/
If you cannot in the long run tell everyone what you have been doing,
your doing was worthless. -- Edwim Schrodinger
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to organize your software in proper version control structure?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 7 Jan 2003, Will Hartung wrote:
> Date: Tue, 7 Jan 2003 10:05:05 -0800
> From: Will Hartung <wi...@msoft.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: How to organize your software in proper version control
> structure?
>
> > From: "Timo Riikonen" <ti...@donesolutions.com>
> > Sent: Tuesday, January 07, 2003 3:46 AM
> > Subject: How to organize your software in proper version control
> structure?
>
>
> > Hello,
> >
> > Here ia a question that may not have only one correct answer,
> > but I hope you will try to give me your answer still.
> >
> > How to organize your software in proper version control structure?
>
The "Application Developer's Guide" that ships with Tomcat describes,
among other things, the directory structures I recommend for webapp
development:
http://jakarta.apache.org/tomcat/tomcat-4.1-dev/appdev/
>From a source code control perspective, you'll note that it totally
separates the source files and JSPs from the webapp that is constructed,
which is built into a target directory that can then be deleted and
rebuilt at any time.
This is also the philosophy used to manage the source code of pretty much
all the Jakarta projects themselves (all of which are under CVS
management), and it works quite well.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>