Re: Modules names and other details for new classpath bug product
> "David" == David Daney <[EMAIL PROTECTED]> writes: David> It sounds a bit questionable to merge the bug tracking system before David> we have a single merged code base. Classpath and libgcj are really like different branches of a single source base. They mostly share code, but some parts are different and they move at different speeds -- I see the situation as being analogous to the difference between the trunk and the gui branch. I think having a shared bug database is basically an administrative move, recognizing that most of these bugs are really shared. We can manage them the way we manage bugs on any branches. There are already a fair number of bugs in the gcc bugzilla that really are classpath bugs... merging like this just makes it simpler to push bugs upstream, and for classpath and gcj hackers to have a shared view of the library's state. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi. Stuart Ballard wrote: Is there a plan for getting them to properly merge? IMHO a difference of only 25 files suggests that it should be perfectly possible for gcj to use an out-of-the-box classpath build and merely prepend a custom jar file containing those 25 files to the beginning of its bootclasspath. I agree that merging the bug databases is a step in the right direction, but I share David's concern about merging the bug databases without actually merging the codebases. If there's some kind of concrete plan as to how a codebase merge is going to be achieved, it might alleviate some of those concerns. The same was proposed by Archie Cobbs but no one answered to this. Considering GNU Classpath the root (of all evil :P ) for all Free Java projects seems like a good idea for me. What speaks against this? cu Robert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> On Mon, 14 Feb 2005 20:32:38 +0100, Mark Wielaard <[EMAIL PROTECTED]> wrote: >> It is a concern that we have not been able to completely merge libgcj >> and GNU Classpath. Stuart> Is there a plan for getting them to properly merge? IMHO a difference Stuart> of only 25 files suggests that it should be perfectly possible for gcj Stuart> to use an out-of-the-box classpath build and merely prepend a custom Stuart> jar file containing those 25 files to the beginning of its Stuart> bootclasspath. libgcj is weird, so the bootclasspath trick won't actually work for us. But yeah, merging is a pain, and since Michael told us today he wouldn't have much time for it, today on irc we brainstormed a bit and came up with the proposal that Tom Fitzsimmons posted to the gcj list today. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
David Daney wrote: My understanding is that you want to integrate the libgcj and classpath bug databases with but still maintain the current situation with the actual code where there are separate code bases. How would a bug be marked that is fixed in libgcj and not fixed in classpath? In general, that shouldn't happen. libgcj developers should be in the habit of committing such fixes simultaniously to classpath. In the rare case where for some technical reason a fix can't be committed to the classpath repository, this could be handled with something like the reported-against/known-to-work/known-to-fail fields in GCC. It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. I don't think so. The vast majority of the code is merged. The vast majority of class library bugs are applicable to both libgcj and classpath. There may be a few issues to overcome, but it will be much more convenient to have a single combined bug database. For one thing, if someone does file a bug against libgcj that is really a generic classpath bug, it should be very easy to "move" the bug upstream just by re-categorizing it. Bryce ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: >>This seems like putting the horse before the cart. > > If you have a concrete proposal to help out the active mergers (mostly > Michael Koch for classpath<->libgcj and gui<->classpath, Graydon Hoare > for gui<->libgcj, Andrew Hughes for classpath<->generic and Dalibor > Topic for classpath<->kaffe) then I am sure everybody would be > interested. What about the proposal to just have one source tree (Classpath) for the 95% of the code that's the same, and let libgcj have its 25 files that differ stored separately? Then you compile these class files and ensure they sit before the 'stock' Classpath files in the bootclasspath. By the way, this is what JC does and it works fine. An added advantage is that you can share a Classpath installation among more than one free VM. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 12:24 -0800, David Daney wrote: > Mark Wielaard wrote: > > > If bugs stay fixed on only one code branch we are doing something > > seriously wrong. > > > >>How would a bug be marked that is fixed in libgcj and not fixed in > >>classpath? > > > > That should really not happen. > > It will always happen until someone manually merges. Yes. And that should normally be happing pretty quickly these days. > When I commit changes I only do it for libgcj, I never merge to > classpath. So it *will* happen for any changes I commit. Sure. But that just means the we can assume the bug as closed, since someone will then merge that fix to one of the other tree. See the comparison pages in my last email. Some people even get email from scripts each night with the new diffs between the trees. If you want we can setup a real mailinglist for that. Most people actually have commit access to GNU Classpath and libgcj. I am really not seeing much of a problem with some people just committing to one tree at times. It would be better if GNU Classpath could be seen as the upstream of libgcj, kaffe, etc. and fixes only flowing in one direction. But this isn't the case at the moment, although it is much better then a few years ago. Currently it is just a little annoyance at times. Not something that needs an immediate fix. If only because it is on one hand not that big a problem and on the other hand much harder to fix then merging the bug databases. > > It is a concern that we have not been able to completely merge libgcj > > and GNU Classpath. But merging the bug reporting mechanisms of both is a > > step in the right direction for coordinating bug fixing and keeping the > > code in sync even more. > > This seems like putting the horse before the cart. If you have a concrete proposal to help out the active mergers (mostly Michael Koch for classpath<->libgcj and gui<->classpath, Graydon Hoare for gui<->libgcj, Andrew Hughes for classpath<->generic and Dalibor Topic for classpath<->kaffe) then I am sure everybody would be interested. I personally think that getting more resources (the bug database in this case) in the same place so we are at least getting rid of the bug-mergers (which we don't really have!) is a step in the right direction. Especially since the separate bug reporting is really hurting us at the moment. Wish I could magically make all code bases equal and the same really... Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
Hi Chris, On Mon, 2005-02-14 at 19:50 +, Chris Burdess wrote: > What's the plan for auxiliary classpath modules such as inetlib and > cp-tools? Are they still managed in the Savannah bug tracker? The current plan is to also move them over and assign them separate categories/modules in the new 'classpath' product. This will make it easier to just point any "GNU Classpath related product" user to the same bug database. That will also make it easier for us hackers to correctly move bugs to another module if it is determined that the bug is in some other subsystem. See my follow up email to the classpath and gcj mailinglist for the proposal of the actual module and version names to use. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
On Mon, 14 Feb 2005 20:32:38 +0100, Mark Wielaard <[EMAIL PROTECTED]> wrote: > It is a concern that we have not been able to completely merge libgcj > and GNU Classpath. Is there a plan for getting them to properly merge? IMHO a difference of only 25 files suggests that it should be perfectly possible for gcj to use an out-of-the-box classpath build and merely prepend a custom jar file containing those 25 files to the beginning of its bootclasspath. I agree that merging the bug databases is a step in the right direction, but I share David's concern about merging the bug databases without actually merging the codebases. If there's some kind of concrete plan as to how a codebase merge is going to be achieved, it might alleviate some of those concerns. (I also regularly pester the Kaffe list with a similar question because again, the differences seem so small that it *must* be possible to do something better with Dalibor's time than waste it on constant merging of the other 3175 files) Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: If bugs stay fixed on only one code branch we are doing something seriously wrong. How would a bug be marked that is fixed in libgcj and not fixed in classpath? That should really not happen. It will always happen until someone manually merges. When I commit changes I only do it for libgcj, I never merge to classpath. So it *will* happen for any changes I commit. It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Perhaps I am misunderstanding what you are recommending. It is a concern that we have not been able to completely merge libgcj and GNU Classpath. But merging the bug reporting mechanisms of both is a step in the right direction for coordinating bug fixing and keeping the code in sync even more. This seems like putting the horse before the cart. Just my $0.02, I will keep quiet now. David Daney. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Wielaard wrote: If there are no objections we would like to close down the savannah bug tracker for GNU Classpath and add a new "product" classpath in GCC bugzilla which contains all the current bug reports. This new 'classpath' product shall be used exclusively in the future for all core library bug reports in either GNU Classpath or libgcj as long as they are "generic" bugs. What's the plan for auxiliary classpath modules such as inetlib and cp-tools? Are they still managed in the Savannah bug tracker? - -- Chris Burdess -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iD8DBQFCEQEU6dl1DEqHgrgRAu5XAKCOJPpHjBZz3lC2+BX4BgM0h/Ro3wCfR3ym 42mdQvxBtoJ02i2SIZK+Ots= =AU3Q -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Calientra Screenshot using CP-current
Hi there, After a long pause I am finally back in GNU CP :-) I have successfully got running Calientra (formerly known as Ontographics) nearly out of the box with current CVS of GNU Classpath. A screenshot of this can be found here: http://www.ontographics.com/~roman/Calientra-Screenshot.png Notable observations: - this is using Java2D with Cairo and GUI is completely Swing - Animation of the graph works fine, speed is not as good as in Suns JDK, but that's probably no surprise with JamVM. I'll try to native-compile it soon as well as other VMs - I was able to create new nodes using the main menu, but not the right-click context menu (JPopupMenu) - The text box (JEditorPane) on the right is not working - The text field for editing new nodes is also not working, thus 'uninitializedValue') in all created nodes - File dialog is not working - I cannot read saved documents, this involves XML parsing and unzipping. Maybe I have missed something - I had to rip off RTF support for the text editor on the right, this is obviously not yet implemented All in all I must say that this is already pretty cool. Maybe we will soon more Swing apps running with GNU Classpath. Please tell me which parts are already in the works and in which I can do something on my own. I will look into this in more depth the next days so I think I'll discover some more bugs and more already working features ;-) . Best regards, Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 10:29 -0800, David Daney wrote: > My understanding is that you want to integrate the libgcj and classpath > bug databases with but still maintain the current situation with the > actual code where there are separate code bases. Yes, but the code bases are actually not that separate. Fixes in one of the trees are merged within days most of the time. Of the around 3200 files just about 25 are/should be really different. And some of these are different by design. See also the GNU Classpath compare pages that track any differences between the various GNU Classpath branches (generics, kaffe, libgcj, gui). http://developer.classpath.org/compare/ A big THANKS should go to Michael Koch for staying on top of this. He does a hell of a job trying to keep the branches in sync! He would of course like help whenever possible. I am hoping a central bug database where people can see an issue is fixed will help with getting more volunteers merging fixes between the trees regularly. If bugs stay fixed on only one code branch we are doing something seriously wrong. > How would a bug be marked that is fixed in libgcj and not fixed in > classpath? That should really not happen. The proposal is for a bug database that has all the "generic" bugs in the core class library as shared by all runtimes, gcj, kaffe, ikvm.net, etc. There should be a separate module/category in the gcc bugzilla for 'libgcj' runtime issues and runtime specific classes/files. (Just like the other runtimes/compilers would keep their own bug reporting mechanism for non-core-class-library specific bugs.) > It sounds a bit questionable to merge the bug tracking system before we > have a single merged code base. > > Perhaps I am misunderstanding what you are recommending. It is a concern that we have not been able to completely merge libgcj and GNU Classpath. But merging the bug reporting mechanisms of both is a step in the right direction for coordinating bug fixing and keeping the code in sync even more. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
David Daney wrote: How would a bug be marked that is fixed in libgcj and not fixed in classpath? It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Maybe we shuld treat libgcj and classpath as branches of a common "virtual repository". This does not necessaily mean using the same cvs (or snv) repository, though that is an option. It does mean marking bugs in bugzilla in as *if* they were branches. It would require thinking about naming convention for "target milestones" etc. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Hi, On Mon, 2005-02-14 at 18:30 +0100, [EMAIL PROTECTED] wrote: > > - Version numbers. > > I don't have a very good suggestion here. Of course we should just > > have the GNU Classpath version numbers there (0.13, 0.14, and up). But > > those are not the same as used by GCC. There is no good/perfect > > mapping between libgcj and classpath version numbers. > > That was my first question; if AWT/Swing bugs are reported for GCJ they > 'should' be mapped to a classpath release, if possible. But I have no idea > how to do that :) There will probably be much more GNU Classpath releases/versions then libgcj versions. We can probably add GCC/libgcj version numbers but only use them in the "Known to fail/Known to work" fields. > > - Move the bugs currently in the savannah bug tracker to > > gcc.gnu.org/bugzilla. [...] I will move at least > > the open ones by hand (currently 59 open bugs). > > My reported bugs will then nog be registred under my email? Should all > classpath bug-reporters (that want to 'keep' their bugs) open an account > on the gcc bugtracker? Just got email from Sylvain Beucler, one of the savannah hackers, and Daniel Berlin, the GCC bugmaster. We will be able to get a sql-script export from the savannah-tracker that we can use to import into bugzilla. So, if all goes well, most attributes of the savannah bugs should be preserved when they are put into gcc bugzilla. GCC bugzilla has a email alias feature as far as I know. So you should be able to alias your bugzilla account/email-address to the one used in the savannah bugtracker (id). I'll explicitly ask about this when we do the actual migration (most probably not before March 1). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: inetlib, texidoclet, gjdoc, cp-tools, automakejar (Are all these necessary? Maybe just gjdoc and cp-tools?) There will be a new TexiDoclet (rewritten from scratch) soon and it will probably make sense to put it into the same repository as Gjdoc. So I'd say the current TexiDoclet can go in the attic instead. Julian ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
Hi, On Mon, 2005-02-14 at 11:25 -0600, Archie Cobbs wrote: > Please make sure that there are two separate categories for bugs > that are classpath bugs (i.e., independent of the VM) and bugs that > are classpath-libgcj bugs (i.e., specific to gcj), at least until > the two go from "mostly" merged to "completely" merged. Yes, the plan is to have a module/category 'libgcj' in the 'gcc' product that tracks bugs specific to libgcj runtime issues or classes that are still libgcj specific (there aren't that many actually). The bugs in the 'classpath' product should all be "generic bugs" not specific to any specific runtime or execution model. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
Mark Wielaard wrote: Hi Hackers, Assuming we don't get huge objections to the proposal to move all GNU Classpath bugs to a new gcc bugzilla product we should already start thinking about some details of the new setup. Here is my proposal. . . . Comments? Other suggestions? My understanding is that you want to integrate the libgcj and classpath bug databases with but still maintain the current situation with the actual code where there are separate code bases. How would a bug be marked that is fixed in libgcj and not fixed in classpath? It sounds a bit questionable to merge the bug tracking system before we have a single merged code base. Perhaps I am misunderstanding what you are recommending. David Daney ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
On Mon, 14 Feb 2005, Mark Wielaard wrote: > I will send a proposal for the module names, standard bug mailinglist > and version numbers to use for this new classpath product in the > database to the classpath and libgcj development mailinglists soon. The > current gcc modules AWT and SWING would also move to this new product. > Which should help with the issue that gcc bugzilla product currently has > a lot of modules already. I think we should continue to auto-cc gcc-bugs@gcc.gnu.org on all bug reports in the database, in addition to whatever extra lists are already used for Java bug reports or will be used for Classpath bugs. The merge of databases seems to make sense to me. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs) ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
On Mon, Feb 14, 2005 at 05:53:09PM +0100, Mark Wielaard wrote: > This is a request for comments on moving the GNU Classpath bug reports > (currently on savannah.gnu.org) into the gcc bugzilla database (as a > separate project). This will ease sharing information between the GNU > Classpath and GCC/GCJ hackers. I think it's a good idea; I'd like to see as much coordination between classpath and gcj development as possible. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Modules names and other details for new classpath bug product
On Mon, Feb 14, 2005 at 05:54:38PM +0100, Mark Wielaard wrote: > Hi Hackers, Proposal sounds like a good idea! > - Version numbers. > I don't have a very good suggestion here. Of course we should just > have the GNU Classpath version numbers there (0.13, 0.14, and up). But > those are not the same as used by GCC. There is no good/perfect > mapping between libgcj and classpath version numbers. That was my first question; if AWT/Swing bugs are reported for GCJ they 'should' be mapped to a classpath release, if possible. But I have no idea how to do that :) > - Actually moving the bugs. We have two tasks: > - Move the bugs currently filed under gcc/libgcj which are not runtime > specific to the correct classpath/category. This is not that hard, > but needs a volunteer to go over the 110 open bugs in that category. > (The AWT and SWING modules will probably be moved automatically) > - Move the bugs currently in the savannah bug tracker to > gcc.gnu.org/bugzilla. [...] I will move at least > the open ones by hand (currently 59 open bugs). My reported bugs will then nog be registred under my email? Should all classpath bug-reporters (that want to 'keep' their bugs) open an account on the gcc bugtracker? -- Thomas Zander pgpI2rB4HUBFL.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Merging GNU Classpath and gcc/libgcj bug databases
Mark Wielaard wrote: > Some background information. GNU Classpath core class library has been > mostly merged with libgcj for a couple of years now. The main technical > difference between them is that libgcj is tightly integrated with the Sounds good.. however.. Please make sure that there are two separate categories for bugs that are classpath bugs (i.e., independent of the VM) and bugs that are classpath-libgcj bugs (i.e., specific to gcj), at least until the two go from "mostly" merged to "completely" merged. Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com * Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. * ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Modules names and other details for new classpath bug product
Hi Hackers, Assuming we don't get huge objections to the proposal to move all GNU Classpath bugs to a new gcc bugzilla product we should already start thinking about some details of the new setup. Here is my proposal. - The product in gcc bugzilla will be called 'classpath'. - I will create a new mailinglist [EMAIL PROTECTED] that will receive all bugzilla activity/emails for the new 'classpath' product. - It seems a good idea to have modules for the main packages. But group them together a bit and not create a module for every (sub)package: accessibility, applet, awt, beans, crypto, imageio, io, lang, reflect, ref, math, naming, net, nio, print, rmi, security, sql, swing, text, transaction, util, jar, logging, prefs, regex, zip, xml. (Note that there is already a SWING and AWT module in gcc, these should be moved to the new classpath product.) Plus modules for the somewhat separate modules: inetlib, texidoclet, gjdoc, cp-tools, automakejar (Are all these necessary? Maybe just gjdoc and cp-tools?) - Version numbers. I don't have a very good suggestion here. Of course we should just have the GNU Classpath version numbers there (0.13, 0.14, and up). But those are not the same as used by GCC. There is no good/perfect mapping between libgcj and classpath version numbers. - Actually moving the bugs. We have two tasks: - Move the bugs currently filed under gcc/libgcj which are not runtime specific to the correct classpath/category. This is not that hard, but needs a volunteer to go over the 110 open bugs in that category. (The AWT and SWING modules will probably be moved automatically) - Move the bugs currently in the savannah bug tracker to gcc.gnu.org/bugzilla. This is harder since we will probably have to move them by hand. I have asked the savannah-hackers whether they can give us an exported database so we might be able to write a script for importing. If that isn't possible I will move at least the open ones by hand (currently 59 open bugs). Comments? Other suggestions? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Merging GNU Classpath and gcc/libgcj bug databases
Hi GCC and GNU Classpath and libgcj hackers, This is a request for comments on moving the GNU Classpath bug reports (currently on savannah.gnu.org) into the gcc bugzilla database (as a separate project). This will ease sharing information between the GNU Classpath and GCC/GCJ hackers. We have discussed the impact of this with Daniel Berlin and the rest of the GCC Bugmasters who don't see any technical or maintenance problems with this. It would solve an important problem for the GNU Classpath and gcj hackers who are now relying on two different bug databases without an easy way to move bugs between them. If there are no objections we would like to close down the savannah bug tracker for GNU Classpath and add a new "product" classpath in GCC bugzilla which contains all the current bug reports. This new 'classpath' product shall be used exclusively in the future for all core library bug reports in either GNU Classpath or libgcj as long as they are "generic" bugs. The libgcj component in the gcc bugzilla product would still be used for bugs in the runtime, as distinct from the class libraries (ie classpath), and for bugs in the few GCJ-specific classes that still exist. I will send a proposal for the module names, standard bug mailinglist and version numbers to use for this new classpath product in the database to the classpath and libgcj development mailinglists soon. The current gcc modules AWT and SWING would also move to this new product. Which should help with the issue that gcc bugzilla product currently has a lot of modules already. Some background information. GNU Classpath core class library has been mostly merged with libgcj for a couple of years now. The main technical difference between them is that libgcj is tightly integrated with the actual gcj/libffi/boehmgc runtime from GCC and GNU Classpath is explicitly kept "execution mechanism neutral". There are about 20 other runtimes and/or compilers based on GNU Classpath next to gcj. Although gcj is probably the most widely distributed one. And the "official GNU supported" one. The FSF sees libgcj and classpath as "merged". And paperwork for libgcj and GNU Classpath is handled in the same way (like the rest of GCC). GNU Classpath is hosted on http://www.gnu.org/software/classpath/ for the public webpages and uses savannah.gnu.org most developer resources (cvs, mailinglists). We have a separate development machine developer.classpath.org for dynamic content, scripts, and developer wikis, etc and http://planet.classpath.org/ for blog aggregation of the various GNU Classpath (and related project) hackers. GCC is mainly hosted on one machine gcc.gnu.org with their own cvs, wiki, mailinglists and bugzilla database separate from the savannah.gnu.org bugtracker. GNU Classpath is maturing and provides a serious free alternative to the proprietary core libraries for the java programming language. And gcj has been made a solid member of the GNU Compiler Collective that is actively being used by more and more people. We are now getting bugreports through different channels. Having multiple bug databases against which users report bugs is causing serious problems since monitoring the different bug databases and moving bugs between them is not trivial. The upcomming GCC 4.0 will have a gcj mature enough to support large free software projects written in the java programming language like Eclipse, lots of the Apache projects and java-gnome applications. So we are expecting a lot of new bug reports for classpath to be reported through the gcc bugdatase. So sharing the bug database architecture/backend with the GCC project makes a lot of sense. By having it as a separate project we hope to also facilitate the other free compilers and runtimes based on GNU Classpath. Cheers, Mark Wielaard GNU Classpath Maintainer signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Preparing for GNU Classpath meeting at Fosdem
Hi all, I created a new wiki page describing all currently know information about our hacker meeting during Fosdem 2005 (Sat/Sun 26/27 February, Brussels, Belgium) http://developer.classpath.org/mediation/Fosdem2005 Please check it out. Add your name if you are comming (there is an Edit Text link at the bottom) and/or add some suggestions for the Technical Session discussion topics. The current schedule of speakers with some talk abstracts can be found at http://www.fosdem.org/2005/index/dev_room_classpath/schedule More to come! Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
