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.so<http://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 commands, e-mail: [EMAIL PROTECTED] > >
