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