about inheritant problem, I think maven may not able to merge String []
injections
Please file JIRA + a simple simple usecase poms
-Dan
On 6/27/06, dan tran <[EMAIL PROTECTED]> wrote:
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]
>
>
