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:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 5:42 AM To: '[email protected]' 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
