Re: Building C++ projects with Maven (2)
Hello every one, IMHO, cpptasks knows too much about platform specific. After a while it becomes impossible to maintain and cpptasks went to orphanate state. I decided to go with a light weight engine, give user the responsibilty to specify every thing. They have to know it any how . I turn out, it works every well with all of my of unix boxes. Forexample a aix box can have a number of compilers. It is impossible to maintain lots of compiler provider types, the way cpptask requires. It does not mean we stuck with this philosoply, underneath of native-maven-plugin is plexus container, so you can extend and still acheive a high level of cohesiveness and independent from the engine itself ( like m2 versus its plugin) On windows, I create specilized provider so that users dont have to setup env on msvc6, msvc2003, borland, etc, as long as they install the compiler at the default place. Most of them do. (but they still can override the compiler install home thru plugin configuration, if they decide so) This is a blast. since the startup env script is small (only jvm and maven2 are required) However, I really like the way Mark done with NAR and handle include files. -Dan On 11/2/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi Chris, -Original Message- From: Chris Berry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 4:17 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar correct, with the exception that the -nar- part in the filename is gone since m2 reports all dependencies irregardless of types, and the classifier is at the end. So you would end up with: 0. openssl/0.9.8/openssl-0.9.8.pom 1. openssl/0.9.8/openssl-0.9.8.jar 2. openssl/0.9.8/openssl-0.9.8-noarch.nar 3. openssl/0.9.8/openssl-0.9.8-i386-linux-gcc.nar 4. openssl/0.9.8/nar/include 5. openssl/0.9.8/nar/lib/i386-linux-gcc/shared/openssl-0.9.8.sohttp://0.9.8.so where 0. is the generic pom file, referring to other jar and/or nar dependencies, 1. is a standard jar file, which may contain class files, but for sure contains a properties file referring to 2. and 3. The nar-plugin will download 2. and 3. and unpack them in 4. and 5. if another project is dependent on openssl-0.9.8. Regards Mark Donszelmann Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found
RE: Building C++ projects with Maven (2)
What's the status of the M2 version of the FreeHEP plugin? Is this becoming the defacto standard, or are there other attempts at this problem? ..David.. -Original Message- From: Donszelmann, Mark [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 6:08 PM To: Maven Users List Subject: RE: Building C++ projects with Maven (2) Hi Chris, for maven 1 we create zip files (.nar extension) which we download using the nar plugin. These files have the same name as a properties file which the user depends on, but with a postfix -aol (architecture-os-linker) or -noarch, and extension .nar The -noarch file is for include files. maven 1 downloads the properties file, since the user depends on it. The nar plugin downloads the -aol.nar file and the -noarch.nar file. Both these files are unpacked in the repository, since all native compilers will not understand zip files (java does), so we need the library files and include files in some directory structure. Unpacking is done by the nar plugin. For Maven 2 we use the classifier, as suggested by Brett. However, the plugin will still handle the download and unpacking, since we do not expect the user to modify the pom to be dependent on the classifier. Regards Mark -Original Message- From: Chris Berry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 4:17 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project
RE: Building C++ projects with Maven (2)
Hi David, -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 02, 2005 7:49 AM To: Maven Users List Subject: RE: Building C++ projects with Maven (2) What's the status of the M2 version of the FreeHEP plugin? I can publish my alpha version by Friday this week. The current version compiles code in C, C++ and Fortran, builds shared and static libraries. It handles native dependencies. It uses CPPTasks underneath, which could be replaced by something better (more maintained), but I currently see no time to deal with that. Next on my list is to create tests and executables, and check the jni library creation. Is this becoming the defacto standard, or are there other attempts at this problem? There is an effort from Dan Tran ongoing, but he chose a slightly different approach. The nar-plugin unifies (via cpptasks) as many options as possible for compiler and linker. You can still set specific options, but you would not have to. Dan's approach is (as we last spoke) to have the user define all. Regards Mark Donszelmann ..David.. -Original Message- From: Donszelmann, Mark [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 6:08 PM To: Maven Users List Subject: RE: Building C++ projects with Maven (2) Hi Chris, for maven 1 we create zip files (.nar extension) which we download using the nar plugin. These files have the same name as a properties file which the user depends on, but with a postfix -aol (architecture-os-linker) or -noarch, and extension .nar The -noarch file is for include files. maven 1 downloads the properties file, since the user depends on it. The nar plugin downloads the -aol.nar file and the -noarch.nar file. Both these files are unpacked in the repository, since all native compilers will not understand zip files (java does), so we need the library files and include files in some directory structure. Unpacking is done by the nar plugin. For Maven 2 we use the classifier, as suggested by Brett. However, the plugin will still handle the download and unpacking, since we do not expect the user to modify the pom to be dependent on the classifier. Regards Mark -Original Message- From: Chris Berry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 4:17 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native
RE: Building C++ projects with Maven (2)
Hi Chris, -Original Message- From: Chris Berry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 4:17 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar correct, with the exception that the -nar- part in the filename is gone since m2 reports all dependencies irregardless of types, and the classifier is at the end. So you would end up with: 0. openssl/0.9.8/openssl-0.9.8.pom 1. openssl/0.9.8/openssl-0.9.8.jar 2. openssl/0.9.8/openssl-0.9.8-noarch.nar 3. openssl/0.9.8/openssl-0.9.8-i386-linux-gcc.nar 4. openssl/0.9.8/nar/include 5. openssl/0.9.8/nar/lib/i386-linux-gcc/shared/openssl-0.9.8.so where 0. is the generic pom file, referring to other jar and/or nar dependencies, 1. is a standard jar file, which may contain class files, but for sure contains a properties file referring to 2. and 3. The nar-plugin will download 2. and 3. and unpack them in 4. and 5. if another project is dependent on openssl-0.9.8. Regards Mark Donszelmann Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Building C++ projects with Maven (2)
Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David..
Re: Building C++ projects with Maven (2)
This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David..
Re: Building C++ projects with Maven (2)
You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David..
Re: Building C++ projects with Maven (2)
Right. I suspect that native artifacts will have to be delineated by both
CPU architecture and OS distribution. There's generally a tight coupling
between the binary and the compiler version and glibc version and possibly
other system libraries. So the repository would need a scheme something like
${groupId}/${artifactId}/${version}/${os}/${march}. The OS would be more
specific than just linux. I think we would need to specify a distro family
(where major versions of systems libs are fixed) like Red Hat Enterprise
Linux 3.x, Red Hat Enterprise Linux 4.x, Suse Linux Enterprise Server 9,
Fedore Core 4, etc.
Roger
On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote:
This brings up a bigger question; How does maven want to handle OS
information in the repo?? To be successful w/ other languages like C, the
repo will need to delineate information such as i586 and linux. Are
these to be rolled into the groupId?? That doesn't smell right. Seems that
we may need new Artifact Resolvers that understand this sort of info
natively and can transparently supply the the correct pieces to the URL.
Cheers,
-- Chris
On 11/1/05, dan tran [EMAIL PROTECTED] wrote:
Hi David,
There is a work in progress for native-maven-plugin
http://svn.mojo.codehaus.org/trunk/mojo/maven-native/
You can build it and take a look at some doc.
-Dan
On 11/1/05, David Jackman [EMAIL PROTECTED] wrote:
I've just found out that I'm going to need to expand our Maven build
process to include several C++ project (which I believe are built
using
gcc). I seem to remember seeing some traffic on this list from people
doing this sort of thing (which I promptly ignored because I wasn't at
the time). Can anyone offer some insight on how you got this to work
and how you overcame the problems that came up? What plugins are
available to build this way and do they do everything you need? Are
you
able to have dependencies in the Maven repository and have the build
use
them from there (similar to .jar dependencies)? How do you access the
header files, possible library, and runtime library for the different
portions of the build? Is there a mini guide for this kind of project
in the works?
Thanks,
..David..
Re: Building C++ projects with Maven (2)
The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David..
Re: Building C++ projects with Maven (2)
I think not. Using groupId or artifactId is insufficient -- at least in it's present form. If I have a dependency on, say, version 1.2 of a shared library -- that dependency is platform independent. If not, then you would have to have different POMs for different platforms. Obviously that doesn't work and is not what a POM is about (a holistic project recipe) Although when I am actually building, maven needs to supply OS specifics to grab the right stuff for my platform. For Java this is a no-op and would thus default to noarch or nothing at all. But for languages like C, the system must somehow transparently fill in OS info when constructing the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David..
RE: Building C++ projects with Maven (2)
If one considers an alternative use case scenario where a single host (build server) is cross compiling for multiple targets. Then would not the maven sense the machine architecture solution would only support one target environment? Perhaps a mechanism for management of iterative profiles in order to target environment. -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building C++ projects with Maven (2)
Good point Sean. But I think the original question still holds; How should we handle this in the repo itself?? I do not think that one can use either groupId or artifactId without violating the platform independence of the POM. I think this implies a smarter Artifact Resolver than we have to today?? Cheers, -- Chris On 11/1/05, Sean Hennessy [EMAIL PROTECTED] wrote: If one considers an alternative use case scenario where a single host (build server) is cross compiling for multiple targets. Then would not the maven sense the machine architecture solution would only support one target environment? Perhaps a mechanism for management of iterative profiles in order to target environment. -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building C++ projects with Maven (2)
Good point. Source RPM handles this with options you can pass to the rpmbuild command. Maven could have either command line or configuration options to do the same. From http://www.rpm.org/max-rpm-snapshot/s1-rpm-multi-build-install-detection.html , The *--buildarch* and *--buildos* options can be used to set the build-time architecture and operating system rather than relying on RPM's automatic detection capabilities. These options are added to a normal RPM build command. One important point to remember is that, although RPM does try to find the specified architecture name, it does no checking as to the sanity of the entered architecture or operating system. For example, if you enter an entirely fictional operating system, RPM will issue a warning message, and then happily build a package for it. This brings up an interesting idea. Rather than building the infrastructure into Maven to detect OS and architecture information, perhaps Maven could delegate this to rpm, at least on Linux. RPM is the package format defined for the Linux Standard Base, although it mentions the standard includes only the rpm package format and not the rpm command or specific rpm macros. In practice, this might not be a big deal. Most or all distros might use the same rpm command options and a small set of standard macros. http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.html http://www.linuxbase.org/talks/lca2005/img52.html Just an idea for trying to reduce the effort to support this and unnecessary duplication of functionality. Roger On 11/1/05, Sean Hennessy [EMAIL PROTECTED] wrote: If one considers an alternative use case scenario where a single host (build server) is cross compiling for multiple targets. Then would not the maven sense the machine architecture solution would only support one target environment? Perhaps a mechanism for management of iterative profiles in order to target environment. -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Building C++ projects with Maven (2)
Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building C++ projects with Maven (2)
Just as another use case to throw in... We use a maven-1 structured repository and we are now beginning to migrate to the m2 style structure. We use our repository not only to store java-based build artifacts such as .jar, .war, .ear files, but also other kinds of release artifacts which might include zips, rpms, tgz, etc., that come out of C-based build tools. Given maven is becoming a more platform agnostic build automation system, I am curious how cpu architecture and operating system build artifacts will be reflected in the structure of the repository, as well. We have discussed creating a convention using using groupId/ artifactId or treating arch/os-specific builds as secondary artifacts. Note also, we presume the scenario where cross compilation is occurring to support multiple targets. Thanks. Alex Good point Sean. But I think the original question still holds; How should we handle this in the repo itself?? I do not think that one can use either groupId or artifactId without violating the platform independence of the POM. I think this implies a smarter Artifact Resolver than we have to today?? Cheers, -- Chris On 11/1/05, Sean Hennessy [EMAIL PROTECTED] wrote: If one considers an alternative use case scenario where a single host (build server) is cross compiling for multiple targets. Then would not the maven sense the machine architecture solution would only support one target environment? Perhaps a mechanism for management of iterative profiles in order to target environment. -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - 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]
Re: Building C++ projects with Maven (2)
We have a -classifier element in the artifact in the repository which was envisaged as encopassing this, however it won't allow it to be later broken down into individual pieces. What it does mean is that all the variants have the same POM and are treated as one dependency that just differs on other architectures. I'll add this to the 2.1 discussion list. On 11/2/05, Roger Hoover [EMAIL PROTECTED] wrote: Good point. Source RPM handles this with options you can pass to the rpmbuild command. Maven could have either command line or configuration options to do the same. From http://www.rpm.org/max-rpm-snapshot/s1-rpm-multi-build-install-detection.html , The *--buildarch* and *--buildos* options can be used to set the build-time architecture and operating system rather than relying on RPM's automatic detection capabilities. These options are added to a normal RPM build command. One important point to remember is that, although RPM does try to find the specified architecture name, it does no checking as to the sanity of the entered architecture or operating system. For example, if you enter an entirely fictional operating system, RPM will issue a warning message, and then happily build a package for it. This brings up an interesting idea. Rather than building the infrastructure into Maven to detect OS and architecture information, perhaps Maven could delegate this to rpm, at least on Linux. RPM is the package format defined for the Linux Standard Base, although it mentions the standard includes only the rpm package format and not the rpm command or specific rpm macros. In practice, this might not be a big deal. Most or all distros might use the same rpm command options and a small set of standard macros. http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.html http://www.linuxbase.org/talks/lca2005/img52.html Just an idea for trying to reduce the effort to support this and unnecessary duplication of functionality. Roger On 11/1/05, Sean Hennessy [EMAIL PROTECTED] wrote: If one considers an alternative use case scenario where a single host (build server) is cross compiling for multiple targets. Then would not the maven sense the machine architecture solution would only support one target environment? Perhaps a mechanism for management of iterative profiles in order to target environment. -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files
Re: Building C++ projects with Maven (2)
Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Building C++ projects with Maven (2)
Hi Chris, for maven 1 we create zip files (.nar extension) which we download using the nar plugin. These files have the same name as a properties file which the user depends on, but with a postfix -aol (architecture-os-linker) or -noarch, and extension .nar The -noarch file is for include files. maven 1 downloads the properties file, since the user depends on it. The nar plugin downloads the -aol.nar file and the -noarch.nar file. Both these files are unpacked in the repository, since all native compilers will not understand zip files (java does), so we need the library files and include files in some directory structure. Unpacking is done by the nar plugin. For Maven 2 we use the classifier, as suggested by Brett. However, the plugin will still handle the download and unpacking, since we do not expect the user to modify the pom to be dependent on the classifier. Regards Mark -Original Message- From: Chris Berry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 4:17 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) Hi Mark, So, if I have it right, your solution is to transparently augment the versionId on-the-fly?? And you keep all of these artifacts together in the same repo dir i.e. all under the same version subdir (in m2) i.e. openssl/0.9.8/i386-linux-gcc-openssl-nar-0.9.8.nar Thanks, -- Chris On 11/1/05, Donszelmann, Mark [EMAIL PROTECTED] wrote: Hi that is what we did with our NAR (Native Archive) plugin in Maven 1, which we are porting to M2 at this time. See for maven 1: http://java.freehep.org/freehep-nar-plugin we let the user depend on an artifact, and add Architecture-OS-Linkername to it. Regards Mark Donszelmann -Original Message- From: Roger Hoover [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 12:28 PM To: Maven Users List Subject: Re: Building C++ projects with Maven (2) The concern I would have with this is that you have the same logical package (let's say apr 1.2.2) built for different architectures needing to have a different groupId or artifactId for each architecture type. Unless the groupId or artifactId is constructed dynamically, poms that depend on a native artifact have to depend on a specific architecture type. I think it would be nice to write generic poms that depend on just the logical package (apr 1.2.2 instead of apr 1.2.2 x86_64) and have maven sense the machine architecture (and OS) and fetch the correct native artifact. Roger On 11/1/05, dan tran [EMAIL PROTECTED] wrote: You can use groupId for platform specific or add platform specific string to your artifact id. -D On 11/1/05, Chris Berry [EMAIL PROTECTED] wrote: This brings up a bigger question; How does maven want to handle OS information in the repo?? To be successful w/ other languages like C, the repo will need to delineate information such as i586 and linux. Are these to be rolled into the groupId?? That doesn't smell right. Seems that we may need new Artifact Resolvers that understand this sort of info natively and can transparently supply the the correct pieces to the URL. Cheers, -- Chris On 11/1/05, dan tran [EMAIL PROTECTED] wrote: Hi David, There is a work in progress for native-maven-plugin http://svn.mojo.codehaus.org/trunk/mojo/maven-native/ You can build it and take a look at some doc. -Dan On 11/1/05, David Jackman [EMAIL PROTECTED] wrote: I've just found out that I'm going to need to expand our Maven build process to include several C++ project (which I believe are built using gcc). I seem to remember seeing some traffic on this list from people doing this sort of thing (which I promptly ignored because I wasn't at the time). Can anyone offer some insight on how you got this to work and how you overcame the problems that came up? What plugins are available to build this way and do they do everything you need? Are you able to have dependencies in the Maven repository and have the build use them from there (similar to .jar dependencies)? How do you access the header files, possible library, and runtime library for the different portions of the build? Is there a mini guide for this kind of project in the works? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
