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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
