see comments inline

On 6/16/06, Brad Harper <[EMAIL PROTECTED]> wrote:

Dan:

Yes, thank you. The layout isn't terribly different than I had thought,
although when you wrote "create all the pom files per extension type" did
you mean "per executable or library instance"?

I.e. application A, libraries L1 and L1, and utility apps U1 and U2 would
each have separate sub-projects beneath 'windows-x86', with their
respective
mavin-native-plugin package types:

   WINDOWS-X86
     pom.xml
     third-party
       pom.xml
     A
       pom.xml           <packaging>exe</packaging>
     L1
       pom.xml           <packaging>dll</packaging>   or 'so' for *nix
     L2
       pom.xml           <packaging>dll</packaging>
     U1
       pom.xml           <packaging>exe</packaging>
     U2
       pom.xml           <packaging>exe</packaging>
     ...


correct,

Alternately, couldn't apps/libraries be siblings of the platform projects
and be beneath a platform when they are built only on that platform? Say,
if U3 was built for WINDOWS-X86 *only*? Platform branching would occur
under the target directory.


Not sure why you want branching under target directory.

My questions arise because I have 4 primary apps built on all platforms,
one extra client (with GUI) on windows only, and ~10 utilities on all
platforms. It seems that branching per platform at a high level makes for
a lot of duplication and adds opportunity for error when a change hits
all of the sub-projects.


Base on experience, I dont have  huge success isolated the changes by
implementing
separated branches for each platform.

Most of the time, the changes are compiler settings, properties and it
should affect per branch basic

Make sure to take advantage of platform's parent pom to store common pom
properties ( ie common compiler flags, etc )



-Dan

Thoughts?

Thanks again.

Brad
[EMAIL PROTECTED]

-----Original Message-----
From: dan tran [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 11:25 AM
To: Maven Users List
Subject: Re: Maven with a C++ Project


maven works best with one artifact per project ( cohesive build).
native-maven-plugin embraces that
practice.

So you will need to pay upfront to create all the pom files per extension
type, after that maven will take care
the rest for you ( ie just like any java artifacts)

So here are my recommendation based my experience with porting a huge
legacy
make project to maven 2

root
  pom.xml
  java
     pom.xml  <----- host all java projects
  native
      pom.xml <----- contains profile to pick the specfic native build at
runtime
     src/main/native  <------ native source common to all platforms
     windows-x86
        pom.xml  <------ parent pom, has all common
settings/configurations/properties specific to this os
        thirdparty
            pom.xml  <------- extract all your specific thirdparty
libraries and include files
        native-project1.
            pom.xml
         native-project2
            pom.xml
        .....
        assembly      <--- use assembly plugin to assembly your windows
bits
            pom.xml

     linux-x86
          see windows settup

     other-os
          ....

It looks tedious, but this allow changes in one os specific build  to have
no impact on others.


Hope it helps


-dan



On 6/16/06, Brad Harper <[EMAIL PROTECTED]> wrote:
>
> I'm evaluating Maven's suitability to manage multi-platform builds
> for a C++ product targeting WIN32 and *nix.
>
> Not having applied Maven in the conventional Java context, I'm
> trying to map a hypothetical project onto the end goal of deploying
> a thing composed of multiple .exe files, .so or .dll libraries,
> resource files, etc.
>
> I'm aware of 'maven-native-plugin' (as well as 'cpp-tasks' from ant-
> contrib). That part seems obvious enough.
>
> I'm struggling with issue of granularity and how to use Maven,
> given the notion that each project should produce one primary output.
>
> Does that mean I would have a sub-project (module) for each .exe/.so
> and then use profile-based assembly/assemblies to deploy?
>
> Or does it mean I would need to define a specialized plug-in to
> compile/link apps and a new packaging type that represents the
> final deployment-ready arrangement.
>
> Cheers,
>
> Brad
>
> [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