Jason van Zyl wrote:
> It's moving to the Sonatype Labs where we will support it.
This is actually great news !!
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
It's moving to the Sonatype Labs where we will support it.
On 11-Nov-08, at 3:19 AM, Jörg Schaible wrote:
Hi Jason,
Jason van Zyl wrote:
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
wa
On Mon, 2008-11-10 at 21:35 -0600, William A. Rowe, Jr. wrote:
> wow - you plan to build itanium 32 bit? now that's one ancient piece of
> scrap metal ;-P
http://en.wikipedia.org/wiki/IA-32
--
Bojan
-
To unsubscribe, e-mail:
On Sun, 2008-11-09 at 20:26 +0100, Branko Čibej wrote:
> Every major Linux distro in the world has some kind of APR package that
> you can probably use. In this case its really best to rely on vendors to
> do the right thing.
Exactly. And these folks also solved the dual-arch problem for you
alre
Hi Jason,
Jason van Zyl wrote:
> 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
Bojan Smojver wrote:
> On Mon, 2008-11-10 at 21:35 -0600, William A. Rowe, Jr. wrote:
>
>> wow - you plan to build itanium 32 bit? now that's one ancient piece of
>> scrap metal ;-P
>
> http://en.wikipedia.org/wiki/IA-32
Very interesting --- thanks for the link :)
-
Max Bowsher wrote:
>
> Oops, I didn't communicate clearly. What I meant was that on a typical
> system, depending on what piece of software you ask, you will get
> different answers, for example, dpkg --print-architecture showing i386,
> Java's os.arch showing i586 and uname -m showing i686. Hence
Alan D. Cabrera wrote:
> 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:
>> (There's also the question of what architecture/processor naming scheme
>> to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
>> --pr
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 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
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
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
On Nov 8, 2008, at 2:55 PM, Max Bowsher wrote:
André Malo wrote:
* Alan D. Cabrera wrote:
On Nov 8, 2008, at 6:01 AM, 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
On Nov 8, 2008, at 6:01 AM, 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?
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 have a problem with me publ
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 have a problem with me publishing these artifacts?
R
26 matches
Mail list logo
