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]
