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.