Hi,
I saw the following thread about F7 plans and noticed we don't have any goals for gcj/eclipse/swt/java-gnome/etc http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/1551
So here are some ideas, deadlines and dependencies that might be nice to look at for F7 for the various stacks that make up the fedora-devel-java world. Please reply if you are working on any of this, if I am saying something silly/wrong or if there are more stack/application issues that you think are important for F7.
The "important dates" are:
- January 23 - Test1 Development Freeze - February 20 - Test2 Development Freeze - March 15 - Test3 Development Freeze - Release in April
Test2 is just before Fosdem. And since all features should be in by then, it would be nice to try and create a liveCD with all "our features" on it to show off at Fosdem (Feb 24/25, Brussel, Belgium).
- 1.5 language & library support in gcj This seems to be the biggest and most intrusive upgrade. But starting this early seems like a very good idea. Upstream is cleaning up some last issues. And it needs lots of testing. Would be good if something can be cooked up for Test1. Needs help from gcc-toolchain people.
- Separate libgcj-rpm. Would be really nice so we can update the core class libraries separate from the core gcc compilers. Should also help with updates/dependencies since libgcj provides the mozilla plugin now and the awt libraries depend on gtk+. Would be nice if this can be done before Test2 so we can test an upgrade. Again needs help from gcc-toolchain people.
- java-gcj-compat The biggest issue with this, if the 1.5-stack goes through is that gjdoc isn't 1.5 safe. If we cannot easily update gjdoc, then maybe sinjdoc could be investigated as replacement. http://www.cag.lcs.mit.edu/~cananian/Projects/GJ/#sinjdoc (Do we also need updates for javap and javah replacements?)
- eclipse/swt/rcp stack 3.2 seems already good to go, and 3.3 will not come out till the middle of 2007. Azureus, RSSOwl also already seem updated. Andrew Overholt already has written down some plans for the future: http://overholt.ca/wp/?p=76 Maybe some work can be done to support the JDWP work in libgcj to get a little debugging going? And it would be nice to make sure that the ecj from eclipse and that from the gcj 1.5-stack match up.
- java-gnome There are some rumors about a upgrade/rewrite, but nothing concrete as far as I have seen. If there is a rewrite that might cause some extra work for applications like Frysk.
- gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something.
- jpackage. Does it make sense to upgrade all packages to jpp 1.7 if the 1.5-stack goes in?
- OpenOffice 2.2 Listed here since it does have some parts written in java. 2.2 comes out end of February. Probably needs retesting with the gcj-stack. I don't know if there are new java language/library dependencies.
Some things that would be nice, but that are probably a lot of work, maybe better left for Fedora *, unless someone volunteers of course! :)
- OpenJDK Still lots missing. Hopefully at Fosdem we will learn a bit more about the encumberments and when which parts of the core libraries will be liberated fully. But it might be nice to see if javac could be packaged. Or maybe a brave soul make hotspot work with classpath?
- PhoneME/CACAO/MIDPath/J2MEPolish The Micro Edition world seems to really have gotten a boost from the GPL release of PhoneME. A lot of this is pretty early access. But it would be nice to have parts of this supported to show that Fedora is also a nice platform to developer for java-based mobile devices.
- JBoss application server, SEAM stack Not tried yet. Parts like tomcat are already packaged. If we can get the 1.5-stack going it makes sense to look at this a bit closer. Maybe other parts can be lifted from jpackage?
- Netbeans I tried this recently, but it seems still very tight to the Sun java implementation and I was unable to fully start it up on the free stack. But some dependencies like JavaHelp have been liberated (gpl+exception) now (and entered jpackage recently). Also it isn't clear whether the current license (CDDL) is acceptable (it seems unacceptable to Debian).
- JOGL and WW2D should work, but I haven't done any testing recently.
- japitools should really be packaged and somehow be tied in with the build system so developers/packagers can get an easy overview of whether or not a library upgrade is binary compatible or not.
I am sure there is a lot missing. And as you saw none of the items above have real deadlines or people responsible, etc. So please feel free to reply with corrections add those yourself :)
Cheers,
Mark
"Mark" == Mark Wielaard mark@klomp.org writes:
Mark> - January 23 - Test1 Development Freeze
Ok...
Mark> - 1.5 language & library support in gcj Mark> This seems to be the biggest and most intrusive upgrade. But starting Mark> this early seems like a very good idea. Upstream is cleaning up some Mark> last issues. And it needs lots of testing. Would be good if something Mark> can be cooked up for Test1. Needs help from gcc-toolchain people.
Yeah... do we know what base compiler is being used for FC7? We'll probably have to back-port all the 1.5 stuff to that. Kinda tough before the 23rd considering that we haven't merged it all to GCC mainline yet :(
Mark> - Separate libgcj-rpm.
This is suspended pending the core/extras merge.
Mark> - java-gcj-compat Mark> (Do we also need updates for javap and javah replacements?)
We don't have javap at all, do we? But we do have jcf-dump, which has not changed during all the 1.5 work.
The new javah that is in Classpath will show up when we merge the gcj-eclipse branch to trunk.
Mark> Maybe some work can be done to support the JDWP work in libgcj to Mark> get a little debugging going?
Whatever is on the branch, we'll ship. I don't know what will work or not before the release, we'll have to ask Keith.
Mark> - OpenJDK Mark> Still lots missing. Hopefully at Fosdem we will learn a bit more about Mark> the encumberments and when which parts of the core libraries will be Mark> liberated fully. But it might be nice to see if javac could be Mark> packaged.
javac builds fine against classpath (as you know). I'm not sure if all the needed bits are in libgcj yet, but this is simple to fix if not.
Tom
Hi Tom,
On Fri, 2006-12-29 at 13:09 -0700, Tom Tromey wrote:
"Mark" == Mark Wielaard mark@klomp.org writes:
Mark> - January 23 - Test1 Development Freeze
Ok...
Mark> - 1.5 language & library support in gcj Mark> This seems to be the biggest and most intrusive upgrade. But starting Mark> this early seems like a very good idea. Upstream is cleaning up some Mark> last issues. And it needs lots of testing. Would be good if something Mark> can be cooked up for Test1. Needs help from gcc-toolchain people.
Yeah... do we know what base compiler is being used for FC7? We'll probably have to back-port all the 1.5 stuff to that. Kinda tough before the 23rd considering that we haven't merged it all to GCC mainline yet :(
I have CCed Jakub. If there is a fedora branch in gcc svn then maybe porting/patching can be done at the same time as it lands on mainline?
Mark> - Separate libgcj-rpm.
This is suspended pending the core/extras merge.
O, that is a pity. Any idea what/how long that will take?
Mark> - java-gcj-compat Mark> (Do we also need updates for javap and javah replacements?)
We don't have javap at all, do we? But we do have jcf-dump, which has not changed during all the 1.5 work.
You are right. Strange, since jcf-dump has a --javap mode I assumed it would be the natural wrapper for java-gcj-compat to provide javap.
The new javah that is in Classpath will show up when we merge the gcj-eclipse branch to trunk.
Will this replace gcjh?
Cheers,
Mark
"Mark" == Mark Wielaard mark@klomp.org writes:
We don't have javap at all, do we? But we do have jcf-dump, which has not changed during all the 1.5 work.
Mark> You are right. Strange, since jcf-dump has a --javap mode I assumed it Mark> would be the natural wrapper for java-gcj-compat to provide javap.
Note that --javap mode is hardly ever used, afaik. I don't recall ever using it myself, nor do I recall ever seeing a bug report mentioning it.
The new javah that is in Classpath will show up when we merge the gcj-eclipse branch to trunk.
Mark> Will this replace gcjh?
Yes. gcjh has been deleted from the branch.
Tom
- gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something.
Batik is working much better on Classpath now. I don't know what areas of Batik are used by DocBook, however, so I don't know how well we do in this regard.
I've been working mostly off of the standard sample files that come with Batik, but I can concentrate on this if we know what areas are needed. I haven't heard of any other progress on the FOP/DocBook front.
Cheers, Francis
On Tue, 2007-01-02 at 10:36 -0500, Francis Kung wrote:
- gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something.
Batik is working much better on Classpath now. I don't know what areas of Batik are used by DocBook, however, so I don't know how well we do in this regard.
I've been working mostly off of the standard sample files that come with Batik, but I can concentrate on this if we know what areas are needed. I haven't heard of any other progress on the FOP/DocBook front.
Karsten (CCed) Do you have a link or description of how the gcj-compiled DocBook toolchain should work to be useful for the doc-team?
We are working on a feature list for Fedora 7 and this is one of the things that seems good to take a look at early if the doc-team wants it. See http://thread.gmane.org/gmane.linux.redhat.fedora.java/1997
Thanks,
Mark
Uttered Mark Wielaard mark@klomp.org, spake thus:
On Tue, 2007-01-02 at 10:36 -0500, Francis Kung wrote:
- gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something.
Batik is working much better on Classpath now. I don't know what areas of Batik are used by DocBook, however, so I don't know how well we do in this regard. I've been working mostly off of the standard sample files that come with Batik, but I can concentrate on this if we know what areas are needed. I haven't heard of any other progress on the FOP/DocBook front.
Karsten (CCed) Do you have a link or description of how the gcj-compiled DocBook toolchain should work to be useful for the doc-team?
Mark,
I've been a major contributor to the FDP/DocBook, mostly in the tools area. I've developed some XMLTO patches that will let us use FOP et. al. and ASUI, Tim Waugh -- the XMLTO maintainer -- is hanging fire waiting for there to actually be a native FOP package.
I'm not sure what you're asking for here, so I'll shotgun a bunch of points in the hope one will be near the mark.
As far as batik is concerned, we would mostly be using it via FOP; batik would not absolutely need to be packaged separately, but it would be nice to use standalone. If I were assigning the priority, I'd want batik-like function via the FOP interface rather than standalone batik.
The preferred rendering would be to PNG objects first, with a JPG alternative a middling second. No GIF, TIF and all the rest needed.
I'm sure Karsten and Paul W Frields will weigh in later, but this should be close.
Cheers, HTH
Hi,
On Tue, 2007-01-02 at 19:00 -0800, Tommy Reynolds wrote:
I've been a major contributor to the FDP/DocBook, mostly in the tools area. I've developed some XMLTO patches that will let us use FOP et. al. and ASUI, Tim Waugh -- the XMLTO maintainer -- is hanging fire waiting for there to actually be a native FOP package.
Great. Lets see what we can get together for F7.
I'm not sure what you're asking for here, so I'll shotgun a bunch of points in the hope one will be near the mark.
As far as batik is concerned, we would mostly be using it via FOP; batik would not absolutely need to be packaged separately, but it would be nice to use standalone. If I were assigning the priority, I'd want batik-like function via the FOP interface rather than standalone batik.
The preferred rendering would be to PNG objects first, with a JPG alternative a middling second. No GIF, TIF and all the rest needed.
Yes, these priorities are useful. Since we are mostly compiler, runtime, library hackers, and don't actually know much about the processes of the doc-team, could you describe the "workflow" you would do? If you could describe/show some sample input files, the stylesheets you would use, the commands you would use to transform them and how you would expect the rendered output files to look like that would be very helpful.
Thanks,
Mark
Uttered Mark Wielaard mark@klomp.org, spake thus:
Since we are mostly compiler, runtime, library hackers, and don't actually know much about the processes of the doc-team, could you describe the "workflow" you would do? If you could describe/show some sample input files, the stylesheets you would use, the commands you would use to transform them and how you would expect the rendered output files to look like that would be very helpful.
You can find all our tools, stylesheets and such in our Documentation Guide on the web at:
http://fedora.redhat.com/docs/documentation-guide/sn-cvs-config.html
Setup the anonymous CVS as shown, and then check out two modules:
o docs-commond o example-tutorial
In the "example-tutorial/" directory, do this heap big magic:
$ make pdf
All will be revealed.
The pithy part is that we will expect an executable named "fop" somewhere on the path, where xmlto(1) can find it, because somewhere in all that make(1)'ing, we generate a:
xmlto pdf example-tutorial.xml
(in essence, if not in fact).
Now, the stock xmlto(1) doesn't use FOP, it relies on the "passivetex" project which appears to be not only broken, but defunct.
I've got a patched version of xmlto(1) here:
http://www.megacoder.com/files/xmlto/xmlto-0.0.18-7.src.rpm http://www.megacoder.com/files/xmlto/xmlto-0.0.18-7.i386.rpm
so you can install that and try it out for real. It won't install unless you --force it to believe there actually is a FOP package.
I won't be around until this evening, but you can catch me then.
Cheers
Yes, these priorities are useful. Since we are mostly compiler, runtime, library hackers, and don't actually know much about the processes of the doc-team, could you describe the "workflow" you would do? If you could describe/show some sample input files, the stylesheets you would use, the commands you would use to transform them and how you would expect the rendered output files to look like that would be very helpful.
Mark:
Sorry I've not been watching this thread as carefully on f-devel-java-l. When you are ready for some testing from our toolchain, please post to fedora-docs-list.
thx - Karsten
Hi,
* Mark Wielaard mark@klomp.org [2006-12-29 14:42]:
- 1.5 language & library support in gcj
This would allow us to have Mylar which is something I'd like to see. It'll also allow us to build the Eclipse SDK with the 1.5 bits (apt, junit4) enabled.
- eclipse/swt/rcp stack 3.2 seems already good to go, and 3.3 will not come out till the middle of 2007. Azureus, RSSOwl also already seem updated.
Yeah, we're staying with 3.2.x for F7. Ben and I will be making 3.3 M-build RPMs available outside of Fedora for testing purposes.
Maybe some work can be done to support the JDWP work in libgcj to get a little debugging going? And it would be nice to make sure that the ecj from eclipse and that from the gcj 1.5-stack match up.
Yes! Although I don't think work can be done on the Eclipse side. It should Just Work like the proprietary JVMs do. I think we're pretty close to this. Keith?
- Eclipse stuff Here, we're planning on: . trying to get most of the autotools work finished. This means the underlying building stuff (which is mostly done at this point), an autoconf editor, an automake editor, the ability to invoke the individual tools independently, etc. I'd also like to investigate a linked, form-based editor like the attached but I don't think I'll personally have time . packaging the language packs. Kyu's almost finished with a tool to automate this. . seeing if we can include the RPM plugins. I'd especially like to see the specfile editor. This sort of depends upon it getting moved at eclipse.org. That's underway. . getting a new version of PyDev ready . finishing up a specfile stubber that I've started on. This will ease the packaging of features and will hopefully encourage more packaging contributors
I can't think of anything else at the moment. It'd be great to get all of these plans up on the Fedora wiki somewhere.
Andrew
Mark Wielaard writes:
I saw the following thread about F7 plans and noticed we don't have any goals for gcj/eclipse/swt/java-gnome/etc http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/1551
So here are some ideas, deadlines and dependencies that might be nice to look at for F7 for the various stacks that make up the fedora-devel-java world. Please reply if you are working on any of this, if I am saying something silly/wrong or if there are more stack/application issues that you think are important for F7.
The "important dates" are:
- January 23 - Test1 Development Freeze
- February 20 - Test2 Development Freeze
- March 15 - Test3 Development Freeze
- Release in April
Test2 is just before Fosdem. And since all features should be in by then, it would be nice to try and create a liveCD with all "our features" on it to show off at Fosdem (Feb 24/25, Brussel, Belgium).
- 1.5 language & library support in gcj This seems to be the biggest and most intrusive upgrade. But starting this early seems like a very good idea. Upstream is cleaning up some last issues. And it needs lots of testing. Would be good if something can be cooked up for Test1. Needs help from gcc-toolchain people.
Tom Tromey and I will merge the gcj 1.5 branch to gcc trunk upstream. Then, we'll work with Jakub Jelinek to get the result into the F7 RPM.
This must happen soon. Hopefully the gcj trunk merge will be complete this week, and we can move on to the F7 RPM next week.
- Separate libgcj-rpm. Would be really nice so we can update the core class libraries separate from the core gcc compilers. Should also help with updates/dependencies since libgcj provides the mozilla plugin now and the awt libraries depend on gtk+. Would be nice if this can be done before Test2 so we can test an upgrade. Again needs help from gcc-toolchain people.
According to Jesse Keating, we should aim to have this ready by February 27, the test2 date. Tom Tromey has already done a separate libgcj RPM for an earlier version, so we should be good to go.
- java-gcj-compat The biggest issue with this, if the 1.5-stack goes through is that gjdoc isn't 1.5 safe. If we cannot easily update gjdoc, then maybe sinjdoc could be investigated as replacement. http://www.cag.lcs.mit.edu/~cananian/Projects/GJ/#sinjdoc (Do we also need updates for javap and javah replacements?)
Tom Fitzsimmons has volunteered to investigate this. However, he can't do much until we've got Item 1, 1.5 language & library support in gcj, done.
- eclipse/swt/rcp stack 3.2 seems already good to go, and 3.3 will not come out till the middle of 2007. Azureus, RSSOwl also already seem updated. Andrew Overholt already has written down some plans for the future: http://overholt.ca/wp/?p=76 Maybe some work can be done to support the JDWP work in libgcj to get a little debugging going? And it would be nice to make sure that the ecj from eclipse and that from the gcj 1.5-stack match up.
The 1.5 gcj branch needs ecj, and ecj is part of Eclipse. There are some tricky dependencies between Eclipse and some other packages, and we should work to have a separate ecj RPM. Andrew Overholt will investigate getting a separate ecj RPM that does not depend on Eclipse into F7.
java-gnome There are some rumors about a upgrade/rewrite, but nothing concrete as far as I have seen. If there is a rewrite that might cause some extra work for applications like Frysk.
gcj-compiled DocBook toolchain It seems we have made lots of progress with FOP and Batik since the last discussion about this: http://thread.gmane.org/gmane.linux.redhat.fedora.documentation/4582 Does anybody know where we are with that at this time? Would be nice to coordinate with the fedora-docs-list if we can provide something.
jpackage. Does it make sense to upgrade all packages to jpp 1.7 if the 1.5-stack goes in?
OpenOffice 2.2 Listed here since it does have some parts written in java. 2.2 comes out end of February. Probably needs retesting with the gcj-stack. I don't know if there are new java language/library dependencies.
This probably won't make it.
Some things that would be nice, but that are probably a lot of work, maybe better left for Fedora *, unless someone volunteers of course! :)
- OpenJDK Still lots missing. Hopefully at Fosdem we will learn a bit more about the encumberments and when which parts of the core libraries will be liberated fully. But it might be nice to see if javac could be packaged. Or maybe a brave soul make hotspot work with classpath?
Before F7 cutoff? I doubt it. :-)
- JBoss application server, SEAM stack Not tried yet. Parts like tomcat are already packaged. If we can get the 1.5-stack going it makes sense to look at this a bit closer. Maybe other parts can be lifted from jpackage?
I'll have a look at JBoss, but it has a lot of dependencies.
Andrew.
Andrew Haley wrote:
Mark Wielaard writes:
- 1.5 language & library support in gcj This seems to be the biggest and most intrusive upgrade. But starting this early seems like a very good idea. Upstream is cleaning up some last issues. And it needs lots of testing. Would be good if something can be cooked up for Test1. Needs help from gcc-toolchain people.
Tom Tromey and I will merge the gcj 1.5 branch to gcc trunk upstream. Then, we'll work with Jakub Jelinek to get the result into the F7 RPM.
Is there anything I can do to help with this?
Cheers, Gary
java-devel@lists.fedoraproject.org