[gentoo-java] Split migration-packages

[gentoo-java] Split migration-packages

[Krzysiek Pawlik]

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


As of now all packages ported to generation 2 are moved from
gentoo-java-experimental to migration-packages.

Any new migrated package has to be moved to migration-packages as well.
It will ease integration of ported packages into the portage tree.

-- 
Krzysiek Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, desktop-dock, x86, java, apache...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-java] Split migration-packages

[Calvin Austin]

I've been working through about 130 packages to gen2 using prefix'd 
builds (EAPI="prefix"), it was an interesting challenge to move 
everything to JDK 5.0 and I have a few fixes and new ebuilds etc to 
commit somewhere. I have the following thoughts on making JDK 5 stable.

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.

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)

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

regards
calvin

Krzysiek Pawlik wrote:

>As of now all packages ported to generation 2 are moved from
>gentoo-java-experimental to migration-packages.
>
>Any new migrated package has to be moved to migration-packages as well.
>It will ease integration of ported packages into the portage tree.
>
>  
>

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Split migration-packages

[Karl Trygve Kalleberg]

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

Re: [gentoo-java] Split migration-packages

[robert burrell donkin]

[-- 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 --]

Re: [gentoo-java] Split migration-packages

[Calvin Austin]

Karl Trygve Kalleberg 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.
>
>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:)
>
>  
>
My hibernate ebuild is based off the ebuild Mike Slinn submitted in 
bugzilla, infact for the most part to get a JDK 5 system you need to 
pull ebuilds from bugzilla or modify your own. Ideally the bugzilla 
ebuilds will eventually get in the tree, many of the changes required 
are harmless to jdk 1.4,  (which is over 4 years old now) I'll be 
posting all the Java 5 ebuilds I used on one of our servers at 
spikesource in the next week

regards
calvin





>Cheers,
>
>-- Karl T
>  
>

-- 
gentoo-java@gentoo.org mailing list