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