Hello
How did you build your Maven project for it? Do you have 5 projects (one
per component) or 1 project that does it all?
There is no universal way of deploying a multi-component system. It all
depends first if these components can be deployed stand-alone or not. If
not, I fail to see why they should be packaged seperately.
I play with a pretty large project at work, based on a commercial
framework over which we add new services. The services, even if they can
be seen as components since we can add or remove them even without
restarting the system, are all part of THE big project, no sub-projects
for them and not deployed packages. Its been in production for nearly 2
years now and never did we upgraded only a single service as a
component upgrade Each time, marketing and product management and ISO
isssues lead us to issue either minor upgrades (when we add new
functionalities) or patches if we correct major bugs.
In another project, we patch some of the framework jars with some
internal fixes. These are built and published with a different maven
project and part of our internal library repository.
Along with this, we also have some minor utilities to perform specific
jobs. For that kind of project, I use 1 maven project per component.
These projects do depends on some jars of the big one and since we
didn't feel it was necessary to publish all the system's jars (over
100!) as libraries, I've build the maven projects for those as
sub-projects of the master maven project. Doing this allowed me that
have access to the master project's sources and share the target
directory so that when we compile the big one, the small ones could use
the same class files thus speeding up the build. The packaging and
deployement is seperate for all projects though.
If you have a distribution that goes beyond what the dist plugin offers,
I suggest you take a look at the distribution plugin I wrote. You can
find it on Source Forge, its called uber dist :
http://sourceforge.net/projects/uber-dist
Just updated the plugin today :).
Hope it helps
Eric.
Helck, Christopher wrote:
I know this could be a huge topic, but I have to start somewhere and I
suspect that this issue is common for maven users.
We've successfully migrated a project from Ant to Maven. In the process
we've broken a large application into 5 components. Currently we deploy
and install the entire thing as one entity using InstallShield. All the
jar files go under one application directory. Upgrading to the next
release means creating another application directory and adjusting a
symbolic link to point to it.
In the past if we needed to make a patch we'd create (by hand) a
patch.jar that had the changes and placed it at the front of the
classpath. I'd like to get away from this. Instead I'd like to just
release a new version of the changed component. The question is how
should my production environment be setup to make this easy/possible?
Thanks,
Christopher
The information contained in this e-mail is confidential. This e-mail is
intended only for the stated addressee. If you are not an addressee, you must
not disclose, copy, circulate or in any other way use or rely on the
information contained in this e-mail. if you have received this e-mail in
error, please inform us immediately and delete it and all copies from your
system.
EBS Dealing Resources International Limited. Registered address: 10 Paternoster
Square, London EC4M 7DY, United Kingdom. Registered number 2669861.
EBS Dealing Resources, Inc, registered in Delaware. Address: 535 Madison
Avenue, 24th Floor, New York, NY 10022, USA, and One upper Pond road, Building
F - Floor 3, Parsippany, NJ 07054, USA.
EBS Dealing Resources Japan Limited, a Japanese Corporation. Address: Asteer
Kayabacho Bldg, 6th Floor, 1-6-1, Shinkawa, Chuo-Ku, Tokyo 104-0033, Japan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
