I try many combinations before, and ended up the select the one I have
outlined.
The main benefit is I can concentrate one platform at the time when I need
to refactor.
About duplication, the individual project should use
<compilerStartOptions>${some property from parent
pom}</compilerStartOptions>
dont try to inherit it, since it is hard to debug. So you should take
advantage at the platform specific parent pom to define as much as common
properties in there.
I have about 4 static libs 4 applications, 20 dll/sharelib for both windows
and linux and it is maintainant free for quite a while now.
Hope it helps.
-Dan
On 6/27/06, Brad Harper <[EMAIL PROTECTED]> wrote:
Dan:
I think I'm getting closer to understanding the root of the problem. It
may not be (non)inheritance of the configuration. The <configuration>
element contained
<compilerStartOptions>${compiler.debug.options}</compilerStartOptions>
and 'compiler.debug.options' is set in a <properties> element within a
profile for a sub-project, whose build is run last.
I'm trying to create a project based on your recommended organization,
but with some twists. The project hierarchy looks like
dxr/
pom.xml
dxr-core/
pom.xml <--- defines platform profiles, which specify
<modules> per platform
dxr-core-binaries/
pom.xml <--- <configuration><compilerStartOptions>
application-a/ element adds ${compiler.debug.options}
pom.xml
application-b/
pom.xml
dxr-core-libraries/
pom.xml <--- <configuration><compilerStartOptions>
library-a/ element adds ${compiler.debug.options}
pom.xml
library-b/
pom.xml
WINDOWS-X86/
pom.xml <--- specifies <modules> as
'dxr-core-binaries'
and 'dxr-core-libraries'.
defines a profile for debug, which sets
<properties><compiler.debug.options>
LINUX-X86/
SOLARIS-SPARC/
<both empty at the moment>
src/main/c-cpp/my.company.com/bin/application-a/
<source files>
/application-b/
<source files>
/lib/library-a/
<source files>
/library-b/
<source files>
/include/
<source header files>
target/bin/
/lib/
dxr-support/
dxr-utilities/
<both empty at the moment>
[ In reality, there will be six core applications and as many as four
core libraries in 'dxr-core'. The 'dxr-support' project will have five
applications, and 'dxr-utilities' could have as many as a dozen
additional apps. ]
Both sub-projects 'dxr-core-binaries' and 'dxr-core-libraries' give their
<parent> as <artifactId>dxr-core</artifactId>.
Oddly the build sequence is
dxr
dxr-core
dxr-core-libraries
dxr-core-binaries
dxr-core-WINDOWS-X86
Note that 'dxr-core-WINDOWS-X86' is last. Its profiles define the value
for the free-form property <compiler.debug.options>, but
${compiler.debug.options} appears to be 'null' when the compilation
actually occurs. It seemed as though the value wasn't being inherited.
I'm trying like mad to avoid duplication at all levels, and especially
not require the reproduction of the project's entire sub-project
organization under each platform project (as per your original outline).
I'm also investigating the use of the (gcc) mingw compiler on Windows.
The compiler and linker command lines would be normalized at that point
and, theoretically, there may not be a need to differentiate the CLI per
platform -- although artifact naming conventions, especially for
libraries,
vary between Windows and *nix.
Ideas?
Brad
-----Original Message-----
From: dan tran [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 27, 2006 11:58 AM
To: Maven Users List
Subject: Re: plugin configuration inheritance?
Brad plugin configuration should be inherited by default
https://svn.codehaus.org/mojo/trunk/mojo/maven-native/native-maven-plugin/sr
c/it/linkages/win32/pom.xml
-D
On 6/27/06, Stefan Hübner <[EMAIL PROTECTED]> wrote:
>
> I think, that inheriting plugin configuration, whether by <plugins> or
> <pluginManagement>, only inherits full configurations. That meens,
> whenever you reference a plugin and define a configuration-element
> inside, its inherited configuration will be lost.
>
> That's just my experience (and I think a was reading about this
> behaviour, but not sure where or when) and I'd appreciate any other
> opinions :-)
>
> --Stefan
>
> 2006/6/27, Brad Harper <[EMAIL PROTECTED]>:
> > Stefan:
> >
> > Until recently, I've had the expectation that plugin configurations
> > *should* be inherited by default. Apparently not.
> >
> > Another poster (Dan Tran) has recommended using <pluginManagement> to
> > control build configuration inheritance. "Better Builds" doesn't even
> > reference the element.
> >
> > I've tried using <inherited>true</inherited> in several positions, now
> > including within <pluginManagement>, but without success.
> >
> > Brad
> >
> > -----Original Message-----
> > From: Stefan Hübner [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 27, 2006 10:59 AM
> > To: Maven Users List
> > Subject: Re: plugin configuration inheritance?
> >
> >
> > Hi Brad,
> >
> > see comment inside:
> >
> > 2006/6/27, Brad Harper <[EMAIL PROTECTED]>:
> > > Are plugin configurations inherited/cumulative? E.g., given
> > > project 'A' descriptor containing
> > >
> > > <build>
> > > <plugins>
> > > <plugin>
> > > <artifactId>P</artifactId>
> > > <configuration>
> > > blah-1
> > >
> > > and sub-project/module 'B', with descriptor containing
> > >
> > > <build>
> > > <plugins>
> > > <plugin>
> > > <artifactId>P</artifactId>
> > > <configuration>
> > > blah-2
> > > blah-3
> > >
> > > Does plugin 'P' see 'blah-1' in its configuration?
> > >
> > I would assume, it doesn't. Not sure though.
> >
> > --Stefan
> >
> > ---------------------------------------------------------------------
> > 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]
