On Friday, 13 בJanuary 2006 01:19, [EMAIL PROTECTED] wrote:
> On Mon, Jan 09, 2006 at 08:16:00PM +0200, Oded Arbel wrote:
> > The problem is like this (the actual system is far more complex):
> > - suppose two web applications, app1 and app2, both use some API
> > (which I developed myself).
> > - I don't want to develop the API twice on both web applications,
> > so I have a third project for the API itself, which is a not a web
> > application and so isn't in WEB-INF/classes of neither app1 nor
> > app2. - I don't want to build a jar for that API library to put in
> > app1 and app2's WEB-INF/lib because its also constantly being
> > developed - if I wanted to do this then after each commit, in
> > addition to the build stage I would have to copy the jar by hand to
> > all the applications that use it, which is an error prone process.
>
> You've got to be kidding. Copy by hand!? Why? Just build the jar
> file to some predefined location, and have the build process for each
> app copy it from there. There's no need to copy it by hand, have
> ant, or whatever you're using to build, do it for you.
The build file that I use to build the web app in the development env is
the exact same build file that eventually builds it for distribution.
The reason this is so, is that everything in the SCM (Software
configuration management - CVS and the likes) for the web app is
exactly the same as we use for the final build, so that checking out
from SCM and running ant are the only steps required to complete a
distribution package - that way we get to do all the code testing in
the development environment and the QC is used only for integration
testing.
> That seems much simpler than playing with custom class loaders, or
> startup classpath dependencies, or loose class files.
On the contrary. due to the reasons noted above, everything that differs
in the development env from the QC env has to be done by hand (when I
say by hand, I also mean special development env only scripts that are
not stored in SCM. Due to the "not stored in SCM" requirement we strive
to keep them as simple as possible so we don't need to track them).
> e.g. say you've got 4 different api's. When you build those, a jar
> file gets created in (e.g.) /myjars:
> Let's say app1 uses api's 1, 3 and 4, so it has something like this
> somewhere in its build.xml: (assuming you're using ant)
> <copy file="/myjars/api1.jar" todir="${WEB_DIR_LOCATION}/lib"/>
The dependency on the build env being "just right" and custom to each
application (i.e. lack of standard deployment techniques) is the major
down side with Java development. In order to solve this, the JPackage
project has developed some strict conventions as to what goes where,
and I'm not in the habit of violating these as keeping up with the
conventions is the number one reducer of development and integration
time.
The JPackage conventions call for all jars to be installed in a specific
directory - /usr/share/java - and be sym-linked from there to where you
want. the symlinking IS part of the ant build script, but it works
because the locations of the 3rd party jars is known ahead of time
because they are installed in the same location for all environments.
The problem is that development projects are not "installed" as they are
in constant development, and everything which is "installed" has to be
installed using the platform package management solution.
So, the way our system works is like this:
Dev has: 3rd party system packages, development projects, custom stuff
Build: get development projects, run ant -> create system package
QC and Production: 3rd party and our system packages.
What way production does not have any custom hand-installed software,
only stuff that plays nice with the built-in software management tools.
That allows us to have the operating system supports software
versioning and software dependencies and unified software distribution
in a transparent way across all of the software products we deploy (3rd
party or locally developed), the QC is exactly the same so it allows
real testing of what its like to be in production, and the build system
is a very simple two step process which is easy to monitor and
reproduce on a clean system (hacking the build is kept to minimum and
everything is in SCM for easy tracking).
This causes the development to have some custom stuff, but again - no
hacking of anything that is in SCM.
--
Oded
::..
"If I have seen farther than other men, it is because I stood on the
shoulders of giants."
-- Sir Isaac Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
