You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2008/11/07 17:23:21 UTC
Apache Portable Runtime artifacts
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?
Regards,
Alan
[1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Jason van Zyl <jv...@sonatype.com>.
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 Free High
Energy Physics libraries.
I'm actually going to try and bring all his work to the Sonatype forge
and do a bit of work to get some new releases out.
Mark has been naming artifacts based on what he's been calling AOL:
machine architecture(A), operating-system(O) and linker(L)
This is generally the different set of cases he's had to deal with
when building and distributing binaries.
On 7-Nov-08, at 11:23 AM, 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 publishing these artifacts?
>
>
> Regards,
> Alan
>
> [1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
Nick Kew wrote:
>> You know, the stuff that comes off the build machines, like JARs and
>> WARs and propery files and all that Java cruft. *rofl*
>
> Google doesn't seem to know what that means, either:
>
> http://www.google.com/search?q=%22apr+artifacts%22
>
> Just one mention of the term (in a computing context)
> before Alan's post.
"Artifacts" is maven speak for the final objects that are created at the
end of a build, which in the early days started off as binaries, but now
can mean jars, javadocs, websites, poms, libraries, anything bundled
together, given a version number and formally released.
Publishing APR binaries in a maven repository will help projects like
tomcat that depend on APR for performance.
Because maven repos typically contain binaries, for it to be practical
to deploy APR to a repo there would need to be some kind of sensible
classifier format that describes the platform that APR would be built
for. If that could be worked out, I don't see any reason why binaries
could not be deployed.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Not everyone assembles their machinne with yum or
> apt-get.
But they should.
:-)
-Paul
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Nick Kew wrote:
> On Sat, 08 Nov 2008 18:30:27 +0100
> Branko Čibej <br...@xbc.nu> wrote:
>
>> Nick Kew wrote:
>>> On Fri, 7 Nov 2008 08:23:21 -0800
>>> "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
>>>
>>>
>>>> I would like to publish the APR artifacts
>>>>
>>> The what?
>>>
>> You know, the stuff that comes off the build machines, like JARs and
>> WARs and propery files and all that Java cruft. *rofl*
>
> Google doesn't seem to know what that means, either:
>
> http://www.google.com/search?q=%22apr+artifacts%22
>
> Just one mention of the term (in a computing context)
> before Alan's post.
We are having fun with this, but
http://www.google.com/search?q=build+artifacts
is a more interesting query.
We use gnu autoconf libtool at this point, so it seems to make sense to name
such packages by that target arch string. There's nothing that makes this
impossible, and keeping a private copy might help avoid clashing with a
properly configured system-wide compilation.
If there is something you would like to check-in to describe the build or
create the packages, that can certainly happen. We have rpm and pkgadd
descriptors already. Why not more?
Only ASF committers' binaries are checked into apache.org/ spaces, due to
the trust issues with binaries. But it doesn't sound like a silly idea if
it helps adoption. Not everyone assembles their machinne with yum or
apt-get.
Bill
Re: Apache Portable Runtime artifacts
Posted by Nick Kew <ni...@webthing.com>.
On Sat, 08 Nov 2008 18:30:27 +0100
Branko Čibej <br...@xbc.nu> wrote:
> Nick Kew wrote:
> > On Fri, 7 Nov 2008 08:23:21 -0800
> > "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
> >
> >
> >> I would like to publish the APR artifacts
> >>
> >
> > The what?
> >
>
> You know, the stuff that comes off the build machines, like JARs and
> WARs and propery files and all that Java cruft. *rofl*
Google doesn't seem to know what that means, either:
http://www.google.com/search?q=%22apr+artifacts%22
Just one mention of the term (in a computing context)
before Alan's post.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Apache Portable Runtime artifacts
Posted by Branko Čibej <br...@xbc.nu>.
Nick Kew wrote:
> On Fri, 7 Nov 2008 08:23:21 -0800
> "Alan D. Cabrera" <li...@toolazydogs.com> wrote:
>
>
>> I would like to publish the APR artifacts
>>
>
> The what?
>
You know, the stuff that comes off the build machines, like JARs and
WARs and propery files and all that Java cruft. *rofl*
-- Brane
Re: Apache Portable Runtime artifacts
Posted by Nick Kew <ni...@webthing.com>.
On Fri, 7 Nov 2008 08:23:21 -0800
"Alan D. Cabrera" <li...@toolazydogs.com> wrote:
> I would like to publish the APR artifacts
The what?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Apache Portable Runtime artifacts
Posted by Jason van Zyl <jv...@sonatype.com>.
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 Free High
Energy Physics libraries.
I'm actually going to try and bring all his work to the Sonatype forge
and do a bit of work to get some new releases out.
Mark has been naming artifacts based on what he's been calling AOL:
machine architecture(A), operating-system(O) and linker(L)
This is generally the different set of cases he's had to deal with
when building and distributing binaries.
On 7-Nov-08, at 11:23 AM, 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 publishing these artifacts?
>
>
> Regards,
> Alan
>
> [1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 have a problem with me publishing these artifacts?
>
> What are the specifics of the artifacts you were thinking of publishing?
> APR is not a Java project after all. I do realize that strictly
> speaking, Maven is not just for Java, but any publishing of native code
> into Maven tends to be fraught with difficulties.
>
> It would probably be best for the precise files being published to be
> acked by an APR committer or PMC member before publishing.
> Actually, wouldn't published Maven artifacts be considered an ASF
> release and therefore needful of PMC voting?
I can't quite see how you would have a maven dependency on "APR-1.2.x" such
that the appropriate platform architecture would be grabbed and installed.
AFAIK a maven package is platform neutral. The way dependencies work, it
would be a real mess, since tcnative.jar couldn't just depend on apr-1.2.x
but would have to either package ALL platforms in that jar, or learn some
platform-conditional magic.
Can you provide an illustration of the sort of package you hope to create,
and how dependencies would remain simple to the .jar author consuming apr?
Otherwise it really seems like a total waste of energy.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 have a problem with me publishing these artifacts?
>
> What are the specifics of the artifacts you were thinking of publishing?
> APR is not a Java project after all. I do realize that strictly
> speaking, Maven is not just for Java, but any publishing of native code
> into Maven tends to be fraught with difficulties.
>
> It would probably be best for the precise files being published to be
> acked by an APR committer or PMC member before publishing.
> Actually, wouldn't published Maven artifacts be considered an ASF
> release and therefore needful of PMC voting?
I can't quite see how you would have a maven dependency on "APR-1.2.x" such
that the appropriate platform architecture would be grabbed and installed.
AFAIK a maven package is platform neutral. The way dependencies work, it
would be a real mess, since tcnative.jar couldn't just depend on apr-1.2.x
but would have to either package ALL platforms in that jar, or learn some
platform-conditional magic.
Can you provide an illustration of the sort of package you hope to create,
and how dependencies would remain simple to the .jar author consuming apr?
Otherwise it really seems like a total waste of energy.
Bill
Re: Apache Portable Runtime artifacts
Posted by André Malo <nd...@perlig.de>.
* Graham Leggett wrote:
> André Malo wrote:
> > Doesn't make sense to me, as the ASF doesn't release binaries. Has that
> > been changed?
>
> The ASF routinely releases binaries in Javaland, and even in httpd,
> binaries are released by the ASF for httpd for Windows.
Nope. httpd is only released as source tarball by the ASF. The windows
binaries is not even voted on.
What I'm saying is, it's simply not possible to let the PMC bless a binary
package of APR *as an ASF release*. If someone wants to build them and put
them somewhere he could just do that without even asking. It wouldn't make
any difference.
nd
--
"Solides und umfangreiches Buch"
-- aus einer Rezension
<http://pub.perlig.de/books.html#apache2>
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
André Malo wrote:
> Doesn't make sense to me, as the ASF doesn't release binaries. Has that been
> changed?
The ASF routinely releases binaries in Javaland, and even in httpd,
binaries are released by the ASF for httpd for Windows.
As Java binaries work everywhere (in theory), it is straightforward to
make and depend on released binaries as there is only one binary to release.
Maven supports the idea of both platform independent and platform
specific binaries, what would be needed would be people willing to build
binaries for a particular platform.
Alternatively, if JNI bindings exist for APR (no idea what interface
tomcat uses, but I am assuming there is some kind of Java wrapper there
somewhere), the JNI bindings can be published to a maven repo, and the
APR could then be deployed according whatever the best practice was on
that platform (rpm, deb, pkg, whatever).
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 :)
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Bojan Smojver <bo...@rexursive.com>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Bojan Smojver <bo...@rexursive.com>.
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
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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, we need to
> establish consistency about which string we intend to use to represent
> the general concept of IA-32.
wow - you plan to build itanium 32 bit? now that's one ancient piece of
scrap metal ;-P
> It's perfectly normal and expected for C libraries to depend on other C
> libraries. It's only in the world of JNI where this becomes potentially
> painful.
ACK - I don't think anyone disagrees this is a frustration, simply folks
are disagreeing on what is a rational solution.
>> Version 2.3.x strikes me as really old. Unless I'm missing something,
>> we, in my case, won't have to deal with that corner case.
>
> Really? You think you'll avoid ever having a user who's running Debian
> stable? I think that's a touch unrealistic.
Yup - Debian stable seems much more realistic than itanium pre-64 bit.
>> To give some more color to what I want to do, I want to make OSGi
>> bundles for APR. I would use OSGi's native code loading mechanism to
>> "dispatch" the correct library.
>
> Can you recommend any docs to that give an overview of this mechanism?
Bingo... a clear example is all the list is looking for.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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, we need to
> establish consistency about which string we intend to use to represent
> the general concept of IA-32.
wow - you plan to build itanium 32 bit? now that's one ancient piece of
scrap metal ;-P
> It's perfectly normal and expected for C libraries to depend on other C
> libraries. It's only in the world of JNI where this becomes potentially
> painful.
ACK - I don't think anyone disagrees this is a frustration, simply folks
are disagreeing on what is a rational solution.
>> Version 2.3.x strikes me as really old. Unless I'm missing something,
>> we, in my case, won't have to deal with that corner case.
>
> Really? You think you'll avoid ever having a user who's running Debian
> stable? I think that's a touch unrealistic.
Yup - Debian stable seems much more realistic than itanium pre-64 bit.
>> To give some more color to what I want to do, I want to make OSGi
>> bundles for APR. I would use OSGi's native code loading mechanism to
>> "dispatch" the correct library.
>
> Can you recommend any docs to that give an overview of this mechanism?
Bingo... a clear example is all the list is looking for.
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@ukf.net>.
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
>> --print-architecture", "uname -m", and Java's os.arch manage to be
>> inconsistent more often than not.)
>
> 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?
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, we need to
establish consistency about which string we intend to use to represent
the general concept of IA-32.
>> More of an issue, though, is the dependencies on other system libraries,
>> and what versions thereof, the APR artifact may have. For example, the
>> APR shared lib on my Ubuntu system depends on glibc >= 2.4, and libuuid1.
>>
>> 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 dependencies are not *that* onerous, especially once Debian
>> lenny succeeds etch as stable, they do illustrate the problem.
>
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I have
> to worry about libuuid1 missing? I'm new to APR and am getting my head
> around what it will and will not do for me.
It's perfectly normal and expected for C libraries to depend on other C
libraries. It's only in the world of JNI where this becomes potentially
painful.
>> In particular, beware that the specific version of glibc required isn't
>> something determined just by the apr source, but by the version being
>> compiled against, and even the compiler flags being used.
>>
>> For example, if the chosen option was to force a glibc 2.3.x compatible
>> build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
>> setting the -fno-stack-protector compiler option would disable the
>> features that currently cause us to require glibc 2.4 at run-time if
>> present at compile-time.
>>
>> That might be a viable option for producing an adequately compatible
>> binary for Maven deployment.
>
> Version 2.3.x strikes me as really old. Unless I'm missing something,
> we, in my case, won't have to deal with that corner case.
Really? You think you'll avoid ever having a user who's running Debian
stable? I think that's a touch unrealistic.
> To give some more color to what I want to do, I want to make OSGi
> bundles for APR. I would use OSGi's native code loading mechanism to
> "dispatch" the correct library.
Can you recommend any docs to that give an overview of this mechanism?
Thanks,
Max.
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 not run as effectively as code for i686. One
shouldn't make arbitrary restrictions on how specific the platform can be.
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I have
> to worry about libuuid1 missing? I'm new to APR and am getting my head
> around what it will and will not do for me.
A bit of history on APR and why it exists.
Way back when, when people tried to make Apache httpd portable to many
platforms, the httpd code started getting filled up with endless #ifdefs
that said "if this system do this, if that system do that".
To try and return some sanity, an effort was made to herd together all
the non portable code in httpd into one single library. That library
would offer some portable concepts like (for example) an apr_socket_t
instead of an integer socket, and you would not have to care what
platform you were on any more, you could just use sockets and take it
for granted that they would "just work".
The library that resulted is APR.
Like the JVM itself, APR tries very hard to be portable across
platforms, and to do this, it needs to know how that particular platform
works so you don't have to.
APR makes your life easier because all you need to do is write code that
depends on APR, and (within reason) you no longer have to care exactly
how the particular functionality you are using works on that platform.
Sockets work differently on Windows? You don't have to care.
The problem is that APR itself *does* have to care how the system works,
and about details like libraries that may or may not be installed, so
anybody wanting to package APR into a bundle is going to have to worry
about these issues.
Imagine if you had to try and package up the JVM and include it in a
maven repo, the problems you would face there are similar to the APR case.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 not run as effectively as code for i686. One
shouldn't make arbitrary restrictions on how specific the platform can be.
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I have
> to worry about libuuid1 missing? I'm new to APR and am getting my head
> around what it will and will not do for me.
A bit of history on APR and why it exists.
Way back when, when people tried to make Apache httpd portable to many
platforms, the httpd code started getting filled up with endless #ifdefs
that said "if this system do this, if that system do that".
To try and return some sanity, an effort was made to herd together all
the non portable code in httpd into one single library. That library
would offer some portable concepts like (for example) an apr_socket_t
instead of an integer socket, and you would not have to care what
platform you were on any more, you could just use sockets and take it
for granted that they would "just work".
The library that resulted is APR.
Like the JVM itself, APR tries very hard to be portable across
platforms, and to do this, it needs to know how that particular platform
works so you don't have to.
APR makes your life easier because all you need to do is write code that
depends on APR, and (within reason) you no longer have to care exactly
how the particular functionality you are using works on that platform.
Sockets work differently on Windows? You don't have to care.
The problem is that APR itself *does* have to care how the system works,
and about details like libraries that may or may not be installed, so
anybody wanting to package APR into a bundle is going to have to worry
about these issues.
Imagine if you had to try and package up the JVM and include it in a
maven repo, the problems you would face there are similar to the APR case.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Paul Querna <ch...@force-elite.com>.
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
> needed basis; I don't anticipate this happening often.
I think you are misunderstanding.
On Windows, binary compatibility is something that Microsoft does.
On Linux, each individual Linux vendor maintains their own binary
compatibility.
This means a binary built on Debian might not work on Ubuntu, and
definitely will not run on Redhat or Suse.
A binary built on $Vendor_Linux version 1, might work on version 2 --
but thats up to the vendor to maintain the appropriate libraries, and
the only one that seems to do this somewhat consistently is Redhat or Suse.
This is even before you start talking about dependencies -- libapr on
linux depends on libuuid1. libapr-util can optionally depend on
BerkeleyDB, Oracle, MySQL, Postgres, SQLite, OpenLDAP, etc.
This is a non-trivial endeavor.
> I have to admit that "wrinkles" that you presented above seem to be rare
> corner cases in my world.
I think you are under estimating the ability to make portable binaries
on linux.
It is *possible*, but mostly if you static link *everything*, going so
far to maybe even static link in dietlibc or something -- because glibc
is a massive pain to static link, because their developers don't see the
value in it.
And if you want to make a binary that runs on Linux 2.4 and Linux 2.6,
the only possibility is to restrict yourself to 2.4 features, ie, no
epoll, and to use a static dietlibc.
-Paul
Re: Apache Portable Runtime artifacts
Posted by Paul Querna <ch...@force-elite.com>.
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
> needed basis; I don't anticipate this happening often.
I think you are misunderstanding.
On Windows, binary compatibility is something that Microsoft does.
On Linux, each individual Linux vendor maintains their own binary
compatibility.
This means a binary built on Debian might not work on Ubuntu, and
definitely will not run on Redhat or Suse.
A binary built on $Vendor_Linux version 1, might work on version 2 --
but thats up to the vendor to maintain the appropriate libraries, and
the only one that seems to do this somewhat consistently is Redhat or Suse.
This is even before you start talking about dependencies -- libapr on
linux depends on libuuid1. libapr-util can optionally depend on
BerkeleyDB, Oracle, MySQL, Postgres, SQLite, OpenLDAP, etc.
This is a non-trivial endeavor.
> I have to admit that "wrinkles" that you presented above seem to be rare
> corner cases in my world.
I think you are under estimating the ability to make portable binaries
on linux.
It is *possible*, but mostly if you static link *everything*, going so
far to maybe even static link in dietlibc or something -- because glibc
is a massive pain to static link, because their developers don't see the
value in it.
And if you want to make a binary that runs on Linux 2.4 and Linux 2.6,
the only possibility is to restrict yourself to 2.4 features, ie, no
epoll, and to use a static dietlibc.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Bojan Smojver <bo...@rexursive.com>.
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
already.
--
Bojan
Re: Apache Portable Runtime artifacts
Posted by Bojan Smojver <bo...@rexursive.com>.
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
already.
--
Bojan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Branko Čibej <br...@xbc.nu>.
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 dependencies are not *that* onerous, especially once Debian
>> lenny succeeds etch as stable, they do illustrate the problem.
>
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I
> have to worry about libuuid1 missing? I'm new to APR and am getting
> my head around what it will and will not do for me.
It's supposed to make application developers' lives easier, not system
distributors'. By sticking APR into a Maven repo, you're trying to be
the latter -- by which you inherit all the myriad PITAs that
distributors have to live with.
I seriously suggest you drop the idea at least until you disabuse
yourself of the notion that "linux" and "windows" are the same class
trouble in that respect.
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@ukf.net>.
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
>> --print-architecture", "uname -m", and Java's os.arch manage to be
>> inconsistent more often than not.)
>
> 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?
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, we need to
establish consistency about which string we intend to use to represent
the general concept of IA-32.
>> More of an issue, though, is the dependencies on other system libraries,
>> and what versions thereof, the APR artifact may have. For example, the
>> APR shared lib on my Ubuntu system depends on glibc >= 2.4, and libuuid1.
>>
>> 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 dependencies are not *that* onerous, especially once Debian
>> lenny succeeds etch as stable, they do illustrate the problem.
>
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I have
> to worry about libuuid1 missing? I'm new to APR and am getting my head
> around what it will and will not do for me.
It's perfectly normal and expected for C libraries to depend on other C
libraries. It's only in the world of JNI where this becomes potentially
painful.
>> In particular, beware that the specific version of glibc required isn't
>> something determined just by the apr source, but by the version being
>> compiled against, and even the compiler flags being used.
>>
>> For example, if the chosen option was to force a glibc 2.3.x compatible
>> build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
>> setting the -fno-stack-protector compiler option would disable the
>> features that currently cause us to require glibc 2.4 at run-time if
>> present at compile-time.
>>
>> That might be a viable option for producing an adequately compatible
>> binary for Maven deployment.
>
> Version 2.3.x strikes me as really old. Unless I'm missing something,
> we, in my case, won't have to deal with that corner case.
Really? You think you'll avoid ever having a user who's running Debian
stable? I think that's a touch unrealistic.
> To give some more color to what I want to do, I want to make OSGi
> bundles for APR. I would use OSGi's native code loading mechanism to
> "dispatch" the correct library.
Can you recommend any docs to that give an overview of this mechanism?
Thanks,
Max.
Re: Apache Portable Runtime artifacts
Posted by Branko Čibej <br...@xbc.nu>.
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 dependencies are not *that* onerous, especially once Debian
>> lenny succeeds etch as stable, they do illustrate the problem.
>
> I'm not sure why APR would allow such a system dependancy. APR is
> supposed to make application developers' lives easier. Why would I
> have to worry about libuuid1 missing? I'm new to APR and am getting
> my head around what it will and will not do for me.
It's supposed to make application developers' lives easier, not system
distributors'. By sticking APR into a Maven repo, you're trying to be
the latter -- by which you inherit all the myriad PITAs that
distributors have to live with.
I seriously suggest you drop the idea at least until you disabuse
yourself of the notion that "linux" and "windows" are the same class
trouble in that respect.
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.
-- Brane
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 to be
>>> considered, but
>>> for all but then you start to get things like C library version
>>> being
>>> involved. If you are looking to do anything with apr-util as well
>>> as apr
>>> itself, then the problem explodes with the number of extra
>>> dependencies.
>>
>> I was thinking that the artifact name could be
>>
>> apr-<osname>-<processor>
>>
>> e.g. apr-linux-x86_64. Or we can have a more general
>>
>> apr-<osname>-<processor>-<configuration>
>>
>> where configuration is a token that represents a particular
>> configuration of options, e.g. apr-msdos-8086-aztecc.
>
> This is the right place to start (though may I suggest <arch>-<os>
> rather than <os>-<arch>, for consistency with the prior art that I'm
> aware of, namely autoconf-style system names and the
> freehep-nar-maven-plugin).
>
> (There's also the question of what architecture/processor naming
> scheme
> to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
> --print-architecture", "uname -m", and Java's os.arch manage to be
> inconsistent more often than not.)
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?
> More of an issue, though, is the dependencies on other system
> libraries,
> and what versions thereof, the APR artifact may have. For example, the
> APR shared lib on my Ubuntu system depends on glibc >= 2.4, and
> libuuid1.
>
> 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 dependencies are not *that* onerous, especially once
> Debian
> lenny succeeds etch as stable, they do illustrate the problem.
I'm not sure why APR would allow such a system dependancy. APR is
supposed to make application developers' lives easier. Why would I
have to worry about libuuid1 missing? I'm new to APR and am getting
my head around what it will and will not do for me.
> In particular, beware that the specific version of glibc required
> isn't
> something determined just by the apr source, but by the version being
> compiled against, and even the compiler flags being used.
>
> For example, if the chosen option was to force a glibc 2.3.x
> compatible
> build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
> setting the -fno-stack-protector compiler option would disable the
> features that currently cause us to require glibc 2.4 at run-time if
> present at compile-time.
>
> That might be a viable option for producing an adequately compatible
> binary for Maven deployment.
Version 2.3.x strikes me as really old. Unless I'm missing something,
we, in my case, won't have to deal with that corner case.
> Leaving aside the compatibility issues for a moment, what is the
> intended method for Maven projects to depend on the APR artifacts?
> Would
> they need to specify a specific flavour hardcoded in their POM
> (potentially conditionalized with a long series of profiles, though
> this
> likely wouldn't be flexible enough to do a completely satisfactory
> job)?
> Or is there a better way that I'm unaware of?
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
needed basis; I don't anticipate this happening often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. I would use OSGi's native code loading mechanism to
"dispatch" the correct library.
I have to admit that "wrinkles" that you presented above seem to be
rare corner cases in my world.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 to be
>>> considered, but
>>> for all but then you start to get things like C library version
>>> being
>>> involved. If you are looking to do anything with apr-util as well
>>> as apr
>>> itself, then the problem explodes with the number of extra
>>> dependencies.
>>
>> I was thinking that the artifact name could be
>>
>> apr-<osname>-<processor>
>>
>> e.g. apr-linux-x86_64. Or we can have a more general
>>
>> apr-<osname>-<processor>-<configuration>
>>
>> where configuration is a token that represents a particular
>> configuration of options, e.g. apr-msdos-8086-aztecc.
>
> This is the right place to start (though may I suggest <arch>-<os>
> rather than <os>-<arch>, for consistency with the prior art that I'm
> aware of, namely autoconf-style system names and the
> freehep-nar-maven-plugin).
>
> (There's also the question of what architecture/processor naming
> scheme
> to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
> --print-architecture", "uname -m", and Java's os.arch manage to be
> inconsistent more often than not.)
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?
> More of an issue, though, is the dependencies on other system
> libraries,
> and what versions thereof, the APR artifact may have. For example, the
> APR shared lib on my Ubuntu system depends on glibc >= 2.4, and
> libuuid1.
>
> 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 dependencies are not *that* onerous, especially once
> Debian
> lenny succeeds etch as stable, they do illustrate the problem.
I'm not sure why APR would allow such a system dependancy. APR is
supposed to make application developers' lives easier. Why would I
have to worry about libuuid1 missing? I'm new to APR and am getting
my head around what it will and will not do for me.
> In particular, beware that the specific version of glibc required
> isn't
> something determined just by the apr source, but by the version being
> compiled against, and even the compiler flags being used.
>
> For example, if the chosen option was to force a glibc 2.3.x
> compatible
> build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
> setting the -fno-stack-protector compiler option would disable the
> features that currently cause us to require glibc 2.4 at run-time if
> present at compile-time.
>
> That might be a viable option for producing an adequately compatible
> binary for Maven deployment.
Version 2.3.x strikes me as really old. Unless I'm missing something,
we, in my case, won't have to deal with that corner case.
> Leaving aside the compatibility issues for a moment, what is the
> intended method for Maven projects to depend on the APR artifacts?
> Would
> they need to specify a specific flavour hardcoded in their POM
> (potentially conditionalized with a long series of profiles, though
> this
> likely wouldn't be flexible enough to do a completely satisfactory
> job)?
> Or is there a better way that I'm unaware of?
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
needed basis; I don't anticipate this happening often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. I would use OSGi's native code loading mechanism to
"dispatch" the correct library.
I have to admit that "wrinkles" that you presented above seem to be
rare corner cases in my world.
Regards,
Alan
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@ukf.net>.
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 then you start to get things like C library version being
>> involved. If you are looking to do anything with apr-util as well as apr
>> itself, then the problem explodes with the number of extra dependencies.
>
> I was thinking that the artifact name could be
>
> apr-<osname>-<processor>
>
> e.g. apr-linux-x86_64. Or we can have a more general
>
> apr-<osname>-<processor>-<configuration>
>
> where configuration is a token that represents a particular
> configuration of options, e.g. apr-msdos-8086-aztecc.
This is the right place to start (though may I suggest <arch>-<os>
rather than <os>-<arch>, for consistency with the prior art that I'm
aware of, namely autoconf-style system names and the
freehep-nar-maven-plugin).
(There's also the question of what architecture/processor naming scheme
to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
--print-architecture", "uname -m", and Java's os.arch manage to be
inconsistent more often than not.)
More of an issue, though, is the dependencies on other system libraries,
and what versions thereof, the APR artifact may have. For example, the
APR shared lib on my Ubuntu system depends on glibc >= 2.4, and libuuid1.
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 dependencies are not *that* onerous, especially once Debian
lenny succeeds etch as stable, they do illustrate the problem.
In particular, beware that the specific version of glibc required isn't
something determined just by the apr source, but by the version being
compiled against, and even the compiler flags being used.
For example, if the chosen option was to force a glibc 2.3.x compatible
build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
setting the -fno-stack-protector compiler option would disable the
features that currently cause us to require glibc 2.4 at run-time if
present at compile-time.
That might be a viable option for producing an adequately compatible
binary for Maven deployment.
Leaving aside the compatibility issues for a moment, what is the
intended method for Maven projects to depend on the APR artifacts? Would
they need to specify a specific flavour hardcoded in their POM
(potentially conditionalized with a long series of profiles, though this
likely wouldn't be flexible enough to do a completely satisfactory job)?
Or is there a better way that I'm unaware of?
> I don't use the apr-util code. Can you explain what extra dependencies
> there are?
Many and varied, since one of apr-util's purposes is to provide an
abstracted API over databases, xml parsers, and ldap clients that may or
may not be present at compile time. It would probably be impossible to
sensibly mavenize, so let's just be happy your use-case doesn't require
it! :-)
Max.
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 libraries don't have this luxury.
APR is like the JVM itself, the best JVM is the system installed one,
and the same can be said for APR.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 libraries don't have this luxury.
APR is like the JVM itself, the best JVM is the system installed one,
and the same can be said for APR.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 libraries don't have this luxury.
APR is like the JVM itself, the best JVM is the system installed one,
and the same can be said for APR.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 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 giraffe as well as stock Linux and Windows Vista
>> boxes. I'm sure the combinatorial space that you guys have to deal
>> with is boggling.
>> 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 needed basis; I don't anticipate this happening
>> often.
>> To give some more color to what I want to do, I want to make OSGi
>> bundles for APR. For example, I need access to raw network
>> sockets. I don't want downstream users of my bundles to have to
>> stitch by hand build runtime libraries to get my stuff to work. In
>> my narrow world it's inconvenient and, I believe, unnecessary.
>
> Hmmm...
>
> I think there are potentially two scenarios to be considered, the
> first where a system installed APR is already present, and the
> second is where APR is either not present at all, or not the version
> you want to run.
>
> Potentially what might work is to have versions of APR that are
> statically built, and then bundled into OSGi. Being static, there
> would be few/no dependencies on the underlying system.
>
> Another option is to include a stub bundle that refers to a system
> installed copy of APR. The stub bundle might be smart enough to
> detect when the system copy of APR is either missing, or not within
> the tolerated version range.
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.
Regards,
Alan
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 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 giraffe as well as stock Linux and Windows Vista
>> boxes. I'm sure the combinatorial space that you guys have to deal
>> with is boggling.
>> 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 needed basis; I don't anticipate this happening
>> often.
>> To give some more color to what I want to do, I want to make OSGi
>> bundles for APR. For example, I need access to raw network
>> sockets. I don't want downstream users of my bundles to have to
>> stitch by hand build runtime libraries to get my stuff to work. In
>> my narrow world it's inconvenient and, I believe, unnecessary.
>
> Hmmm...
>
> I think there are potentially two scenarios to be considered, the
> first where a system installed APR is already present, and the
> second is where APR is either not present at all, or not the version
> you want to run.
>
> Potentially what might work is to have versions of APR that are
> statically built, and then bundled into OSGi. Being static, there
> would be few/no dependencies on the underlying system.
>
> Another option is to include a stub bundle that refers to a system
> installed copy of APR. The stub bundle might be smart enough to
> detect when the system copy of APR is either missing, or not within
> the tolerated version range.
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.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 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 giraffe as well as stock Linux and Windows Vista
>> boxes. I'm sure the combinatorial space that you guys have to deal
>> with is boggling.
>> 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 needed basis; I don't anticipate this happening
>> often.
>> To give some more color to what I want to do, I want to make OSGi
>> bundles for APR. For example, I need access to raw network
>> sockets. I don't want downstream users of my bundles to have to
>> stitch by hand build runtime libraries to get my stuff to work. In
>> my narrow world it's inconvenient and, I believe, unnecessary.
>
> Hmmm...
>
> I think there are potentially two scenarios to be considered, the
> first where a system installed APR is already present, and the
> second is where APR is either not present at all, or not the version
> you want to run.
>
> Potentially what might work is to have versions of APR that are
> statically built, and then bundled into OSGi. Being static, there
> would be few/no dependencies on the underlying system.
>
> Another option is to include a stub bundle that refers to a system
> installed copy of APR. The stub bundle might be smart enough to
> detect when the system copy of APR is either missing, or not within
> the tolerated version range.
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.
Regards,
Alan
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 giraffe as
> well as stock Linux and Windows Vista boxes. I'm sure the combinatorial
> space that you guys have to deal with is boggling.
>
> 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
> needed basis; I don't anticipate this happening often.
>
> To give some more color to what I want to do, I want to make OSGi
> bundles for APR. For example, I need access to raw network sockets. I
> don't want downstream users of my bundles to have to stitch by hand
> build runtime libraries to get my stuff to work. In my narrow world
> it's inconvenient and, I believe, unnecessary.
Hmmm...
I think there are potentially two scenarios to be considered, the first
where a system installed APR is already present, and the second is where
APR is either not present at all, or not the version you want to run.
Potentially what might work is to have versions of APR that are
statically built, and then bundled into OSGi. Being static, there would
be few/no dependencies on the underlying system.
Another option is to include a stub bundle that refers to a system
installed copy of APR. The stub bundle might be smart enough to detect
when the system copy of APR is either missing, or not within the
tolerated version range.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
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 giraffe as
> well as stock Linux and Windows Vista boxes. I'm sure the combinatorial
> space that you guys have to deal with is boggling.
>
> 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
> needed basis; I don't anticipate this happening often.
>
> To give some more color to what I want to do, I want to make OSGi
> bundles for APR. For example, I need access to raw network sockets. I
> don't want downstream users of my bundles to have to stitch by hand
> build runtime libraries to get my stuff to work. In my narrow world
> it's inconvenient and, I believe, unnecessary.
Hmmm...
I think there are potentially two scenarios to be considered, the first
where a system installed APR is already present, and the second is where
APR is either not present at all, or not the version you want to run.
Potentially what might work is to have versions of APR that are
statically built, and then bundled into OSGi. Being static, there would
be few/no dependencies on the underlying system.
Another option is to include a stub bundle that refers to a system
installed copy of APR. The stub bundle might be smart enough to detect
when the system copy of APR is either missing, or not within the
tolerated version range.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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-<osname>-<processor>
>> e.g. apr-linux-x86_64. Or we can have a more general
>> apr-<osname>-<processor>-<configuration>
>> 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 you explain what extra
>> dependencies there are?
>
> APR is typically installed at the system level, as a JVM would be,
> and being installed at a system level it would have a number of
> system dependencies installed along with it, some of which are
> optional.
>
> In order to better understand the solution to this, can you explain
> the problem you are trying to solve?
>
> Am I correct in assuming that you would like to access APR from Java
> (like tomcat does)?
>
> If this is correct, it may make more sense to deploy the JNI
> bindings for APR into the maven repo, and then have those bindings
> depend on the system installed version of APR.
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
giraffe as well as stock Linux and Windows Vista boxes. I'm sure the
combinatorial space that you guys have to deal with is boggling.
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
needed basis; I don't anticipate this happening often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. For example, I need access to raw network sockets.
I don't want downstream users of my bundles to have to stitch by hand
build runtime libraries to get my stuff to work. In my narrow world
it's inconvenient and, I believe, unnecessary.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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-<osname>-<processor>
>> e.g. apr-linux-x86_64. Or we can have a more general
>> apr-<osname>-<processor>-<configuration>
>> 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 you explain what extra
>> dependencies there are?
>
> APR is typically installed at the system level, as a JVM would be,
> and being installed at a system level it would have a number of
> system dependencies installed along with it, some of which are
> optional.
>
> In order to better understand the solution to this, can you explain
> the problem you are trying to solve?
>
> Am I correct in assuming that you would like to access APR from Java
> (like tomcat does)?
>
> If this is correct, it may make more sense to deploy the JNI
> bindings for APR into the maven repo, and then have those bindings
> depend on the system installed version of APR.
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
giraffe as well as stock Linux and Windows Vista boxes. I'm sure the
combinatorial space that you guys have to deal with is boggling.
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
needed basis; I don't anticipate this happening often.
To give some more color to what I want to do, I want to make OSGi
bundles for APR. For example, I need access to raw network sockets.
I don't want downstream users of my bundles to have to stitch by hand
build runtime libraries to get my stuff to work. In my narrow world
it's inconvenient and, I believe, unnecessary.
Regards,
Alan
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
Alan D. Cabrera wrote:
> I was thinking that the artifact name could be
>
> apr-<osname>-<processor>
>
> e.g. apr-linux-x86_64. Or we can have a more general
>
> apr-<osname>-<processor>-<configuration>
>
> 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 you explain what extra dependencies
> there are?
APR is typically installed at the system level, as a JVM would be, and
being installed at a system level it would have a number of system
dependencies installed along with it, some of which are optional.
In order to better understand the solution to this, can you explain the
problem you are trying to solve?
Am I correct in assuming that you would like to access APR from Java
(like tomcat does)?
If this is correct, it may make more sense to deploy the JNI bindings
for APR into the maven repo, and then have those bindings depend on the
system installed version of APR.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@ukf.net>.
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 then you start to get things like C library version being
>> involved. If you are looking to do anything with apr-util as well as apr
>> itself, then the problem explodes with the number of extra dependencies.
>
> I was thinking that the artifact name could be
>
> apr-<osname>-<processor>
>
> e.g. apr-linux-x86_64. Or we can have a more general
>
> apr-<osname>-<processor>-<configuration>
>
> where configuration is a token that represents a particular
> configuration of options, e.g. apr-msdos-8086-aztecc.
This is the right place to start (though may I suggest <arch>-<os>
rather than <os>-<arch>, for consistency with the prior art that I'm
aware of, namely autoconf-style system names and the
freehep-nar-maven-plugin).
(There's also the question of what architecture/processor naming scheme
to use - amd64 vs. x86_64, i386 vs. i586 vs. i686, etc. - "dpkg
--print-architecture", "uname -m", and Java's os.arch manage to be
inconsistent more often than not.)
More of an issue, though, is the dependencies on other system libraries,
and what versions thereof, the APR artifact may have. For example, the
APR shared lib on my Ubuntu system depends on glibc >= 2.4, and libuuid1.
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 dependencies are not *that* onerous, especially once Debian
lenny succeeds etch as stable, they do illustrate the problem.
In particular, beware that the specific version of glibc required isn't
something determined just by the apr source, but by the version being
compiled against, and even the compiler flags being used.
For example, if the chosen option was to force a glibc 2.3.x compatible
build, I believe that forcing HAVE_PTHREAD_MUTEX_ROBUST to off and
setting the -fno-stack-protector compiler option would disable the
features that currently cause us to require glibc 2.4 at run-time if
present at compile-time.
That might be a viable option for producing an adequately compatible
binary for Maven deployment.
Leaving aside the compatibility issues for a moment, what is the
intended method for Maven projects to depend on the APR artifacts? Would
they need to specify a specific flavour hardcoded in their POM
(potentially conditionalized with a long series of profiles, though this
likely wouldn't be flexible enough to do a completely satisfactory job)?
Or is there a better way that I'm unaware of?
> I don't use the apr-util code. Can you explain what extra dependencies
> there are?
Many and varied, since one of apr-util's purposes is to provide an
abstracted API over databases, xml parsers, and ldap clients that may or
may not be present at compile time. It would probably be impossible to
sensibly mavenize, so let's just be happy your use-case doesn't require
it! :-)
Max.
Re: Apache Portable Runtime artifacts
Posted by Graham Leggett <mi...@sharp.fm>.
Alan D. Cabrera wrote:
> I was thinking that the artifact name could be
>
> apr-<osname>-<processor>
>
> e.g. apr-linux-x86_64. Or we can have a more general
>
> apr-<osname>-<processor>-<configuration>
>
> 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 you explain what extra dependencies
> there are?
APR is typically installed at the system level, as a JVM would be, and
being installed at a system level it would have a number of system
dependencies installed along with it, some of which are optional.
In order to better understand the solution to this, can you explain the
problem you are trying to solve?
Am I correct in assuming that you would like to access APR from Java
(like tomcat does)?
If this is correct, it may make more sense to deploy the JNI bindings
for APR into the maven repo, and then have those bindings depend on the
system installed version of APR.
Regards,
Graham
--
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 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?
>>>> What are the specifics of the artifacts you were thinking of
>>>> publishing?
>>>> APR is not a Java project after all. I do realize that strictly
>>>> speaking, Maven is not just for Java, but any publishing of native
>>>> code into Maven tends to be fraught with difficulties.
>>> What difficulties are you speaking of?
>
> 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 then you start to get things like C library version being
> involved. If you are looking to do anything with apr-util as well as
> apr
> itself, then the problem explodes with the number of extra
> dependencies.
I was thinking that the artifact name could be
apr-<osname>-<processor>
e.g. apr-linux-x86_64. Or we can have a more general
apr-<osname>-<processor>-<configuration>
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 you explain what extra
dependencies there are?
>>> You are correct, I want to publish the APR libraries so that they
>>> may
>>> be pulled in by projects built with the Maven native plugin [1].
>>>
>>>> It would probably be best for the precise files being published
>>>> to be
>>>> acked by an APR committer or PMC member before publishing.
>>>> Actually, wouldn't published Maven artifacts be considered an ASF
>>>> release and therefore needful of PMC voting?
>>> Makes sense to me. How, exactly, should we do this? Should I file
>>> Jiras w/ the POMs for the artifacts, [2], and then start a vote?
>
> APR lives in Bugzilla rather than JIRA, but I'd suggest the best place
> to start would be posting POMs and build recipes for the binaries to
> go
> with them to this list.
I think that I should iron out the configuration/dependency space that
we are discussing above first.
Thanks for your help!
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 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?
>>>> What are the specifics of the artifacts you were thinking of
>>>> publishing?
>>>> APR is not a Java project after all. I do realize that strictly
>>>> speaking, Maven is not just for Java, but any publishing of native
>>>> code into Maven tends to be fraught with difficulties.
>>> What difficulties are you speaking of?
>
> 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 then you start to get things like C library version being
> involved. If you are looking to do anything with apr-util as well as
> apr
> itself, then the problem explodes with the number of extra
> dependencies.
I was thinking that the artifact name could be
apr-<osname>-<processor>
e.g. apr-linux-x86_64. Or we can have a more general
apr-<osname>-<processor>-<configuration>
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 you explain what extra
dependencies there are?
>>> You are correct, I want to publish the APR libraries so that they
>>> may
>>> be pulled in by projects built with the Maven native plugin [1].
>>>
>>>> It would probably be best for the precise files being published
>>>> to be
>>>> acked by an APR committer or PMC member before publishing.
>>>> Actually, wouldn't published Maven artifacts be considered an ASF
>>>> release and therefore needful of PMC voting?
>>> Makes sense to me. How, exactly, should we do this? Should I file
>>> Jiras w/ the POMs for the artifacts, [2], and then start a vote?
>
> APR lives in Bugzilla rather than JIRA, but I'd suggest the best place
> to start would be posting POMs and build recipes for the binaries to
> go
> with them to this list.
I think that I should iron out the configuration/dependency space that
we are discussing above first.
Thanks for your help!
Regards,
Alan
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@ukf.net>.
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 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?
>>> What are the specifics of the artifacts you were thinking of
>>> publishing?
>>> APR is not a Java project after all. I do realize that strictly
>>> speaking, Maven is not just for Java, but any publishing of native
>>> code into Maven tends to be fraught with difficulties.
>> What difficulties are you speaking of?
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 then you start to get things like C library version being
involved. If you are looking to do anything with apr-util as well as apr
itself, then the problem explodes with the number of extra dependencies.
>> You are correct, I want to publish the APR libraries so that they may
>> be pulled in by projects built with the Maven native plugin [1].
>>
>>> It would probably be best for the precise files being published to be
>>> acked by an APR committer or PMC member before publishing.
>>> Actually, wouldn't published Maven artifacts be considered an ASF
>>> release and therefore needful of PMC voting?
>> Makes sense to me. How, exactly, should we do this? Should I file
>> Jiras w/ the POMs for the artifacts, [2], and then start a vote?
APR lives in Bugzilla rather than JIRA, but I'd suggest the best place
to start would be posting POMs and build recipes for the binaries to go
with them to this list.
> Doesn't make sense to me, as the ASF doesn't release binaries. Has that been
> changed?
Lots of (Java) ASF projects provide binaries on
http://www.apache.org/dist/. I don't know whether those are semantically
considered releases or just arbitrarily distributed files that happen to
coincidentally be derived from actual releases.
Max.
Re: Apache Portable Runtime artifacts
Posted by André Malo <nd...@perlig.de>.
* 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 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?
> >
> > What are the specifics of the artifacts you were thinking of
> > publishing?
> > APR is not a Java project after all. I do realize that strictly
> > speaking, Maven is not just for Java, but any publishing of native
> > code
> > into Maven tends to be fraught with difficulties.
>
> What difficulties are you speaking of?
>
> You are correct, I want to publish the APR libraries so that they may
> be pulled in by projects built with the Maven native plugin [1].
>
> > It would probably be best for the precise files being published to be
> > acked by an APR committer or PMC member before publishing.
> > Actually, wouldn't published Maven artifacts be considered an ASF
> > release and therefore needful of PMC voting?
>
> Makes sense to me. How, exactly, should we do this? Should I file
> Jiras w/ the POMs for the artifacts, [2], and then start a vote?
Doesn't make sense to me, as the ASF doesn't release binaries. Has that been
changed?
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://pub.perlig.de #
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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? Does
>> anyone have a problem with me publishing these artifacts?
>
> What are the specifics of the artifacts you were thinking of
> publishing?
> APR is not a Java project after all. I do realize that strictly
> speaking, Maven is not just for Java, but any publishing of native
> code
> into Maven tends to be fraught with difficulties.
What difficulties are you speaking of?
You are correct, I want to publish the APR libraries so that they may
be pulled in by projects built with the Maven native plugin [1].
> It would probably be best for the precise files being published to be
> acked by an APR committer or PMC member before publishing.
> Actually, wouldn't published Maven artifacts be considered an ASF
> release and therefore needful of PMC voting?
Makes sense to me. How, exactly, should we do this? Should I file
Jiras w/ the POMs for the artifacts, [2], and then start a vote?
Regards,
Alan
[1] http://mojo.codehaus.org/maven-native/native-maven-plugin/
[2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Apache Portable Runtime artifacts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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? Does
>> anyone have a problem with me publishing these artifacts?
>
> What are the specifics of the artifacts you were thinking of
> publishing?
> APR is not a Java project after all. I do realize that strictly
> speaking, Maven is not just for Java, but any publishing of native
> code
> into Maven tends to be fraught with difficulties.
What difficulties are you speaking of?
You are correct, I want to publish the APR libraries so that they may
be pulled in by projects built with the Maven native plugin [1].
> It would probably be best for the precise files being published to be
> acked by an APR committer or PMC member before publishing.
> Actually, wouldn't published Maven artifacts be considered an ASF
> release and therefore needful of PMC voting?
Makes sense to me. How, exactly, should we do this? Should I file
Jiras w/ the POMs for the artifacts, [2], and then start a vote?
Regards,
Alan
[1] http://mojo.codehaus.org/maven-native/native-maven-plugin/
[2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@apache.org>.
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 publishing these artifacts?
What are the specifics of the artifacts you were thinking of publishing?
APR is not a Java project after all. I do realize that strictly
speaking, Maven is not just for Java, but any publishing of native code
into Maven tends to be fraught with difficulties.
It would probably be best for the precise files being published to be
acked by an APR committer or PMC member before publishing.
Actually, wouldn't published Maven artifacts be considered an ASF
release and therefore needful of PMC voting?
Max.
Re: Apache Portable Runtime artifacts
Posted by Max Bowsher <ma...@apache.org>.
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 publishing these artifacts?
What are the specifics of the artifacts you were thinking of publishing?
APR is not a Java project after all. I do realize that strictly
speaking, Maven is not just for Java, but any publishing of native code
into Maven tends to be fraught with difficulties.
It would probably be best for the precise files being published to be
acked by an APR committer or PMC member before publishing.
Actually, wouldn't published Maven artifacts be considered an ASF
release and therefore needful of PMC voting?
Max.