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]
