Alan D. Cabrera wrote:
I was thinking that the artifact name could be
apr--
e.g. apr-linux-x86_64. Or we can have a more general
apr---
where configuration is a token that represents a particular
configuration of options, e.g. apr-msdos-8086-aztecc.
I don't use the apr-util code. Can y
Alan D. Cabrera wrote:
You bring up a good point in that it might be a good idea to describe
the target deployments. I'm sure that the APR team lives in a different
universe than I. You probably have to make sure that the code is
general enough to run on my son's bluetooth enabled talking gi
Alan D. Cabrera wrote:
I'm not sure that we need to choose one over the other. Let me ask you
this, why would we need fine grained detail such as "i386 vs. i586 vs.
i686"? Is that really necessary?
It is, because code compiled for i686 won't run on an i386, and code
written for i386 may n
When introducing Maven during some projects, I see the same problem every time.
They've heard of Maven, but find it a bit too difficult to start with.
So I've been thinking of creating an maven-setup-plugin.
It should be able write a settings.xml file (although: I'm not able to access
userSetting
I suggest you look at Mark's NAR work:
http://java.freehep.org/freehep-nar-plugin/intro.html
I'm talking with Mark to try and make the NAR the standard way to work
with native code so I highly recommend you follow the way he has named
binaries as part of his work in creating/maintaining the
Alan D. Cabrera wrote:
I think in this case, my case, we only need to worry about a few stock
configurations, e.g. Linux and Windows. For me that would handle 99.9%
of my universe. More exotic configurations can use the naming
conventions that we are currently working out and publish on an as
Alan D. Cabrera wrote:
I think that there's something to be said about using the libraries that
are bundled into OSGi rather than using libraries whose provenance is
unknown.
In the Java world that might be true where one binary can be reasonably
expected to work anywhere, but native librari
Max Bowsher wrote:
> Alan D. Cabrera wrote:
>> I would like to publish the APR artifacts into the Maven repository,
>> [1]. I think that the group id should be org.apache.apr and the
>> artifact id should be apr.
>>
>> Does anyone have a problem with these group and artifact ids? Does
>> anyone h
Alan D. Cabrera wrote:
>
> On Nov 9, 2008, at 6:43 AM, Max Bowsher wrote:
>
>> This means it won't work on Debian etch / Ubuntu dapper, for example, or
>> other distros of similar age, nor would it work if libuuid1 was missing
>> - quite unlikely, I admit, but possible.
>>
>> Whilst these dependenc
I suggest you look at Mark's NAR work:
http://java.freehep.org/freehep-nar-plugin/intro.html
I'm talking with Mark to try and make the NAR the standard way to work
with native code so I highly recommend you follow the way he has named
binaries as part of his work in creating/maintaining the
Stephen Connolly wrote:
> AFAIK,
>
> The execution id refers only to a specific plugin, and each execution can
> only match a specific phase... so I don't see the need to tie the execution
> to a goal name, neither to the plugin name...
>
> What I see as bind important is if the plugin is bound t
Benjamin Bentmann wrote:
> Christian Schulte wrote:
>
>> Not having specified an execution id does not necessarily mean someone
>> did not care about it. It means someone explicitly referred to the
>> default execution.
>
> I disagree with this interpretation, mainly because I am not aware of
>
AFAIK,
The execution id refers only to a specific plugin, and each execution can
only match a specific phase... so I don't see the need to tie the execution
to a goal name, neither to the plugin name...
What I see as bind important is if the plugin is bound to multiple phases
and you want to conf
That's a bad example and what if you want to provide defaults for both?
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 09, 2008 6:27 AM
To: Maven Developers List
Subject: Re: Default plugin execution id
Jason van Zyl wrote:
> I don't think an
I'm going to CC the Felix project. I'm sure their perspective will be
very useful.
On Nov 9, 2008, at 7:57 AM, Graham Leggett wrote:
Alan D. Cabrera wrote:
You bring up a good point in that it might be a good idea to
describe the target deployments. I'm sure that the APR team lives
in
On Nov 9, 2008, at 6:43 AM, Max Bowsher wrote:
Alan D. Cabrera wrote:
On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:
The difficulty is that there is no standard on how to manage the
multitude of flavours of native binaries that are possible.
For example, there's architecture and OS that need
On Nov 9, 2008, at 4:31 AM, Graham Leggett wrote:
Alan D. Cabrera wrote:
I was thinking that the artifact name could be
apr--
e.g. apr-linux-x86_64. Or we can have a more general
apr---
where configuration is a token that represents a particular
configuration of options, e.g. apr-msdos-80
Alan D. Cabrera wrote:
> On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:
>> The difficulty is that there is no standard on how to manage the
>> multitude of flavours of native binaries that are possible.
>>
>> For example, there's architecture and OS that need to be considered, but
>> for all but th
how about lifecycle:[packaging]:[phase]
e.g. lifecycle:jar:compile and lifecycle:jar:test-compile
this would have the side-effect that you might need to override both
lifecycle:jar:compile and lifecycle:war:compile to alter all compile
settings, but I see plusses to that too
Sent from my i
Jason van Zyl wrote:
I don't think anyone is generally going to type:
default-execution-id
As said before, I believe it's nice to distinguish executions of
different plugin goals to allow their separate configuration. So how
about appending the goal name like
default-execution-compile
Christian Schulte wrote:
Not having specified an execution id does not necessarily mean someone
did not care about it. It means someone explicitly referred to the
default execution.
I disagree with this interpretation, mainly because I am not aware of
any docs that would indicate this to the
21 matches
Mail list logo
