F7 plan (gcj/java/eclipse/swt/java-gnome/fop/batik/etc)

[Mark Wielaard]

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

[Tom Tromey]

> >>>> "Mark" == Mark Wielaard
> <mark(a)klomp.org&gt; 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

[Mark Wielaard]

Hi Tom,

On Fri, 2006-12-29 at 13:09 -0700, Tom Tromey wrote:
>  >>>>> "Mark" == Mark Wielaard
> <mark(a)klomp.org&gt; 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

[Tom Tromey]

> >>>> "Mark" == Mark Wielaard
> <mark(a)klomp.org&gt; 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

[Francis Kung]

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

[Mark Wielaard]

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

[Tommy Reynolds]

Uttered Mark Wielaard <mark(a)klomp.org&gt;, 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

[Mark Wielaard]

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

[Tommy Reynolds]

Uttered Mark Wielaard <mark(a)klomp.org&gt;, 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

[Karsten Wade]

>  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
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Anthony Green]

On Tue, 2007-01-02 at 10:36 -0500, Francis Kung wrote:
>  Batik is working much better on Classpath now. 
Are you planning on packaging this for Fedora Extras?  That would be
great.

AG

[Andrew Overholt]

Hi,

* Mark Wielaard <mark(a)klomp.org&gt; [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

[Andrew Haley]

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.

[Gary Benson]

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