So just to give a heads-up on what I've done. I needed the ability to be able to import more than just dependency management (DM) from a pom.
USE CASE: Import properties and plugin configurations from a central location Once your company starts using maven and creating all sorts of projects, this ability becomes necessary. Managing common changes in properties, plugin versions and configurations across multiple big projects (diff repos) becomes tedious. SOLUTION: Custom build extension I created a build extension that merges interesting (to me) items from an external pom into the maven projects accessible to the extension. Sort of like having an external parent pom, though not as powerful as there are only a couple of things that work; mainly what I was interested in - plugins and their configurations. LIMITATIONS: Manual property resolution. Not everything can be merged to affect the current build. For example I have to resolve external properties during my merging process. They don't seem to resolve properly even when I add them to the project's properties. Changes are merged into the project's build plugins. Adding them to plugin management has no effect, probably because the projects have already been read. Works for me though. I think this should probably be a feature for future versions of maven. Importing should not just be restricted to DM. On Jan 4, 2013, at 7:05 PM, Marcos Mendez wrote: > thanks. i've done the dependency mgmt stuff. works fine and with a main > import. we actually have the poms set pretty much the way you describe. but > we have a lot of projects (diff repos and builds) and we need to change them > all correctly to update standard things which is not good. gonna tinker a > little bit more... > > On Jan 4, 2013, at 18:14, Ansgar Konermann <[email protected]> > wrote: > >> Suggestions: >> >> Dependency management: a small number of poms. In the beginning: could be >> one pom. >> >> Build behaviour: a small number of parent poms. One for each type of >> artifact you're going to produce. Say: JAR, WAR. Maybe one common parent >> where you define plugin versions and build behaviour which is really the >> same for all your artifacts. >> >> Hint: plugin management can use properties which are "undefined" in the >> parent pom. You can define their values in the inheriting module's pom. >> Think OOP: parent pom can define abstract/parameterized behaviour, >> inheriting pom defines abstract parts of behaviour. >> >> Put dependencies of each module into that module. Reduce number of >> dependencies as much as possible. Don't depend on, say, a JAR, just because >> all your other modules do that too. >> >> If this does not work for you, let us know the detailed "why". >> Am 04.01.2013 23:42 schrieb "Marcos Mendez" <[email protected]>: >> >>> ok what us the maven way? if it is to have the same parent then it will >>> not work for me. conventions are fine until they impede. >>> >>> On Jan 4, 2013, at 17:38, Anders Hammar <[email protected]> wrote: >>> >>>> I seriously doubt it is possible. And even if it was, it's the wrong way >>> to >>>> go as there is already a standard way to handle it in Maven. And Maven is >>>> all about conventions and not inventing your own solution. >>>> >>>> /Anders >>>> >>>> >>>> On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann < >>>> [email protected]> wrote: >>>> >>>>> If you really do, please discuss your approach here on the mailing list. >>>>> >>>>> I'm sure it will be useful for others, too. >>>>> Am 04.01.2013 23:11 schrieb "Marcos Mendez" <[email protected]>: >>>>> >>>>>> thanks. i'll see if i can create a plugin to do it then. >>>>>> >>>>>> On Jan 4, 2013, at 16:38, Anders Hammar <[email protected]> wrote: >>>>>> >>>>>>>> I actually do mean super pom. >>>>>>> >>>>>>> >>>>>>> No, you don't. What you're talking about is something often called a >>>>> BOM >>>>>>> (bill of material) or maybe an import-pom. >>>>>>> >>>>>>> >>>>>>>> We have multiple projects that have similar configurations, >>>>>> dependencies, >>>>>>>> plugins, etc. I don't want to have them repeated each time and they >>>>>> will >>>>>>>> not have the same parent - it is not feasible. I've used the import >>>>>> scope >>>>>>>> for setting dependency versions (e.g. dependency management) in one >>>>>> place >>>>>>>> and that worked ok. Has anyone tried to do this for plugins >>>>>> configurations >>>>>>>> as well? >>>>>>> >>>>>>> It only works for depMgmt. PluginMgmt you need to inherit from a >>>>>> parent-pom. >>>>>>> >>>>>>> /Anders >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote: >>>>>>>> >>>>>>>>> First, there is only one "super-POM" and that one is included in >>>>> Maven >>>>>>>>> itself. What you probably mean is a "parent pom". >>>>>>>>> >>>>>>>>> To use that parent pom you declare it in the "parent" section, not >>>>> as a >>>>>>>>> import scope dependency. >>>>>>>>> >>>>>>>>> /Anders >>>>>>>>> >>>>>>>>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez <[email protected] >>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've defined a superpom and I'm using the import scope in another >>>>>> maven >>>>>>>>>> project to apply those. I'm not seeing the configurations being >>>>>> applied >>>>>>>> for >>>>>>>>>> the plugins I've defined in the superpom's pluginManagement. >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Marcos >>>>> --------------------------------------------------------------------- >>>>>>>>>> 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] >>> >>> --------------------------------------------------------------------- >>> 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]
