Re: [gentoo-java] Split migration-packages

["robert burrell donkin" <robertburrelldonkin@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

(i'd just like to add a few clarifications)

On 5/28/06, Karl Trygve Kalleberg <karltk@gentoo.org> wrote:
>
> 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.


for jars with a full and correct POM (maven project descriptor),  the source
code used to build the release will be available from the tag in the
appropriate repository as noted in the POM. however, most jars do not have
fully correct POMs...

for apache jars, the maven repository @ ibiblio is just a mirror of the
normative java repository @ apache. providing that the binaries are verified
against the signature files created by the release manager and hosted by
apache, they are as trustworthy as building new jars from the source
distributions.

maven2 is starting to distribute source jars (for IDEs). these should match
exactly the binary version.

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.


IMHO there are two separate issues here:

1 there are a relatively small number of jars (which were uploaded in the
early days of maven) whose exact provinence is unknown (at least in terms of
the tag from which the build was created) and some of which are badly
numbered. this issue really hurt the maven team a year or two ago and took a
lot of energy to address. the maven2 repository is much cleaner and is much
better supervised. so, i believe that (going forward) this particular
problem is overstated.

2 security patches are relatively rare in the java world: new minor releases
are much more common. this is particular because many common security issues
with C and C++ are prevented by the langauge but is also cultural. this
approach seems likely to cause difficulties downstream.

In conclusion: binary .jars are banned.


otherwise this wouldn't be gentoo ;-)

> 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


passing a TCK is quite a lot of effort. the process takes a long time even
if the implementation is already ready without the right contacts, it can
also take hard cash. it's probably beyond the means of open source projects
which aren't backed by a big organisation.

- robert

[-- Attachment #2: Type: text/html, Size: 3788 bytes --]