I'm not sure if I've stumbled upon a solution or a hack (I've been pounding away at this problem on and off for quite some time).
Here it is - please poke some holes in this: 1 - In some project pom (doesn't have to be related to anything), have filter files set up. In my case, I've named them after what I wanted (so stackdefaults-filter.properties and crimson-filter.properties). 2 - Attach an assembly to put the resulting zip file into your local repository. 3 - use Dependency:unpack to pull down this set of filters 4 - use a profile in the child poms to choose other filters if I'd like 5 - profit I'd love to hear some feed back where this could possibly fall apart, but so far, I can list all the filters in the poms and they override from top to bottom. -----Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 7:13 PM To: Maven Users List Subject: RE: sharing properties between modules Yeah, the first paragraph below doesn't work. I created a pom that not only has a properties section (with one property) but also has a profile with the same property. In another pom, I put a dependency on this first pom and tried processing resources on a file that has this same one property. Then on the command line of this second pom, I type "mvn process-resources -P<profile name in first pom>" but it doesn't change the property inside the one file with the one property (I can see it's getting "processed" from src to target, the token isn't being expanded tho). As far as that second example, it went right over my head. Are you suggesting that this property file should be completed manually and installed in our repository? My test project is really small (one file) all truth be told, with ATG config files counted, we have hundreds. The one really tricky piece is for local development, people need to be able to apply the profiles they have locally (in their settings.xml files). The other part to this is we combine mulitple profiles to get a final deployment configuration. So it'd be something like: Mvn install -Pbase,StackDefaults,serverclass Where "base" contains things like memory settings for the compiler and java docs/unit testing. "StackDefaults" contains things like where java home is for all the stacks "serverclass" contains things specific to say an app server versus a db server I like this - more ideas! I'm pouring over the documentation trying to find something that allows this kind of "put in one place, share all over" type treatment of properties. -----Original Message----- From: Allen, Daniel [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 6:51 PM To: Maven Users List Subject: RE: sharing properties between modules I don't actually know if dependency POMs look at their profiles' <activeByDefault> elements or not. I guess not, from what you're describing. Have you tried invoking the profile explicitly when you run Maven? (e.g. "mvn -P profileName deploy") The dependency POM's profiles may still be available, even if they're not auto-activated. Also, I think Wayne was suggesting actually writing config files with the properties, packaging them into an archive, and then using that as a dependency. (Sorry, Wayne, if I'm misunderstanding your advice.) Many frameworks will allow you to do an #include-style import of settings from other files, so perhaps you could have your bottom-level projects depend on that archive, and point to its config files. ~DVA -----Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 6:28 PM To: Maven Users List Subject: RE: sharing properties between modules So there's no way to keep the properties in various profiles (all within a pom) and just put a dependency on that pom (I think the dependency part works, but it doesn't seem to pick up the activated profile)? -----Original Message----- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 6:24 PM To: Maven Users List Subject: RE: sharing properties between modules Wait, package what? 99% of our properties are stored in profiles. When we want to generate the configuration for a particular stack, we use the -P<common>,<stackname> convention. -----Original Message----- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 6:12 PM To: Maven Users List Subject: Re: sharing properties between modules Sure. Just package it as a jar, and use the dependency plugin to unpack its contents where you need them in your related projects. Wayne -- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of any entity within the KBC Financial Products group of companies (together referred to as "KBC FP"). This message does not create any obligation, contractual or otherwise, on the part of KBC FP. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, prices at which KBC FP would enter into a transaction, or prices at which similar transactions may be carried on KBC FP's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
