I've done something similar to Vincent's approach but extended it with distributed configuration files. A project can publish its configuration as a jar file that contains a properties file per environment. The configuration jar gets downloaded like any other dependency. When "filter.file=true" is found within a dependency's properties, the jar is extracted and the appropriate configuration is loaded for filtering. I have found this to be useful in large project settings where one project's configuration (e.g a Web service end-point) is used by multiple projects. It avoids ensuring that a trivial modification is propagated across all teams. I've installed a blog so you can take a look at the Jelly script.
http://lacesco.com/blog/ Best regards, Thomas -----Original Message----- From: Maczka Michal [mailto:[EMAIL PROTECTED] Sent: lundi 18 avril 2005 16:02 To: 'Maven Developers List' Subject: RE: [M2] filter definition > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Monday, April 18, 2005 1:53 AM > To: Maven Developers List > Subject: Re: [M2] filter definition > > > Jason van Zyl wrote: > > >>Here's the full URL: http://www.jconfig.org/ConfigurationServer.html > >> > >> > > > >Cool! I'll take a look and try to integrate it into what I'm making. > > > > > Yeah, I think we are all on the same page now. > almost :) > - Build a single archive > - swizzle J2EE files that need to be changed for deployment, > as part of > the deployment process, not the build process > I a not 100% sure if I understand you. What do you mean by deployment process here? Is it going to be supported/executed in m2? In a place where I am working we often follow the following scenario: There is one person resposible to prepare deployment artifacts. Some other person is verifing if everything is OK and is transfering those artifacts to CDs which are later taken to the customer. Alternativly they are transferd to the customer via ftp/ssh. Third person is responsible of physical deployment of those artifacts at the customer site. And this may happen weeks or even months after the artifacts were prepared (built). It may also happen in the place where there is not a chance that they will let you use any extra tool (so maven ant and such tools are excluded). So as you can see in my case really build process is completly seperated from deployment process but during the deployment process we are not allowed to change any artifacts. As we try to deploy more and more artifacts for each customer to our artifact repository - it makes it possible to do some cool things and for example we are exeprimenting with incremental updates and hoping to soon have a possibility of transfering to the clients just very small archives which contains the files, which have changed since the last deployment. This is possible as we know what we have deployed (historical version are stored in the repoitory) and what we have to deploy. So from my experince the communication via artifact repositories (e.g. maven repositories) and the requirment that build process on output must deploy ready (or almost ready to use) artifacts to repositoriy(ies) realy is a key and works quite well. This also requires that each artifact must have unique name - so the rule one project - one artifact has to be followed. So for example Vincent's solution: ----------- project1 |_ src/resources |_ env1 |_ [files or env1] |_ envN |_ [files or envN] |_ shared |_ [files shared by all envs] |_ [...] And then having the logic to choose the resource files based on a env.name=env1|envN property. ---------- is not something which we can use as artifacts for different environments will replace each other in local/remote repository. I don't think that my scenario is the only valid one it is one and most likely some other case (simpler or more complex) may require completely different solutions (e.g. the one described by Jason and Vincent). But I don't think that there is too many such cases. And I am sure there is a lot of "private" existing m1 plugins which were never published, which support those use cases. So it is not like we are exploring new lands - just nothing was shared and standarized in that domain :). best regards Michal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]