Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/29 Mark Reinhold : >> Date: Thu, 21 May 2009 16:51:24 +0100 >> From: Andrew John Hughes > >> ... >> >> Looks like the Contributed-by info is wrong. I tried adding the line >> as in the example and jcheck choked: >> >> remote: > Contributed-by: Andrew John Hughes >> remote: >> remote: Invalid contributor attribution >> remote: >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> >> The example is Contributed-by: Ben Bitdiddle > > Right -- as Jon already pointed out, this is a bug in the example. > > More the the point, however, you didn't need a Contributed-by line in > your comment since you are the author. That line is meant to be used > only when the author of the changeset (in hg terms) is not the sole > author of the actual patch. > > - Mark > That's good to hear. Thanks for the clarification as it doesn't seem obvious from the guide. BTW, I also noticed that the -m Merge trick is missing or at least I can't see it on http://openjdk.java.net/guide/repositories.html or http://openjdk.java.net/guide/producingChangeset.html And now I can't find the mail either :( Thanks again, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Thu, 21 May 2009 16:51:24 +0100 > From: Andrew John Hughes > ... > > Looks like the Contributed-by info is wrong. I tried adding the line > as in the example and jcheck choked: > > remote: > Contributed-by: Andrew John Hughes > remote: > remote: Invalid contributor attribution > remote: > remote: abort: pretxnchangegroup.0.jcheck hook failed > > The example is Contributed-by: Ben Bitdiddle Right -- as Jon already pointed out, this is a bug in the example. More the the point, however, you didn't need a Contributed-by line in your comment since you are the author. That line is meant to be used only when the author of the changeset (in hg terms) is not the sole author of the actual patch. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
I'll try and get the example fixed. -- Jon On May 21, 2009, at 10:15 AM, Andrew John Hughes wrote: 2009/5/21 Jonathan Gibbons : Andrew, Yes, Contributed-by: just takes a simple email address. It'll be munged (@ -> " at ") automatically on web pages. -- Jon Ugh, should have thought of that. It's confusing having an example that doesn't work as given :( On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: 2009/5/21 Mark Reinhold : Date: Mon, 18 May 2009 19:17:21 +0100 From: Andrew John Hughes Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ Looks good to me -- go ahead and push when ready. Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 I presume I need to wait a bit due to the current block on pushes though. No, the group integration areas are already open for M4. Is the standard format for such messages documented somewhere? http://openjdk.java.net/guide/producingChangeset.html#changesetComment Thanks. I'd forgotten about the developer guide. It was been discussed for a while, but then things seemed to go quiet. Is it now complete? No, unfortunately no one's had time to work on it, except for minor changes, since the first version. What's there is still relatively accurate. Looks like the Contributed-by info is wrong. I tried adding the line as in the example and jcheck choked: remote: > Contributed-by: Andrew John Hughes remote: remote: Invalid contributor attribution remote: remote: abort: pretxnchangegroup.0.jcheck hook failed The example is Contributed-by: Ben Bitdiddle - Mark Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/21 Jonathan Gibbons : > Andrew, > > Yes, Contributed-by: just takes a simple email address. It'll be munged (@ > -> " at ") automatically on web pages. > > -- Jon > Ugh, should have thought of that. It's confusing having an example that doesn't work as given :( > > On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: > >> 2009/5/21 Mark Reinhold : Date: Mon, 18 May 2009 19:17:21 +0100 From: Andrew John Hughes >>> Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ >>> >>> Looks good to me -- go ahead and push when ready. >>> >> >> Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 >> I presume I need to wait a bit due to the current block on pushes though. >>> >>> No, the group integration areas are already open for M4. >>> >> Is the standard format for such messages documented somewhere? > > http://openjdk.java.net/guide/producingChangeset.html#changesetComment Thanks. I'd forgotten about the developer guide. It was been discussed for a while, but then things seemed to go quiet. Is it now complete? >>> >>> No, unfortunately no one's had time to work on it, except for minor >>> changes, since the first version. What's there is still relatively >>> accurate. >>> >> >> Looks like the Contributed-by info is wrong. I tried adding the line >> as in the example and jcheck choked: >> >> remote: > Contributed-by: Andrew John Hughes >> remote: >> remote: Invalid contributor attribution >> remote: >> remote: abort: pretxnchangegroup.0.jcheck hook failed >> >> The example is Contributed-by: Ben Bitdiddle >> >>> - Mark >>> >> >> Thanks, >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew, Yes, Contributed-by: just takes a simple email address. It'll be munged (@ -> " at ") automatiocally on web pages. -- Jon On May 21, 2009, at 8:51 AM, Andrew John Hughes wrote: 2009/5/21 Mark Reinhold : Date: Mon, 18 May 2009 19:17:21 +0100 From: Andrew John Hughes Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ Looks good to me -- go ahead and push when ready. Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 I presume I need to wait a bit due to the current block on pushes though. No, the group integration areas are already open for M4. Is the standard format for such messages documented somewhere? http://openjdk.java.net/guide/producingChangeset.html#changesetComment Thanks. I'd forgotten about the developer guide. It was been discussed for a while, but then things seemed to go quiet. Is it now complete? No, unfortunately no one's had time to work on it, except for minor changes, since the first version. What's there is still relatively accurate. Looks like the Contributed-by info is wrong. I tried adding the line as in the example and jcheck choked: remote: > Contributed-by: Andrew John Hughes remote: remote: Invalid contributor attribution remote: remote: abort: pretxnchangegroup.0.jcheck hook failed The example is Contributed-by: Ben Bitdiddle - Mark Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/21 Mark Reinhold : >> Date: Mon, 18 May 2009 19:17:21 +0100 >> From: Andrew John Hughes > >> Ok, new webrev created against jdk7/build: >> >> http://fuseyism.com/6841728/webrev.01/ > > Looks good to me -- go ahead and push when ready. > Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06d30bd8c69 >> I presume I need to wait a bit due to the current block on pushes though. > > No, the group integration areas are already open for M4. > Is the standard format for such messages documented somewhere? >>> >>> http://openjdk.java.net/guide/producingChangeset.html#changesetComment >> >> Thanks. I'd forgotten about the developer guide. It was been >> discussed for a while, but then things seemed to go quiet. Is it now >> complete? > > No, unfortunately no one's had time to work on it, except for minor > changes, since the first version. What's there is still relatively > accurate. > Looks like the Contributed-by info is wrong. I tried adding the line as in the example and jcheck choked: remote: > Contributed-by: Andrew John Hughes remote: remote: Invalid contributor attribution remote: remote: abort: pretxnchangegroup.0.jcheck hook failed The example is Contributed-by: Ben Bitdiddle > - Mark > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Mon, 18 May 2009 19:17:21 +0100 > From: Andrew John Hughes > Ok, new webrev created against jdk7/build: > > http://fuseyism.com/6841728/webrev.01/ Looks good to me -- go ahead and push when ready. > I presume I need to wait a bit due to the current block on pushes though. No, the group integration areas are already open for M4. >>> Is the standard format for such messages documented somewhere? >> >> http://openjdk.java.net/guide/producingChangeset.html#changesetComment > > Thanks. I'd forgotten about the developer guide. It was been > discussed for a while, but then things seemed to go quiet. Is it now > complete? No, unfortunately no one's had time to work on it, except for minor changes, since the first version. What's there is still relatively accurate. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/16 Mark Reinhold : >> Date: Fri, 15 May 2009 18:32:14 +0100 >> From: Andrew John Hughes > >> 2009/5/15 Mark Reinhold : >>> One changeset is best. Â You need somehow to revert the changeset >> >> Somehow I thought that's what you were going to say.. :) >> Looks like I can do a hg backout to revert the last changeset, and >> then create a new one. What's the preferred repo to work against? >> jdk7/jdk7? > > The preferred repo is the one into which your change will be pushed. > In this case I'd suggest jdk7/build so that Xiomara's build testing, > which runs in the context of the release-engineering system that does > our product builds, has a chance to catch any problems (which seems > extremely unlikely in this case). > Ok, new webrev created against jdk7/build: http://fuseyism.com/6841728/webrev.01/ I presume I need to wait a bit due to the current block on pushes though. >> I commit the changes because OpenJDK's documentation seems to suggest >> that this is preferred (patch submission says hg export -g is >> preferable, webrev does an (f)outgoing search first). > > Ah, I was assuming you were going to push the change in yourself. If > you'd rather just submit a patch that's fine too; whichever you prefer. > You're right, I do plan to push the change myself. I was just using that as an example of the assumption that the changes would have been committed prior to patch creation, rather than being local uncommitted changes. >> Do Sun >> engineers usually just have their >> patches as uncommitted changes? > > No. My impression (which may be incorrect) is that many Sun engineers > still aren't all that comfortable slinging patches, so instead they tend > to work on several different repos/forests, one per change in progress, > which was a common practice with the old internal TeamWare SCM. > Ah, right -- now it makes sense :) >>> anyway since it'd need a proper comment, with a Sun bug id, before >>> being pushed upstream. (I just created one for you: 6841728.) >> >> It had a bug ID, just a Bugzilla one... > > At the moment we're assigning inbound patches a Sun bug id for tracking > purposes, and still using Sun bug ids uniformly in changeset comments. > That will change, in time, as part of the Bugzilla migration project. > Understood. It will be better all round when we we fully migrate. >> Is the standard format for such messages documented somewhere? > > http://openjdk.java.net/guide/producingChangeset.html#changesetComment > Thanks. I'd forgotten about the developer guide. It was been discussed for a while, but then things seemed to go quiet. Is it now complete? >>> (I can't resist pointing out that if you were using Mercurial patch >>> Â queues you could just pop to that patch, edit, re-test, finalize, >>> Â and then push the resulting changeset upstream.) >> >> Yeah, but can webrev use patch queues yet? ;) > > There are no mq-specific features in webrev, but since an mq-managed > patch shows up as a regular changeset there's no reason you couldn't > create a webrev comparing that changeset to some other one using the > exicting capabilities of the webrev script. > > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Mark Reinhold wrote: Date: Fri, 15 May 2009 18:32:14 +0100 From: Andrew John Hughes [...snip...] (I can't resist pointing out that if you were using Mercurial patch  queues you could just pop to that patch, edit, re-test, finalize,  and then push the resulting changeset upstream.) Yeah, but can webrev use patch queues yet? ;) There are no mq-specific features in webrev, but since an mq-managed patch shows up as a regular changeset there's no reason you couldn't create a webrev comparing that changeset to some other one using the exicting capabilities of the webrev script. Try the webrev -N option, it will create a webrev of the edited working set files against the current tip. -kto
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
An mq patch changeset has a "virtual" tag (in self.repo.tags()) which is not recorded in the .hgtags file. I think even for an mq patch, jcheck can still check about TAB, CR and end white spaces. Max On May 16, 2009, at 9:50 PM, Jonathan Gibbons wrote: Is it not possible to detect that mq is in use/"active" and just bail on jcheck altogether? i.e. jcheck should surely not apply if you're just commiting a patch into your local set of mq patches. -- Jon On May 15, 2009, at 10:36 PM, Max (Weijun) Wang wrote: I've patched my local jcheck a little to work with mq: 1. If "Reviewed-by" is "nobody", accept it 2. Do not use "self.repo.tags()", bit directly read from the .hgtags file. Max On May 16, 2009, at 12:16 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 09:08:39 -0700 From: jonathan.gibb...@sun.com What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. I like having jcheck enabled as a preextension hook, but that didn't work well with mq. Hmm, that bug might get fixed now that the jcheck maintainer is heavily using mq. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Is it not possible to detect that mq is in use/"active" and just bail on jcheck altogether? i.e. jcheck should surely not apply if you're just commiting a patch into your local set of mq patches. -- Jon On May 15, 2009, at 10:36 PM, Max (Weijun) Wang wrote: I've patched my local jcheck a little to work with mq: 1. If "Reviewed-by" is "nobody", accept it 2. Do not use "self.repo.tags()", bit directly read from the .hgtags file. Max On May 16, 2009, at 12:16 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 09:08:39 -0700 From: jonathan.gibb...@sun.com What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. I like having jcheck enabled as a preextension hook, but that didn't work well with mq. Hmm, that bug might get fixed now that the jcheck maintainer is heavily using mq. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
I've patched my local jcheck a little to work with mq: 1. If "Reviewed-by" is "nobody", accept it 2. Do not use "self.repo.tags()", bit directly read from the .hgtags file. Max On May 16, 2009, at 12:16 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 09:08:39 -0700 From: jonathan.gibb...@sun.com What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. I like having jcheck enabled as a preextension hook, but that didn't work well with mq. Hmm, that bug might get fixed now that the jcheck maintainer is heavily using mq. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Fri, 15 May 2009 18:32:14 +0100 > From: Andrew John Hughes > 2009/5/15 Mark Reinhold : >> One changeset is best. Â You need somehow to revert the changeset > > Somehow I thought that's what you were going to say.. :) > Looks like I can do a hg backout to revert the last changeset, and > then create a new one. What's the preferred repo to work against? > jdk7/jdk7? The preferred repo is the one into which your change will be pushed. In this case I'd suggest jdk7/build so that Xiomara's build testing, which runs in the context of the release-engineering system that does our product builds, has a chance to catch any problems (which seems extremely unlikely in this case). > I commit the changes because OpenJDK's documentation seems to suggest > that this is prefered (patch submission says hg export -g is > preferable, webrev does an (f)outgoing search first). Ah, I was assuming you were going to push the change in yourself. If you'd rather just submit a patch that's fine too; whichever you prefer. >Do Sun > engineers usually just have their > patches as uncommitted changes? No. My impression (which may be incorrect) is that many Sun engineers still aren't all that comfortable slinging patches, so instead they tend to work on several different repos/forests, one per change in progress, which was a common practice with the old internal TeamWare SCM. >> anyway since it'd need a proper comment, with a Sun bug id, before >> being pushed upstream. (I just created one for you: 6841728.) > > It had a bug ID, just a Bugzilla one... At the moment we're assigning inbound patches a Sun bug id for tracking purposes, and still using Sun bug ids uniformly in changeset comments. That will change, in time, as part of the Bugzilla migration project. > Is the standard format for such messages documented somewhere? http://openjdk.java.net/guide/producingChangeset.html#changesetComment >> (I can't resist pointing out that if you were using Mercurial patch >> Â queues you could just pop to that patch, edit, re-test, finalize, >> Â and then push the resulting changeset upstream.) > > Yeah, but can webrev use patch queues yet? ;) There are no mq-specific features in webrev, but since an mq-managed patch shows up as a regular changeset there's no reason you couldn't create a webrev comparing that changeset to some other one using the exicting capabilities of the webrev script. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/15 Mark Reinhold : >> Date: Fri, 15 May 2009 16:30:04 +0100 >> From: Andrew John Hughes > >> I was thinking this as I read your mail. It should be easy enough to >> add this as an #else clause to the existing patch in Sanity.gmk. >> What's the best way to handle updating the patch, given that the >> existing patch is a committed changeset? Do I need to somehow revert >> the changeset or is a pair of changesets feasible? > > One changeset is best. You need somehow to revert the changeset > Somehow I thought that's what you were going to say.. :) Looks like I can do a hg backout to revert the last changeset, and then create a new one. What's the preferred repo to work against? jdk7/jdk7? I commit the changes because OpenJDK's documentation seems to suggest that this is prefered (patch submission says hg export -g is preferable, webrev does an (f)outgoing search first). Do Sun engineers usually just have their patches as uncommitted changes? > anyway since it'd need a proper comment, with a Sun bug id, before > being pushed upstream. (I just created one for you: 6841728.) It had a bug ID, just a Bugzilla one... Is the standard format for such messages documented somewhere? > (I can't resist pointing out that if you were using Mercurial patch > queues you could just pop to that patch, edit, re-test, finalize, > and then push the resulting changeset upstream.) > Yeah, but can webrev use patch queues yet? ;) > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Jonathan Gibbons wrote: On May 15, 2009, at 7:53 AM, Kelly O'Hair wrote: Jonathan Gibbons wrote: The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly That is disturbing. You get a dependency error -- this was on Ubuntu 9.04, and I got a dependency conflict between "mercurial" and "mercurial-common", both trying to install some *win32*.py file. It seems mosty benign, but enough that I wasn't sure about the errors I was getting trying to run the latest forest package. -- Jon Not sure of the details, but some Linux distributions of Mercurial seem to have turned on lots of default extensions. This caused all kinds of problems and I think (I hope) they have stopped doing this. This seemed related to the debian packaging of Mercurial? See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511872 Can't say that this what you ran into or not, but I remember several Ubuntu users having problems in our building, some managed to figure out how to disable certain extensions (inotify?) and work ok. -kto
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Mine was definitely an upgrade (from 8.10) but I tried completely removing and reinstalling the mercurial package, and that didn't help. Currently, dpkg --configure -a continues to report a Mercurial problem. -- Jon On May 15, 2009, at 9:19 AM, Peter Zhelezniakov wrote: Mark Reinhold wrote: Date: Fri, 15 May 2009 07:16:01 -0700 From: jonathan.gibb...@sun.com Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5. :-( Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, with the newest version of the forest extension, and it works fine. 9.04 worked for me out-of-the-box, too (almost - i just had to install mercurial and extensions). But didn't upgrade, i installed Ubuntu from scratch. May be that was the difference. -- Peter | x33066 | location: SPB04 | timezone: GMT+03
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Fri, 15 May 2009 20:19:47 +0400 > From: peter.zheleznia...@sun.com > Mark Reinhold wrote: >>> Date: Fri, 15 May 2009 07:16:01 -0700 >>> From: jonathan.gibb...@sun.com >> >>> Yeah, tried that, didn't work for me; I had to do real work so I gave >>> up and downloaded and went back to using 0.9.5. :-( >> >> Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, >> with the newest version of the forest extension, and it works fine. > > 9.04 worked for me out-of-the-box, too (almost - i just had to install > mercurial and extensions). But didn't upgrade, i installed Ubuntu from > scratch. May be that was the difference. Seems unlikely. I upgraded from 8.10 to 9.04. The hg in 8.10 (forget which version it was) worked fine with the new forest extension too. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
On May 15, 2009, at 9:16 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 09:08:39 -0700 From: jonathan.gibb...@sun.com What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. I like having jcheck enabled as a preextension hook, but that didn't work well with mq. Hmm, that bug might get fixed now that the jcheck maintainer is heavily using mq. Multiple hats are very attractive in cases like this. -- Jon - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Mark Reinhold wrote: Date: Fri, 15 May 2009 07:16:01 -0700 From: jonathan.gibb...@sun.com Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5. :-( Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, with the newest version of the forest extension, and it works fine. 9.04 worked for me out-of-the-box, too (almost - i just had to install mercurial and extensions). But didn't upgrade, i installed Ubuntu from scratch. May be that was the difference. -- Peter | x33066 | location: SPB04 | timezone: GMT+03
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Fri, 15 May 2009 09:08:39 -0700 > From: jonathan.gibb...@sun.com > What is your experience with the combination of mq and jcheck? None, so far, since jcheck is disabled in the Jigsaw forest. > I like having jcheck enabled as a preextension hook, but that > didn't work well with mq. Hmm, that bug might get fixed now that the jcheck maintainer is heavily using mq. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
On May 15, 2009, at 9:00 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 16:30:04 +0100 From: Andrew John Hughes I was thinking this as I read your mail. It should be easy enough to add this as an #else clause to the existing patch in Sanity.gmk. What's the best way to handle updating the patch, given that the existing patch is a committed changeset? Do I need to somehow revert the changeset or is a pair of changesets feasible? One changeset is best. You need somehow to revert the changeset anyway since it'd need a proper comment, with a Sun bug id, before being pushed upstream. (I just created one for you: 6841728.) (I can't resist pointing out that if you were using Mercurial patch queues you could just pop to that patch, edit, re-test, finalize, and then push the resulting changeset upstream.) - Mark Mark, What is your experience with the combination of mq and jcheck? I like having jcheck enabled as a preextension hook, but that didn't work well with mq. -- Jon
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Fri, 15 May 2009 16:30:04 +0100 > From: Andrew John Hughes > I was thinking this as I read your mail. It should be easy enough to > add this as an #else clause to the existing patch in Sanity.gmk. > What's the best way to handle updating the patch, given that the > existing patch is a committed changeset? Do I need to somehow revert > the changeset or is a pair of changesets feasible? One changeset is best. You need somehow to revert the changeset anyway since it'd need a proper comment, with a Sun bug id, before being pushed upstream. (I just created one for you: 6841728.) (I can't resist pointing out that if you were using Mercurial patch queues you could just pop to that patch, edit, re-test, finalize, and then push the resulting changeset upstream.) - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/15 Andrew Haley : > Jonathan Gibbons wrote: >> The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and >> (a) the Mercurial package does not completely install correctly >> (b) even if it did, it is version 1.1.2.something, and OpenJDK requires >> 0.9.5. >> The point being that if people need version X of something they will >> download and use it one way or another. > > Point taken. :-) > > However, distros are all built on the build farms, and packages can only > use dependencies that are actually part of the distro. Therefore, > packagers don't install packages outside the distro in their test > buildroots, as it would only mean a failure when pushed to the build farm. > This is exactly my concern, given I'm tackling how to package this up for people using IcedTea7, who in many cases will be using it to create packages of the JavaOne preview for the distros. A quick survey of some of the most popular distros showed that: * Fedora doesn't yet package JIBX at all (https://bugzilla.redhat.com/show_bug.cgi?id=462923) * Debian only includes an older version 1.0.1 and in the stable version it's in 'contrib' which isn't turned on by default. This is presumably an artefact of it previously only building with the proprietary Sun JDK (http://packages.debian.org/search?keywords=jibx&searchon=names&suite=all§ion=all) * Ubuntu, as it follows Debian, has the same 1.0.1 version of JIBX in hardy and intrepid. Again it's in 'multiverse', their equivalent of 'contrib' I believe. A newer version is in Jaunty but I think this is too new (1.1.6) (http://packages.ubuntu.com/search?keywords=jibx&searchon=names&suite=all§ion=all) * Gentoo has JIBX 1.1.5 and that's the version I've been able to build against. Interestingly, the first reaction when I mentioned this to the Gentoo Java devs. was that the low version was a bug and I wanted it bumped to 1.2... In summary, things don't look that good. > Andrew. > > >> On May 15, 2009, at 6:39 AM, Andrew Haley wrote: >> >>> Peter Zhelezniakov wrote: Andrew Haley wrote: > We are not in a position to dictate to a user exactly which version of > JIBX will be installed on their system. Therefore, if JIBX is now a > dependency of OpenJDK we'll have to find a way to make OpenJDK work > with whatever versions of JIBX people choose. To make it clear: JIBX is not a runtime dependency. It is used at build time only. OpenJDK does work regardless of JIBX presence. >>> >>> Sure, thanks for clarifying, but it makes no difference to the real >>> situation: we are not in a position to dictate to someone building >>> OpenJDK exactly which version of JIBX will be installed on their system. >>> The build systems used by distros aren't guaranteed to have exactly >>> Version X of JIBX. >>> >>> Andrew. >>> >>> >>> >>> >> > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/15 Mark Reinhold : >> Date: Thu, 14 May 2009 23:31:58 +0100 >> From: Andrew John Hughes > >> 2009/5/14 phil.r...@sun.com: >>> I do think I know what you want. But I consider its a slippery slope as >>> you have no way of knowing or keeping track of the consequences of >>> not building a particular component. >> >> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that >> risk. It's much the same as if they turn on insane mode or don't >> build the docs. It's a tradeoff of having an incomplete build at the >> end against simplifying the process, and one it is down to the user to >> make. For example, if someone wants to build OpenJDK as a precursor >> to hacking on HotSpot, then they are probably more concerned about >> just completing the build than finding an additional set of >> dependencies for a look and feel they probably won't use. I don't see >> how arbitrarily restricting choice helps anyone. >> >>> I suggest its better to fix the local build problem than push workarounds >>> upstream. >> >> My fear is we will run over this problem again and again. If people >> working on OpenJDK day in and day out are having issues with this, >> then newbies are going to fare even worse. > > I have to agree with Andrew on this one. > > Engineers working on the JDK routinely skip building various components, > yet somehow we've survived. When was the last time, e.g., you built > HotSpot, or javac, or the Windows installer, or generated rpm packages on > Linux? > > There are already lots of ways to disable various components of the > build. The better ones take care to issue a warning during the sanity > check so that people who carelessly set build variables in their shell > environment don't get tripped up too badly, as long as they make sure to > read the sanity log. > > That these happen to be "platform" classes doesn't mean much. The chance > that a Nimbus-disabled build would be mistaken for a product build is > pretty well near zero, given all the testing that we do. > > If this tiny change makes it easier for people to work with our code, > then I'm all for it. > > My only comment on Andrew's actual patch is that Sanity.gmk should be > extended to print a warning when Nimbus is disabled. It otherwise looks > fine to me. > I was thinking this as I read your mail. It should be easy enough to add this as an #else clause to the existing patch in Sanity.gmk. What's the best way to handle updating the patch, given that the existing patch is a committed changeset? Do I need to somehow revert the changeset or is a pair of changesets feasible? > Oh, and if we have somehow become dependent upon a third-party tool > (JIBX) that's so difficult to locate and has such a low commitment to > interface stability, then perhaps we should reconsider that and use a > different tool. > > - Mark > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/15 Mark Reinhold : >> Date: Fri, 15 May 2009 07:16:01 -0700 >> From: jonathan.gibb...@sun.com > >> Yeah, tried that, didn't work for me; I had to do real work so I gave >> up and downloaded and went back to using 0.9.5. :-( > > Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, > with the newest version of the forest extension, and it works fine. > > - Mark > I've also been hacking on the IcedTea forest with Mercurial 1.2.1 and a working forest. The version from: http://bitbucket.org/pmezard/hgforest-crew/ worked for me (and presumably for Andrew Haley too as I passed him the same link). Specifically, I'm using changeset: 91:872a57531db6 :) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
On May 15, 2009, at 7:53 AM, Kelly O'Hair wrote: Jonathan Gibbons wrote: The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly That is disturbing. You get a dependency error -- this was on Ubuntu 9.04, and I got a dependency conflict between "mercurial" and "mercurial-common", both trying to install some *win32*.py file. It seems mosty benign, but enough that I wasn't sure about the errors I was getting trying to run the latest forest package. -- Jon
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Jonathan Gibbons wrote: > The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and > (a) the Mercurial package does not completely install correctly > (b) even if it did, it is version 1.1.2.something, and OpenJDK requires > 0.9.5. > The point being that if people need version X of something they will > download and use it one way or another. Point taken. :-) However, distros are all built on the build farms, and packages can only use dependencies that are actually part of the distro. Therefore, packagers don't install packages outside the distro in their test buildroots, as it would only mean a failure when pushed to the build farm. Andrew. > On May 15, 2009, at 6:39 AM, Andrew Haley wrote: > >> Peter Zhelezniakov wrote: >>> Andrew Haley wrote: We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. >>> >>> To make it clear: JIBX is not a runtime dependency. It is used at build >>> time only. >>> >>> OpenJDK does work regardless of JIBX presence. >> >> Sure, thanks for clarifying, but it makes no difference to the real >> situation: we are not in a position to dictate to someone building >> OpenJDK exactly which version of JIBX will be installed on their system. >> The build systems used by distros aren't guaranteed to have exactly >> Version X of JIBX. >> >> Andrew. >> >> >> >> >
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
OK, it helps to know it might work. Having spent a while fighting issues, I was getting withdrawal symptoms from my jigsaw puzzle, and just wanted something to work ;-) -- Jon On May 15, 2009, at 8:09 AM, Mark Reinhold wrote: Date: Fri, 15 May 2009 07:16:01 -0700 From: jonathan.gibb...@sun.com Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5. :-( Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, with the newest version of the forest extension, and it works fine. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Fri, 15 May 2009 07:16:01 -0700 > From: jonathan.gibb...@sun.com > Yeah, tried that, didn't work for me; I had to do real work so I gave > up and downloaded and went back to using 0.9.5. :-( Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box, with the newest version of the forest extension, and it works fine. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
What OS gave you problems? I know TortoiseHG on Windows had problems with the notify extension, but they tend to turn on every extension on the planet by default. -kto Jonathan Gibbons wrote: Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5. :-( -- Jon On May 15, 2009, at 7:13 AM, Ismael Juma wrote: Hi, Jonathan Gibbons writes: I was getting problems in the extensions (forest, I think was the main stumbling block) which seems not to be supported any longer. Did you check the following? http://bitbucket.org/pmezard/hgforest-crew/overview/ It's linked from the forest extension page with the note: "There's a newer version that should work against post-1.0 releases." Best, Ismael
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Jonathan Gibbons wrote: The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly That is disturbing. (b) even if it did, it is version 1.1.2.something, and OpenJDK requires 0.9.5. I'm pretty sure that is not true. I'm using 1.2+ on my Mac and everything works fine. I don't think you 'have to' use 0.9.5, but you may need a different forest extension and perhaps use the 'clone --pull' option to create repositories. Even the jcheck extension was modified a while back and works with 1.2+. The point being that if people need version X of something they will download and use it one way or another. That's kind of my feeling too. I recently loaded up an Ubuntu 7.10 system (for JavaFX which uses this as their Linux build OS), and discovered that the newest Mercurial I could get was 0.9.4, which was painful. I got it to work, but it was frustrating that the versions get locked down on a system, understandable for the distro to do this, but awkward for doing development on those systems. I won't be using that system much, but it was a bit enlightening. -kto -- Jon On May 15, 2009, at 6:39 AM, Andrew Haley wrote: Peter Zhelezniakov wrote: Andrew Haley wrote: We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. To make it clear: JIBX is not a runtime dependency. It is used at build time only. OpenJDK does work regardless of JIBX presence. Sure, thanks for clarifying, but it makes no difference to the real situation: we are not in a position to dictate to someone building OpenJDK exactly which version of JIBX will be installed on their system. The build systems used by distros aren't guaranteed to have exactly Version X of JIBX. Andrew.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Il giorno ven, 15/05/2009 alle 15.33 +0200, Roman Kennke ha scritto: > Hi, > > > and don't like the idea of being able to disable Nimbus > > because of this dependency. > > Too many negations and ablebables for my parser... Oops. ;-) > > /Roman Argh :) I mean, disabling it for testing is one thing, but I fear that we will end up making it disabled by default just because JIBX is borked. The problem with the current code is that JIBX doesn't really compile, it just compile "enough" to create the jars that openjdk needs. Honestly, I see that this is not a very clean approach, and makes hard for distributions to have this package in (I personally don't care, I have secured the 4 magics jars and this is all I need :) Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Il giorno ven, 15/05/2009 alle 09.53 +0100, Andrew Haley ha scritto: > Andrew John Hughes wrote: > > 2009/5/14 Kelly O'Hair : > >> If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, > >> or in general was able to build with more of the jibx versions > >> (I don't know how hard that would be) does that change things? > > > > It would simplify things a little, yes. I'm not sure it's possible, > > given builds with both older and newer versions fail for different > > reasons. It seems the package doesn't attempt any kind of stable API. > > That surely is the key point. > > It doesn't matter how much we might want a specific version of JIBX, > it isn't going to happen for Linux distributions. Distros generally > pick a particular version of Package X, and if Package Y needs some > other version of Package X then Package Y must be patched or dropped > from the distribution. > > We are not in a position to dictate to a user exactly which version of > JIBX will be installed on their system. Therefore, if JIBX is now a > dependency of OpenJDK we'll have to find a way to make OpenJDK work > with whatever versions of JIBX people choose. > > Andrew. I second that, and don't like the idea of being able to disable Nimbus because of this dependency. Cheers, Mario -- Mario Torre, Software Developer, http://www.jroller.com/neugens/ aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-44 pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Geschäftsführer: Dr. James J. Hunt Please, support open standards: http://endsoftpatents.org/
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Oh, and if we have somehow become dependent upon a third-party tool > (JIBX) that's so difficult to locate and has such a low commitment to > interface stability, then perhaps we should reconsider that and use a > different tool. The decision to remove this tool from the version control, yet still to continue depending on it during the build time is indeed a little puzzling. Obviously the time is scarce and the tasks are many, but how difficult would it be to remove the dependency on JiBX altogether? Unless Nimbus designer is very close to public release *and* it heavily depends on JiBX, what's the compelling reason to keep having this dependency. And if i understand correctly (from either Richard or Jasper), the XMLs generated by Nimbus designer were tweaked manually afterwards. Thanks Kirill
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Yeah, tried that, didn't work for me; I had to do real work so I gave up and downloaded and went back to using 0.9.5. :-( -- Jon On May 15, 2009, at 7:13 AM, Ismael Juma wrote: Hi, Jonathan Gibbons writes: I was getting problems in the extensions (forest, I think was the main stumbling block) which seems not to be supported any longer. Did you check the following? http://bitbucket.org/pmezard/hgforest-crew/overview/ It's linked from the forest extension page with the note: "There's a newer version that should work against post-1.0 releases." Best, Ismael
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Hi, Jonathan Gibbons writes: > I was getting problems in the extensions (forest, I think was the main > stumbling block) which seems not to be supported any longer. Did you check the following? http://bitbucket.org/pmezard/hgforest-crew/overview/ It's linked from the forest extension page with the note: "There's a newer version that should work against post-1.0 releases." Best, Ismael
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
I was getting problems in the extensions (forest, I think was the main stumbling block) which seems not to be supported any longer. -- Jon On May 15, 2009, at 7:05 AM, Andrew John Hughes wrote: 2009/5/15 Anthony Petrov : On 5/15/2009 5:48 PM Jonathan Gibbons wrote: The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly (b) even if it did, it is version 1.1.2.something, and OpenJDK requires 0.9.5. I don't experience any problems using a newer version of Mercurial with OpenJDK. AFAIK this is a minimum version requirement, not an exact one. -- best regards, Anthony Same here. I've been using later versions with both IcedTea and OpenJDK for some time now; basically whatever my distro provides. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/15 Anthony Petrov : > On 5/15/2009 5:48 PM Jonathan Gibbons wrote: >> >> The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and >> (a) the Mercurial package does not completely install correctly >> (b) even if it did, it is version 1.1.2.something, and OpenJDK requires >> 0.9.5. > > I don't experience any problems using a newer version of Mercurial with > OpenJDK. AFAIK this is a minimum version requirement, not an exact one. > > -- > best regards, > Anthony > Same here. I've been using later versions with both IcedTea and OpenJDK for some time now; basically whatever my distro provides. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
On 5/15/2009 5:48 PM Jonathan Gibbons wrote: The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly (b) even if it did, it is version 1.1.2.something, and OpenJDK requires 0.9.5. I don't experience any problems using a newer version of Mercurial with OpenJDK. AFAIK this is a minimum version requirement, not an exact one. -- best regards, Anthony
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and (a) the Mercurial package does not completely install correctly (b) even if it did, it is version 1.1.2.something, and OpenJDK requires 0.9.5. The point being that if people need version X of something they will download and use it one way or another. -- Jon On May 15, 2009, at 6:39 AM, Andrew Haley wrote: Peter Zhelezniakov wrote: Andrew Haley wrote: We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. To make it clear: JIBX is not a runtime dependency. It is used at build time only. OpenJDK does work regardless of JIBX presence. Sure, thanks for clarifying, but it makes no difference to the real situation: we are not in a position to dictate to someone building OpenJDK exactly which version of JIBX will be installed on their system. The build systems used by distros aren't guaranteed to have exactly Version X of JIBX. Andrew.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Peter Zhelezniakov wrote: > Andrew Haley wrote: >> We are not in a position to dictate to a user exactly which version of >> JIBX will be installed on their system. Therefore, if JIBX is now a >> dependency of OpenJDK we'll have to find a way to make OpenJDK work >> with whatever versions of JIBX people choose. > > To make it clear: JIBX is not a runtime dependency. It is used at build > time only. > > OpenJDK does work regardless of JIBX presence. Sure, thanks for clarifying, but it makes no difference to the real situation: we are not in a position to dictate to someone building OpenJDK exactly which version of JIBX will be installed on their system. The build systems used by distros aren't guaranteed to have exactly Version X of JIBX. Andrew.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Hi, > and don't like the idea of being able to disable Nimbus > because of this dependency. Too many negations and ablebables for my parser... Oops. ;-) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew Haley wrote: We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. To make it clear: JIBX is not a runtime dependency. It is used at build time only. OpenJDK does work regardless of JIBX presence. -- Peter | x33066 | location: SPB04 | timezone: GMT+03
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew John Hughes wrote: > 2009/5/14 Kelly O'Hair : >> If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, >> or in general was able to build with more of the jibx versions >> (I don't know how hard that would be) does that change things? > > It would simplify things a little, yes. I'm not sure it's possible, > given builds with both older and newer versions fail for different > reasons. It seems the package doesn't attempt any kind of stable API. That surely is the key point. It doesn't matter how much we might want a specific version of JIBX, it isn't going to happen for Linux distributions. Distros generally pick a particular version of Package X, and if Package Y needs some other version of Package X then Package Y must be patched or dropped from the distribution. We are not in a position to dictate to a user exactly which version of JIBX will be installed on their system. Therefore, if JIBX is now a dependency of OpenJDK we'll have to find a way to make OpenJDK work with whatever versions of JIBX people choose. Andrew.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Kirill Grouchnikov wrote: > Oh, and if we have somehow become dependent upon a third-party tool > (JIBX) that's so difficult to locate and has such a low commitment to > interface stability, then perhaps we should reconsider that and use a > different tool. The decision to remove this tool from the version control, yet still to continue depending on it during the build time is indeed a little puzzling. Obviously the time is scarce and the tasks are many, but how difficult would it be to remove the dependency on JiBX altogether? Unless Nimbus designer is very close to public release *and* it heavily depends on JiBX, what's the compelling reason to keep having this dependency. And if i understand correctly (from either Richard or Jasper), the XMLs generated by Nimbus designer were tweaked manually afterwards. I agree. I'll look into this, but don't expect a fix anytime soon ;) -- Peter
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
> Date: Thu, 14 May 2009 23:31:58 +0100 > From: Andrew John Hughes > 2009/5/14 phil.r...@sun.com: >> I do think I know what you want. But I consider its a slippery slope as >> you have no way of knowing or keeping track of the consequences of >> not building a particular component. > > Sure, but if someone chooses to set DISABLE_NIMBUS then they take that > risk. It's much the same as if they turn on insane mode or don't > build the docs. It's a tradeoff of having an incomplete build at the > end against simplifying the process, and one it is down to the user to > make. For example, if someone wants to build OpenJDK as a precursor > to hacking on HotSpot, then they are probably more concerned about > just completing the build than finding an additional set of > dependencies for a look and feel they probably won't use. I don't see > how arbitrarily restricting choice helps anyone. > >> I suggest its better to fix the local build problem than push workarounds >> upstream. > > My fear is we will run over this problem again and again. If people > working on OpenJDK day in and day out are having issues with this, > then newbies are going to fare even worse. I have to agree with Andrew on this one. Engineers working on the JDK routinely skip building various components, yet somehow we've survived. When was the last time, e.g., you built HotSpot, or javac, or the Windows installer, or generated rpm packages on Linux? There are already lots of ways to disable various components of the build. The better ones take care to issue a warning during the sanity check so that people who carelessly set build variables in their shell environment don't get tripped up too badly, as long as they make sure to read the sanity log. That these happen to be "platform" classes doesn't mean much. The chance that a Nimbus-disabled build would be mistaken for a product build is pretty well near zero, given all the testing that we do. If this tiny change makes it easier for people to work with our code, then I'm all for it. My only comment on Andrew's actual patch is that Sanity.gmk should be extended to print a warning when Nimbus is disabled. It otherwise looks fine to me. Oh, and if we have somehow become dependent upon a third-party tool (JIBX) that's so difficult to locate and has such a low commitment to interface stability, then perhaps we should reconsider that and use a different tool. - Mark
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Andrew John Hughes wrote: 2009/5/14 Phil Race : I do think I know what you want. But I consider its a slippery slope as you have no way of knowing or keeping track of the consequences of not building a particular component. Sure, but if someone chooses to set DISABLE_NIMBUS then they take that risk. It's much the same as if they turn on insane mode or don't Right. Until one day they stuff it into their .bashrc and forget about it, and risk breaking the build inadvertently later or spending time trying to figure out why their changes don't have any effect.. But that may be just me =) Thanks, Dmitri build the docs. It's a tradeoff of having an incomplete build at the end against simplifying the process, and one it is down to the user to make. For example, if someone wants to build OpenJDK as a precursor to hacking on HotSpot, then they are probably more concerned about just completing the build than finding an additional set of dependencies for a look and feel they probably won't use. I don't see how arbitrarily restricting choice helps anyone. I suggest its better to fix the local build problem than push workarounds upstream. My fear is we will run over this problem again and again. If people working on OpenJDK day in and day out are having issues with this, then newbies are going to fare even worse. -phil. Andrew John Hughes wrote: 2009/5/14 Phil Race : There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks, In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/14 Kelly O'Hair : > If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, > or in general was able to build with more of the jibx versions > (I don't know how hard that would be) does that change things? > > -kto > > Andrew John Hughes wrote: >> >> 2009/5/14 Phil Race : >>> >>> I do think I know what you want. But I consider its a slippery slope as >>> you have no way of knowing or keeping track of the consequences of >>> not building a particular component. >> >> Sure, but if someone chooses to set DISABLE_NIMBUS then they take that >> risk. It's much the same as if they turn on insane mode or don't >> build the docs. It's a tradeoff of having an incomplete build at the >> end against simplifying the process, and one it is down to the user to >> make. For example, if someone wants to build OpenJDK as a precursor >> to hacking on HotSpot, then they are probably more concerned about >> just completing the build than finding an additional set of >> dependencies for a look and feel they probably won't use. I don't see >> how arbitrarily restricting choice helps anyone. >> >>> I suggest its better to fix the local build problem than push workarounds >>> upstream. >> >> My fear is we will run over this problem again and again. If people >> working on OpenJDK day in and day out are having issues with this, >> then newbies are going to fare even worse. >> >>> -phil. >>> >>> Andrew John Hughes wrote: 2009/5/14 Phil Race : > > There's public API associated with Nimbus in javax.swing.plaf.nimbus > so I don't think many people will want to use that facility and it > doesn't > seem appropriate to have it in the jdk7 source train. > > -phil. > > > Andrew John Hughes wrote: >> >> HI all, >> >> I have a simple patch that allows the building of the Nimbus L'n'F >> (which has a dependency on a specific version of JIBX, 1.1.5) to be >> turned off so the user can trade build simplicity for a lack of Nimbus >> support and curved buttons in Swing. >> >> The bug report is here: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >> >> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >> having some issues getting access to cr.openjdk.java.net) >> >> Thanks, In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream. >> >> >> > It would simplify things a little, yes. I'm not sure it's possible, given builds with both older and newer versions fail for different reasons. It seems the package doesn't attempt any kind of stable API. I'm still think it's better to give people the option rather than forcing a dependency when it's not critical to the build. I recall seeing discussion on the OpenJDK lists and IRC channel in the past about being able to disable some of the graphical stuff, which is more tricky to contemplate but again there is some demand for it. However, I guess this is contrary to the way OpenJDK works, which very much seems to take an all-or-nothing approach :( I hope JDK7's module system will improve on this! -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
If the OpenJDK was able to build with jibx 1.1.6 or 1.2.1, or in general was able to build with more of the jibx versions (I don't know how hard that would be) does that change things? -kto Andrew John Hughes wrote: 2009/5/14 Phil Race : I do think I know what you want. But I consider its a slippery slope as you have no way of knowing or keeping track of the consequences of not building a particular component. Sure, but if someone chooses to set DISABLE_NIMBUS then they take that risk. It's much the same as if they turn on insane mode or don't build the docs. It's a tradeoff of having an incomplete build at the end against simplifying the process, and one it is down to the user to make. For example, if someone wants to build OpenJDK as a precursor to hacking on HotSpot, then they are probably more concerned about just completing the build than finding an additional set of dependencies for a look and feel they probably won't use. I don't see how arbitrarily restricting choice helps anyone. I suggest its better to fix the local build problem than push workarounds upstream. My fear is we will run over this problem again and again. If people working on OpenJDK day in and day out are having issues with this, then newbies are going to fare even worse. -phil. Andrew John Hughes wrote: 2009/5/14 Phil Race : There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks, In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/14 Phil Race : > I do think I know what you want. But I consider its a slippery slope as > you have no way of knowing or keeping track of the consequences of > not building a particular component. Sure, but if someone chooses to set DISABLE_NIMBUS then they take that risk. It's much the same as if they turn on insane mode or don't build the docs. It's a tradeoff of having an incomplete build at the end against simplifying the process, and one it is down to the user to make. For example, if someone wants to build OpenJDK as a precursor to hacking on HotSpot, then they are probably more concerned about just completing the build than finding an additional set of dependencies for a look and feel they probably won't use. I don't see how arbitrarily restricting choice helps anyone. > I suggest its better to fix the local build problem than push workarounds > upstream. My fear is we will run over this problem again and again. If people working on OpenJDK day in and day out are having issues with this, then newbies are going to fare even worse. > > -phil. > > Andrew John Hughes wrote: >> >> 2009/5/14 Phil Race : >>> >>> There's public API associated with Nimbus in javax.swing.plaf.nimbus >>> so I don't think many people will want to use that facility and it >>> doesn't >>> seem appropriate to have it in the jdk7 source train. >>> >>> -phil. >>> >>> >>> Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks, >> >> In my experience, it's usually a bad idea to pre-judge what people want. >> >> I created and posted this patch because a number of us working on >> OpenJDK have already had issues trying to build with this enabled. >> I'm not suggesting by any means that you'd want this enabled in a >> production build. But it helps reduce the build requirements of >> completing an OpenJDK build and, to my mind, allowing more people to >> build OpenJDK allows more people to make worthwhile contributions. >> >> I've already added this to IcedTea for this reason and I don't see >> what harm it does to have the option available upstream. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
I do think I know what you want. But I consider its a slippery slope as you have no way of knowing or keeping track of the consequences of not building a particular component. I suggest its better to fix the local build problem than push workarounds upstream. -phil. Andrew John Hughes wrote: 2009/5/14 Phil Race : There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks, In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream.
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
2009/5/14 Phil Race : > There's public API associated with Nimbus in javax.swing.plaf.nimbus > so I don't think many people will want to use that facility and it doesn't > seem appropriate to have it in the jdk7 source train. > > -phil. > > > Andrew John Hughes wrote: >> >> HI all, >> >> I have a simple patch that allows the building of the Nimbus L'n'F >> (which has a dependency on a specific version of JIBX, 1.1.5) to be >> turned off so the user can trade build simplicity for a lack of Nimbus >> support and curved buttons in Swing. >> >> The bug report is here: >> https://bugs.openjdk.java.net/show_bug.cgi?id=100054 >> >> And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still >> having some issues getting access to cr.openjdk.java.net) >> >> Thanks, > In my experience, it's usually a bad idea to pre-judge what people want. I created and posted this patch because a number of us working on OpenJDK have already had issues trying to build with this enabled. I'm not suggesting by any means that you'd want this enabled in a production build. But it helps reduce the build requirements of completing an OpenJDK build and, to my mind, allowing more people to build OpenJDK allows more people to make worthwhile contributions. I've already added this to IcedTea for this reason and I don't see what harm it does to have the option available upstream. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
Is that a 'seems ok'? --- The makefiles changes seem fine to me. -kto Phil Race wrote: There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks,
Re: Request for review: Bug 100054: Make building the Nimbus look 'n' feel optional
There's public API associated with Nimbus in javax.swing.plaf.nimbus so I don't think many people will want to use that facility and it doesn't seem appropriate to have it in the jdk7 source train. -phil. Andrew John Hughes wrote: HI all, I have a simple patch that allows the building of the Nimbus L'n'F (which has a dependency on a specific version of JIBX, 1.1.5) to be turned off so the user can trade build simplicity for a lack of Nimbus support and curved buttons in Swing. The bug report is here: https://bugs.openjdk.java.net/show_bug.cgi?id=100054 And the webrev is here: http://fuseyism.com/100054/webrev.00/ (still having some issues getting access to cr.openjdk.java.net) Thanks,
