Just as another use case to throw in...
We use a maven-1 structured repository and we are now beginning to
migrate to the m2 style structure. We use our repository not only to
store java-based build artifacts such as .jar, .war, .ear files, but
also other kinds of release artifacts which might include zips, rpms,
tgz, etc., that come out of C-based build tools. Given maven is
becoming a more platform agnostic build automation system, I am
curious how cpu architecture and operating system build artifacts
will be reflected in the structure of the repository, as well.
We have discussed creating a convention using using groupId/
artifactId or treating arch/os-specific builds as secondary
artifacts. Note also, we presume the scenario where cross compilation
is occurring to support multiple targets.
Thanks. Alex
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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
