From: Karl Trygve Kalleberg <karltk@gentoo.org>
To: Calvin Austin <caustin@spikesource.com>
Cc: Krzysiek Pawlik <nelchael@gentoo.org>,
gentoo-java@lists.gentoo.org, java@gentoo.org
Subject: Re: [gentoo-java] Split migration-packages
Date: Sun, 28 May 2006 11:07:34 +0200 [thread overview]
Message-ID: <44796856.1030605@gentoo.org> (raw)
In-Reply-To: <447606BB.50600@spikesource.com>
Calvin Austin wrote:
> 1. source vs jars ebuilds.
> I built everything from source minus one jar file. I had to drop to
> source 1.4 or patch the code in some cases. However some projects are
> based on maven jar repositories, getting a source version of these can
> be a huge project in itself.
That's true, but we'll of course never include any .jars from Maven in
our tree, since we cannot know which evil backdoors they put into their
code: we don't have the source code.
Also, we can never know if we need to do a security update, since the
versions of the jars in the maven repo do not always correspond to an
actual upstream release of anything.
In conclusion: binary .jars are banned.
> 2. Using open source components vs certified binary components.
> Downloading certified jars from Sun or other vendors was a pain, however
> picking up a free implementation that may have never been certified may
> be just as bad if you don't know what you are doing (and caused a long
> tail of dependencies of cause)
The long tail of dependencies is at best a minor nuisance for the user:
Java apps and libraries are tiny. Also, the fact that they can now do
emerge -uD world should weigh up for any minor inconvenience related to
a long dep chain.
A better argument is that maintaining such a long chain of deps is more
cumbersome than just one binary library. However, with proper open
source packages, at least we have a decent shot at making them available
permanently, instead of this eternal catch-up with have to play with Sun.
>
> 3. Varying dependencies
> I ended up with a very simple hibernate 3.1 ebuild for example, the
> current migration ebuild essentially pulls in the rest of jboss
Cool! Show us the source:)
Cheers,
-- Karl T
--
gentoo-java@gentoo.org mailing list
next prev parent reply other threads:[~2006-05-28 9:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-21 21:39 [gentoo-java] Split migration-packages Krzysiek Pawlik
2006-05-25 19:34 ` Calvin Austin
2006-05-28 9:07 ` Karl Trygve Kalleberg [this message]
2006-05-28 11:16 ` robert burrell donkin
2006-06-08 6:12 ` Calvin Austin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44796856.1030605@gentoo.org \
--to=karltk@gentoo.org \
--cc=caustin@spikesource.com \
--cc=gentoo-java@lists.gentoo.org \
--cc=java@gentoo.org \
--cc=nelchael@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox