12:26 p.m.
There are a couple of big problems with our javadoc situation right now:
- We don't install javadoc for the core classes.
- There are no links between javadoc packages.
If would be nice to fix this for FC5.
Here are my suggested actions:
1. If we aren't going to modify the gcc spec file to generate libgcj
javadoc, then we should use something like this package, which builds
core javadoc from the libgcj-src RPM...
http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm
2. Modify all our spec files to include links between packages.
3. All the javadoc gets installed in directories
under /usr/share/javadoc. It would be nice if there were a top level
index.html to tie them all together. We could add a %post(un) script to
maintain this file.
4. The Eclipse help system should refer to this top level index.html, so
it shows up along with the other Eclipse docs. Maybe it could also go
on the main Gnome menu under Applications/Programming.
Any other ideas? It all starts with [1], which we've discussed before
but I'm afraid we're kind of stalled on.
AG
1:15 p.m.
On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote:
1. If we aren't going to modify the gcc spec file to generate
libgcj
javadoc, then we should use something like this package, which builds
core javadoc from the libgcj-src RPM...
http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm
I've updated this srpm. http://spindazzle.org/FC/devel
It would be much better to generate the javadoc from within the gcc spec
file, but my understanding is that this can't happen until gjdoc is
imported into GCC.
2. Modify all our spec files to include links between packages.
It looks like gjdoc's link facility is broken (or unimplemented). I'll
file a bug report.
AG
4:07 a.m.
Anthony Green wrote:
On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote:
> 1. If we aren't going to modify the gcc spec file to generate
> libgcj javadoc, then we should use something like this package,
> which builds core javadoc from the libgcj-src RPM...
> http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm
I've updated this srpm. http://spindazzle.org/FC/devel
It would be much better to generate the javadoc from within the
gcc spec file, but my understanding is that this can't happen
until gjdoc is imported into GCC.
Why not?
4:38 p.m.
On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote:
Anthony Green wrote:
> On Sun, 2005-09-11 at 10:26 -0700, Anthony Green wrote:
> > 1. If we aren't going to modify the gcc spec file to generate
> > libgcj javadoc, then we should use something like this package,
> > which builds core javadoc from the libgcj-src RPM...
> > http://people.redhat.com/green/libgcj-docs-4.0.0-1.src.rpm
>
> I've updated this srpm. http://spindazzle.org/FC/devel
>
> It would be much better to generate the javadoc from within the
> gcc spec file, but my understanding is that this can't happen
> until gjdoc is imported into GCC.
Why not?
Because we don't want to introduce another bootstrapping problem; gjdoc
BuildRequires gcj, gcj would BuildRequires gjdoc.
Tom
--
fedora-devel-java-list mailing list
fedora-devel-java-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
3:42 a.m.
Thomas Fitzsimmons wrote:
On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote:
> Anthony Green wrote:
> > It would be much better to generate the javadoc from within the
> > gcc spec file, but my understanding is that this can't happen
> > until gjdoc is imported into GCC.
>
> Why not?
Because we don't want to introduce another bootstrapping problem;
gjdoc BuildRequires gcj, gcj would BuildRequires gjdoc.
Why is that a problem? Everything that gcc BuildRequires also
BuildRequires gcc.
Cheers,
Gary
4:44 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary Benson wrote:
Why is that a problem? Everything that gcc BuildRequires also
BuildRequires gcc.
Personally, I would create two packages in this scenario: %{name} (with
javadocs enabled) and %{name}-bootstrap (without javadocs).
The idea is to not have cyclic dependencies. These are a nightmare when
building packages from scratch. A lot of times I see in your packages
``bootstrapped into fedora''. Well, this is nice for most people I
guess, but I don't consider it very free since you likely bootstrapped
off of a package built with Sun javac and now no one else can reproduce
it without much work. Granted, not many people would want to reproduce
it except me anyway, but in principle it's not very workable. Finally,
this isn't as bad as having prebuilt binary jar dependencies, and your
example about gcc is valid though I am not sure how it is avoidable.
As a related side-note: jonas is sitting in FC4 now, yet *many* packages
it requires are not even built for fedora---just Sun built and dropped
into the source tarball. At least here I would hope the non-existent
packages are filed in buzilla or someone's TODO list. As another side
note, I have made a package of jss which is a binary jar currently used
by ldapjdk, and I hope to push this out eventually. I believe xalan-j2
also has prebuilt jars in the build (I wish there was a list of these
packages somewhere).
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDKUKKarJDwJ6gwowRAl1jAJ9tRaLI4tIw06Vev2GwSUaBbPIhRgCglsNO
FqWUJg/XAtzZLlhA5aSn0k8=
=cZXT
-----END PGP SIGNATURE-----
7:37 a.m.
David Walluck wrote:
Gary Benson wrote:
> Why is that a problem? Everything that gcc BuildRequires also
> BuildRequires gcc.
Personally, I would create two packages in this scenario: %{name}
(with javadocs enabled) and %{name}-bootstrap (without javadocs).
The idea is to not have cyclic dependencies. These are a nightmare
when building packages from scratch. A lot of times I see in your
packages ``bootstrapped into fedora''. Well, this is nice for most
people I guess, but I don't consider it very free since you likely
bootstrapped off of a package built with Sun javac and now no one
else can reproduce it without much work. Granted, not many people
would want to reproduce it except me anyway, but in principle it's
not very workable. Finally, this isn't as bad as having prebuilt
binary jar dependencies, and your example about gcc is valid though
I am not sure how it is avoidable.
Circular dependencies cannot be avoided for Fedora as a whole because
there are packages which depend upon themselves -- the kernel, gcc,
rpm, etc. This doesn't make any of those packages not free.
Fedora's build system can of course cope with such dependency loops so
when they're non-trivial to remove I've always been happy for them to
remain.
Besides, the full set of gcc rpms is 100-120Mb _per_arch_, with
another 30Mb of sources. It's inconceivable that releng would allow
what is essentially a duplicate of something that large whatever I
or anyone else in the Java group decide.
As a related side-note: jonas is sitting in FC4 now, yet *many*
packages it requires are not even built for fedora---just Sun built
and dropped into the source tarball. At least here I would hope the
non-existent packages are filed in buzilla or someone's TODO
list.
There's only a couple left in the Fedora JOnAS, but these require
Maven and its 60-70 dependencies that are not yet in Fedora. I'm
swamped with the 80-90 packages I already maintain! I should be
getting help Real Soon Now, but until that happens we'll be stuck
with the binary dependencies (and old package versions, and the
other stuff I don't have time to fix).
As another side note, I have made a package of jss which is a
binary jar currently used by ldapjdk, and I hope to push this
out eventually.
Cool.
I believe xalan-j2 also has prebuilt jars in the build
It does.
(I wish there was a list of these packages somewhere).
Any Fedora package whose source rpm contains a file that matches
'*RHsemiCLEAN*' is one.
Cheers,
Gary
6:32 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary Benson wrote:
Circular dependencies cannot be avoided for Fedora as a whole
because
there are packages which depend upon themselves -- the kernel, gcc,
rpm, etc. This doesn't make any of those packages not free.
I agree with everything here. While gcc, the kernel, etc. may be special
cases, we may try to avoid circular dependencies with java packages at
least. It is not that hard. Most bootstrap packages exist in jpackage
already (and hopefully they don't use binary jars). Then a few packages
like java-gcj-compat and ant will need to be bootstraped. The biggest
problem is the lack of javadoc creation. If javadoc could be part of the
core, then a lot of bootstrap issues would go away.
Finally, by non-free I am referring to pre-built binary jars,
tecnhnically, only ones built with the Sun jdk (though this is only a
philosophical issue). Assuming they were built with ecj + libgcj, all
the practical issues would still apply.
There's only a couple left in the Fedora JOnAS, but these
require
Maven and its 60-70 dependencies that are not yet in Fedora. I'm
swamped with the 80-90 packages I already maintain! I should be
getting help Real Soon Now, but until that happens we'll be stuck
with the binary dependencies (and old package versions, and the
other stuff I don't have time to fix).
All, the more reason for jpackage and FC not to diverge. As we know,
someone from Red Hat has been working on a free maven, so maybe the
update to jonas can eventually happen.
>I believe xalan-j2 also has prebuilt jars in the build
It does.
I don't believe they are required to build if you just avoid building
the docs (which requrie stylebook, I think). Actually, last time I tried
to build xalan at all on a free stack it failed, so I will have to look
at this again.
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDKgSNarJDwJ6gwowRAhdDAKCc1hXsOu9Bel8WXqp7v8u2MVmkZwCdF0xr
2ivK6YY8+6pZrAOLoUFcWzw=
=QHK1
-----END PGP SIGNATURE-----
4:20 a.m.
David Walluck wrote:
Gary Benson wrote:
> Circular dependencies cannot be avoided for Fedora as a whole
> because there are packages which depend upon themselves -- the
> kernel, gcc, rpm, etc. This doesn't make any of those packages
> not free.
I agree with everything here. While gcc, the kernel, etc. may be
special cases, we may try to avoid circular dependencies with java
packages at least. It is not that hard. Most bootstrap packages
exist in jpackage already (and hopefully they don't use binary
jars).
I agree it's not that hard, but it is also not without price.
Fedora's bootstrapping was a one-off, and can be forgotten about now
it's done. Bootstrap packages, on the other hand, must maintained.
This means they must be updated and tested for every new release.
They must be shipped, over the network and on CDs. Finally they must
be monitored for security vulnerabilities for as long as they exist in
a Red Hat supported product. Any package (bootstrap or otherwise) I
introduce into Fedora that ends up in the next version of RHEL will
have to be monitored until 2013!
If you want to bootstrap Fedora yourself can you not simply use the
JPackage ant-bootstrap to get it all going?
> There's only a couple left in the Fedora JOnAS, but these
require
> Maven and its 60-70 dependencies that are not yet in Fedora. I'm
> swamped with the 80-90 packages I already maintain! I should be
> getting help Real Soon Now, but until that happens we'll be stuck
> with the binary dependencies (and old package versions, and the
> other stuff I don't have time to fix).
All, the more reason for jpackage and FC not to diverge. As we know,
someone from Red Hat has been working on a free maven, so maybe the
update to jonas can eventually happen.
It _will_ happen, don't worry about that :)
> > I believe xalan-j2 also has prebuilt jars in the build
>
> It does.
I don't believe they are required to build if you just avoid
building the docs (which requrie stylebook, I think). Actually,
last time I tried to build xalan at all on a free stack it failed,
so I will have to look at this again.
xalan-j2 was unbuildable in Fedora for a very long time but it should
be fixed now.
Cheers,
Gary
4:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary Benson wrote:
xalan-j2 was unbuildable in Fedora for a very long time but it
should
be fixed now.
Do you have more specifics on what the bugs were and where they were
fixed? I am using a custom setup here (say, a different version of gcc,
or whatever) so I can't be guaranteed to have the fixes, nor do I know
where or how to track these fixes when they occurred.
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDKpBnarJDwJ6gwowRAoQpAJ4u85L0rBKYKhW1a5OTXVt0Lb0pcgCePybm
kxyLaWyM5M3Tyu8ljBVFBkg=
=6AxP
-----END PGP SIGNATURE-----
4:40 a.m.
David Walluck wrote:
Gary Benson wrote:
> xalan-j2 was unbuildable in Fedora for a very long time but it
> should be fixed now.
Do you have more specifics on what the bugs were and where they were
fixed? I am using a custom setup here (say, a different version of
gcc, or whatever) so I can't be guaranteed to have the fixes, nor do
I know where or how to track these fixes when they occurred.
The visible face of the problem is that it uses libgcj's xml classes
rather than those in xml-commons-apis. libgcj's are newer and contain
more interface definitions, so I needed to add stubs in xalan-j2.
These are in xalan-j2-bz152255.patch in Fedora xalan-j2.
The core of the problem is that there is a bunch of packages which
builds using xml-commons-apis, but when you use libgcj only a small
minority actually see xml-commons-apis whereas the rest see libgcj's
XML classes. I have no idea why.
Cheers,
Gary
4:45 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gary Benson wrote:
The core of the problem is that there is a bunch of packages which
builds using xml-commons-apis, but when you use libgcj only a small
minority actually see xml-commons-apis whereas the rest see libgcj's
XML classes. I have no idea why.
The only thing I can think of is classpath ordering (depends on how the
classpath is defined in build.xml). To override internal classes I
thought (for Sun at least) you needed to use -bootclasspath, but this
doesn't seem always to be the case either.
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDKpQoarJDwJ6gwowRAtgVAJ9xlbO3U/QkahgFXzzvZ0NPXPet3QCgpvrx
rl5+eBay3TQEz79FB4gq8BQ=
=ii8d
-----END PGP SIGNATURE-----
9:19 a.m.
On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote:
The core of the problem is that there is a bunch of packages which
builds using xml-commons-apis, but when you use libgcj only a small
minority actually see xml-commons-apis whereas the rest see libgcj's
XML classes. I have no idea why.
I think it's a bug in the Eclipse compiler.
https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg001...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617
AG
9:28 a.m.
Anthony Green wrote:
On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote:
> The core of the problem is that there is a bunch of packages which
> builds using xml-commons-apis, but when you use libgcj only a
> small minority actually see xml-commons-apis whereas the rest see
> libgcj's XML classes. I have no idea why.
I think it's a bug in the Eclipse compiler.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617
Oh, cool. I copied myself on that, and I'll see if if fixes it when
it's fixed.
Cheers,
Gary
9:37 a.m.
On Fri, 2005-09-16 at 15:28 +0100, Gary Benson wrote:
Oh, cool. I copied myself on that, and I'll see if if fixes it
when
it's fixed.
That patch in my email definitely fixes the problem. But I think there
are other hidden problems in Eclipse's classpath ordering that fitzsim
wanted to fix. I forget what the current status of this bug is.
AG
9:41 a.m.
(CCing overholt)
On Fri, 2005-09-16 at 07:19 -0700, Anthony Green wrote:
On Fri, 2005-09-16 at 10:40 +0100, Gary Benson wrote:
> The core of the problem is that there is a bunch of packages which
> builds using xml-commons-apis, but when you use libgcj only a small
> minority actually see xml-commons-apis whereas the rest see libgcj's
> XML classes. I have no idea why.
I think it's a bug in the Eclipse compiler.
https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg001...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617
Andrew, can you add this patch to the next eclipse-ecj build?
Thanks,
Tom
9:48 a.m.
* Thomas Fitzsimmons <fitzsim(a)redhat.com> [2005-09-16 10:45]:
>
> I think it's a bug in the Eclipse compiler.
>
> https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg001...
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617
Andrew, can you add this patch to the next eclipse-ecj build?
Of course. I can't build eclipse ATM, though, until Bryce's patch for
gcc #23891 gets into a rawhide gcc. We should also discuss this with the
JDT core guys.
Andrew
9:54 a.m.
On Fri, 2005-09-16 at 10:48 -0400, Andrew Overholt wrote:
* Thomas Fitzsimmons <fitzsim(a)redhat.com> [2005-09-16 10:45]:
> >
> > I think it's a bug in the Eclipse compiler.
> >
> >
https://www.redhat.com/archives/fedora-devel-java-list/2005-August/msg001...
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166617
>
> Andrew, can you add this patch to the next eclipse-ecj build?
Of course. I can't build eclipse ATM, though, until Bryce's patch for
gcc #23891 gets into a rawhide gcc. We should also discuss this with the
JDT core guys.
Not yet; we're not sure how it's supposed to work yet. After I
formalize my tests we can start talking about this upstream.
Tom
1:52 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Overholt wrote:
Of course. I can't build eclipse ATM, though, until Bryce's
patch for
gcc #23891 gets into a rawhide gcc. We should also discuss this with the
JDT core guys.
I fell victim to this bug too. There are two workarounds right now that
I found.
The first is that ecj.jar doesn't really need to be built in eclipse
since the same exact version is already built in the standalone ecj rpm
(of course this required gcc at one point). One might wonder why
compilation is being done a second time instead of using BuildRequires:
eclipse-ecj (not circular if ecj provides eclipse-ecj also).
The second is to use the standalone ecj compiler (instead of gcj) to
build ecj.jar. The jikes compiler could also be used successfully here.
Right now jikes is only in FE, not core, though.
- --
Sincerely,
David Walluck
<david(a)zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDKxR2arJDwJ6gwowRAmjxAKCJxAj/484vTJWA51VHCuRNvAxgDgCgqXQN
qep/vLcJ+EM31EhrkAtfUTA=
=vEKJ
-----END PGP SIGNATURE-----
12:35 p.m.
On Thu, 2005-09-15 at 09:42 +0100, Gary Benson wrote:
Thomas Fitzsimmons wrote:
> On Wed, 2005-09-14 at 10:07 +0100, Gary Benson wrote:
> > Anthony Green wrote:
> > > It would be much better to generate the javadoc from within the
> > > gcc spec file, but my understanding is that this can't happen
> > > until gjdoc is imported into GCC.
> >
> > Why not?
>
> Because we don't want to introduce another bootstrapping problem;
> gjdoc BuildRequires gcj, gcj would BuildRequires gjdoc.
Why is that a problem? Everything that gcc BuildRequires also
BuildRequires gcc.
Yeah, I guess you're right. So someone should submit a spec file patch
to Jakub, I guess. Anthony?
Tom
6796
days inactive
6801
days old
java-devel@lists.fedoraproject.org
20 comments
5 participants
participants (5)
-
Andrew Overholt -
Anthony Green -
David Walluck -
Gary Benson -
Thomas Fitzsimmons