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]
>
>

Reply via email to