Distributing dependent resources (external configuration files)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Distributing dependent resources (external configuration files)

Chua, Hin
Hi,
 
I've got a bit of a sticky problem and I was wondering if any of the Maven
gurus in this list wuold be able to help.
 
We have a common messaging package that we have set up as a Maven project in
our local repository.
 
This 'messaging project' consists of a single jar file and multiple
user-editable text configuration files (which CANNOT be included inside the
jar). This project utilised by several other projects in our organisation
and is listed as a Maven dependency in each of the latter's project.xml
files.
 
As a result, it's very easy to update the messaging jar in the other
projects as it change; we just run the Eclipse 'generate-classpath' goal to
suck down the latest version of the messaging jar. However, we are unable to
easily update the external configuration files; we have to manually copy
these from the messaging project to any other project that utilises them. As
the number of projects that utilise the messaging jar grows, this is
becoming a major hassle.
 
Is there a Maven-friendly approach to distribute these configuration files
to other projects in a manner similar to distributing the messaging jar? As
in, run some magical goal in a project and have all these dependent
resources be updated. The only solution I can currently think of involves a
lot of evil jelly/ant hackery in a custom plugin to pull the dependent
resources from CVS... but surely there must be a cleaner solution?
 
thanks in advance,
Hin


--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender. 3167
--------------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

RE: Distributing dependent resources (external configuration files)

David Jackman
We had a problem similar to this, but I don't think it's quite
identical.  We have a project that builds a jar that also has external
configuration files that, when installed, may be updated by the
installer to fit the user's situation (so the configuration can't be in
the jar).

For the project that builds the jar, I created a simple zip plugin that
packages all of the configuration files into a zip file and deploys that
artifact (so the project actually deploys two artifacts: the jar and the
zip).  The project that builds the install then uses both artifacts.  It
copies the jar, but extracts the zip (I have another custom plugin that
does this part) so the install can copy the individual configuration
files.

The same sort of thing could work for your situation as well.  In your
case do you have another project that uses the jar and needs the
configuration files in place in order to use it?  It's not too hard to
have a plugin extract the zip to the correct place, but having that take
place as part of the dependency downloading is the tricky part (I
actually don't know how you would do it--is there some goal you can
attach to?).

If the reason you can't have the configuration files in the jar is
because it's likely the user will need to make changes to the
configuration, then you wouldn't really want to overwrite those changes
when extracting the zip anyway, so there would have to be some manual
element to the process.  What you could do is have a plugin extract the
zip then automatically fix the configuration settings based on existing
user settings (say from a build.properties or even project.properties).
If that would work, then it would make sense to have a custom plugin for
this particular jar that knows how to do this.

..David..


-----Original Message-----
From: Chua, Hin [mailto:[hidden email]]
Sent: Wednesday, June 08, 2005 5:42 AM
To: '[hidden email]'
Subject: Distributing dependent resources (external configuration files)

Hi,
 
I've got a bit of a sticky problem and I was wondering if any of the
Maven gurus in this list wuold be able to help.
 
We have a common messaging package that we have set up as a Maven
project in our local repository.
 
This 'messaging project' consists of a single jar file and multiple
user-editable text configuration files (which CANNOT be included inside
the jar). This project utilised by several other projects in our
organisation and is listed as a Maven dependency in each of the latter's
project.xml files.
 
As a result, it's very easy to update the messaging jar in the other
projects as it change; we just run the Eclipse 'generate-classpath' goal
to suck down the latest version of the messaging jar. However, we are
unable to easily update the external configuration files; we have to
manually copy these from the messaging project to any other project that
utilises them. As the number of projects that utilise the messaging jar
grows, this is becoming a major hassle.
 
Is there a Maven-friendly approach to distribute these configuration
files to other projects in a manner similar to distributing the
messaging jar? As in, run some magical goal in a project and have all
these dependent resources be updated. The only solution I can currently
think of involves a lot of evil jelly/ant hackery in a custom plugin to
pull the dependent resources from CVS... but surely there must be a
cleaner solution?
 
thanks in advance,
Hin


------------------------------------------------------------------------
--------
The information contained herein is confidential and is intended solely
for the addressee. Access by any other party is unauthorised without the
express written permission of the sender. If you are not the intended
recipient, please contact the sender either via the company switchboard
on +44 (0)20 7623 8000, or via e-mail return. If you have received this
e-mail in error or wish to read our e-mail disclaimer statement and
monitoring policy, please refer to http://www.drkw.com/disc/email/ or
contact the sender. 3167
------------------------------------------------------------------------
--------


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]