public inbox for gentoo-java@lists.gentoo.org
 help / color / mirror / Atom feed
From: "William L. Thomson Jr." <wltjr@gentoo.org>
To: Alon Bar-Lev <alon.barlev@gmail.com>
Cc: Vlastimil Babka <caster@gentoo.org>, gentoo-java@lists.gentoo.org
Subject: Re: [gentoo-java] Changing virtual/jdk || deps to prefer the latest version first
Date: Mon, 02 Apr 2007 09:49:22 -0400	[thread overview]
Message-ID: <1175521762.17115.24.camel@wlt.obsidian-studios.com> (raw)
In-Reply-To: <9e0cf0bf0704020616g1d1c0a91t2470ef327c143786@mail.gmail.com>

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

On Mon, 2007-04-02 at 15:16 +0200, Alon Bar-Lev wrote:
> On 4/2/07, Vlastimil Babka <caster@gentoo.org> wrote:
> > > When will we be able to use jdk-1.5 only system?
> >
> > When
> > a) everything is migrated to gen-2
> > b) everything can build with 1.5(+) (even some gen-2 packages can't...)
> 
> Oh... This is what I know...
> Just thought you have some kind of time-line,

There is no time line, we have discussed it a bit. We might bring it up
at our next meeting.

>  since there should be a
> small number of generation-1 packages now.

There is not
http://dev.gentoo.org/~nelchael/java-generation-2/not-migrated-current
http://dev.gentoo.org/~betelgeuse/unported.txt

> Since I didn't like what you have done... We discussed this long
> ago... I like only one jdk to be installed on my system, created patch
> for every one which does not work...

Thanks for submitting these patches. I assume they are just ebuild
patches because if it's more than that. Submissions of patches would
surely be useful.

>  But then you came with the
> generation-2 build which forces 1.4 to be installed, so I faked 1.5 to
> be generation-1 and continue to have one jdk on my system.

Great, where's the patch for Eclipse? Since it REQUIRES 1.4 to be
present to be built. At least that was the last state of the sources
from upstream. 

> But nevermind... All packages listed above are working with 1.5 so
> please convert them to generation-2.

Might want to look to see if stabilization requests have been filed. Or
if the gen 2 versions have been in tree long enough to be stabilized.
Because your requesting what has been done already, and there is a
process to migrating packages.

> I think you should switch into the top-bottom tree scanning selecting
> popular packages like tomcat

Tomcat is one of our best maintained Java apps, if I can toot my own
horn for a bit. Also FYI, your rush to 1.5 causes problems. For example
that patch you provided dropping deps for Tomcat 5.5.x when using 1.5,
via java5 USE flag. Caused several bugs to pop up, a few deps were over
aggressively dropped and I added them back. There is still one remaining
problem with catalina.jar and the manager app when deploying,
restarting, and undeploying an app. A user wasted considerable time
tracking that down.

So we are not looking to introduce breakage, bugs, or problems like that
to our stable tree. By rushing to get everything compiling with, and
using 1.5. Although it is a goal. Others teams might feel that is
acceptable, but we on the Java team and with our Java herd of packages
have pretty high QA standards.

>  and make sure the whole stable tree of
> dependencies is generation-2 compliant.

Thank you for your input. We have been desperately working on this.
Schedule meetings so we can all stay focused, goal oriented, and be
working as a team. However some of us (like me) have lost considerable
time due to breakage else where in the tree. If time was not lost like
that, then we might be further along.

We have been recruiting for some time, and bringing on new people as
fast as we can reasonably. But we are all volunteers, and can only do as
much as we can in our free time. If you are unhappy with the state of
things, I would suggest helping out in the process. Also doing a bit of
home work on said packages or the state of things. Before commenting in
a negative manner towards those busting there rears to maintain 400+
java applications in the Java herd alone. Much less in other parts of
the tree.

Math alone breaks down to like ~40 packages per dev, and with my efforts
on Tomcat and etc. I have little time for gen 2 migration or maintenance
of other packages. All the while trying to increase our package
offerings by packaging stuff like glassfish. Much less virtuals so users
can choose implementations of things like jaf, javamail, jmx,
servlet-api, and etc.

-- 
William L. Thomson Jr.
Gentoo/Java

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-04-02 13:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-01 12:42 [gentoo-java] Changing virtual/jdk || deps to prefer the latest version first Petteri Räty
2007-04-02 11:28 ` Alon Bar-Lev
2007-04-02 12:37   ` Vlastimil Babka
2007-04-02 13:16     ` Alon Bar-Lev
2007-04-02 13:49       ` William L. Thomson Jr. [this message]
2007-04-02 16:52         ` Joshua Nichols
2007-04-02 15:04   ` Petteri Räty
2007-04-02 15:48   ` Petteri Räty
2007-04-02 18:54 ` Vlastimil Babka
2007-04-02 18:57   ` Petteri Räty

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=1175521762.17115.24.camel@wlt.obsidian-studios.com \
    --to=wltjr@gentoo.org \
    --cc=alon.barlev@gmail.com \
    --cc=caster@gentoo.org \
    --cc=gentoo-java@lists.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