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] > >
