-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have made a partial list of requirements for a base system and I've run into a few problems when trying to build everything from the ground up.
First, here is the (partial) list:
* jpackage-utils * java-1.4.2-gcj4.0-compat o Requires: eclipse-ecj o Requires: gjdoc + BuildRequires: antlr o Requires: jessie + Requires: gnu-crypto # BuildRequires: ant # BuildRequires: bcel * BuildRequires: regexp # BuildRequires: javamail (classpathx) * BuildRequires: classpath-inetlib-javadoc # BuildRequires: jaf (classpathx) # BuildRequires: jakarta-commons-logging * BuildRequires: avalon-logkit o BuildRequires: servlet (tomcat5) * BuildRequires: avalon-framework o BuildRequires: xalan-j2 + BuildRequires: jlex + BuildRequires: java_cup o BuildRequires: xerces-j2 # BuildRequires: jdepend # BuildRequires: jsch * BuildRequires: jzlib # BuildRequires: junit # BuildRequires: log4j * BuildRequires: xml-commons-apis # BuildRequires: oro # BuildRequires: regexp # BuildRequires: xml-commons-resolver
The major problem stems from the requirements (not the build requirements) of java-1.4.2-gcj4.0-compat. Now, antlr can be built without ant or the gcj-compat package, so it should be fine as well as should gjdoc.
Then, our first problem comes from eclipse-ecj. If this is supposed to come from eclipse, then there is a major bootstrapping problem, as eclipse has many dependencies. However, ecj used to be distributed separately. I tried building it, but it relies on katana, and the build for ecj fails when katana fails with some exception. Anyway, I don't know if the current wrapper scripts for gcj-compat even honor this eclipse-ecj jar which has a different name than the current eclipse-ecj as far as I can tell.
Note that ecj is still in fedora development, but katana is not (even though it is required by eclipse-ecj).
A minor issue seems to be that classpathx-mail requires classpath-inetlib-javadoc, only I can't find a separate classpath-inetlib package. Instead, it seems to be in the classpathx-mail rpm, in which case no package can provide the classpath-inetlib-javadoc dependency that is needed.
The other major problem is jessie. Does java-1.4.2-gcj4.0-compat really need jessie? Probably it does not for any of the base requirements. It may be possible to leave this requirement out initially, or leave it out together, and pull in jessie some other way.
The final big headache seems to be that all of tomcat5 would need to be built to satisfy the servlet requirement of jessie. As I recall, servlet also used to be distributed separately from tomcat5. This would be a great win in terms of simplifying how many packages would need to be bootstrapped.
I would like some opinions on how to handle the ecj requirement and the jessie/servlet requirement. Keep in mind that if jessie is required by gcj-compat, then twenty-something packages (not even including tomcat5) would need to be built, and yet we don't have a compatible jdk installed. Obviously, nearly everything can be solved by providing a separate eclipse-ecj that actually builds, and not requiring jessie. A separate servlet rpm would also be nice, to save pulling in everything required by tomcat5.
- -- Sincerely,
David Walluck david@zarb.org
Hi,
On Wed, 2005-05-04 at 19:22 -0400, David Walluck wrote:
Then, our first problem comes from eclipse-ecj. If this is supposed to come from eclipse, then there is a major bootstrapping problem, as eclipse has many dependencies. However, ecj used to be distributed separately. I tried building it, but it relies on katana, and the build for ecj fails when katana fails with some exception. Anyway, I don't know if the current wrapper scripts for gcj-compat even honor this eclipse-ecj jar which has a different name than the current eclipse-ecj as far as I can tell.
Yes, we know about this circular dependency. We didn't want to create and maintain an eclipse-ecj RPM separate from the Eclipse package. The real solution here is to make gcj -C a true replacement for javac. gcjx will make this happen, hopefully in time for Fedora Core 5.
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
Note that ecj is still in fedora development, but katana is not (even though it is required by eclipse-ecj).
A minor issue seems to be that classpathx-mail requires classpath-inetlib-javadoc, only I can't find a separate classpath-inetlib package. Instead, it seems to be in the classpathx-mail rpm, in which case no package can provide the classpath-inetlib-javadoc dependency that is needed.
The other major problem is jessie. Does java-1.4.2-gcj4.0-compat really need jessie? Probably it does not for any of the base requirements. It may be possible to leave this requirement out initially, or leave it out together, and pull in jessie some other way.
I'm working on a patch that will merge Jessie into GNU Classpath/libgcj which will eliminate this dependency.
Tom
On Wed, 2005-04-05 at 22:55 -0400, Thomas Fitzsimmons wrote:
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
IIRC, some JDT developers were talking about releasing ECJ as an official download:
http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg01166.html
Would this make providing an ECJ package a easier? If so it might be worth commenting on that post.
Cheers, Ben
On Wed, 2005-05-04 at 23:11 -0400, Ben Konrath wrote:
On Wed, 2005-04-05 at 22:55 -0400, Thomas Fitzsimmons wrote:
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
IIRC, some JDT developers were talking about releasing ECJ as an official download:
http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg01166.html
Would this make providing an ECJ package a easier? If so it might be worth commenting on that post.
Yes, a separate ecj is a great idea. I'm not subscribed to that list; can someone who is post a message in support of the idea?
Thanks, Tom
Cheers, Ben
-- fedora-devel-java-list mailing list fedora-devel-java-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
On Wed, 2005-05-04 at 23:44 -0400, Thomas Fitzsimmons wrote:
On Wed, 2005-05-04 at 23:11 -0400, Ben Konrath wrote:
On Wed, 2005-04-05 at 22:55 -0400, Thomas Fitzsimmons wrote:
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
IIRC, some JDT developers were talking about releasing ECJ as an official download:
http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg01166.html
Would this make providing an ECJ package a easier? If so it might be worth commenting on that post.
Yes, a separate ecj is a great idea.
Hmm, on second thought, it depends how they're doing this. The archives you've linked to require a username and password, so I can't see the post.
We only want one copy of ecj installed on the system. So if they're proposing splitting out ecj from the rest of eclipse then that would be very useful. (It would likely also solve their known-good compiler vs. proper bootstrapping issues). But if they're just making ecj available separately as well as with eclipse itself then it's not that useful to us, since we'll always want to be using the in-eclipse ecj. In that case we'd just stick with how we're packaging eclipse currently.
Tom
On Wed, 2005-04-05 at 23:49 -0400, Thomas Fitzsimmons wrote:
On Wed, 2005-05-04 at 23:44 -0400, Thomas Fitzsimmons wrote:
Yes, a separate ecj is a great idea.
Hmm, on second thought, it depends how they're doing this. The archives you've linked to require a username and password, so I can't see the post.
You have to sign up for an Eclipse.org account if you want to read the archives:
http://dev.eclipse.org/newsManager/newsRequestForm.html
We only want one copy of ecj installed on the system. So if they're proposing splitting out ecj from the rest of eclipse then that would be very useful. (It would likely also solve their known-good compiler vs. proper bootstrapping issues). But if they're just making ecj available separately as well as with eclipse itself then it's not that useful to us, since we'll always want to be using the in-eclipse ecj. In that case we'd just stick with how we're packaging eclipse currently.
It's not clear which way they want to go, but I imagine they would follow the SWT's lead and provide ECJ separately *and* include it with the Eclipse SDK. The post is asking about ahead of time compilation of ECJ and wondering how it is done. Nobody has responded yet so perhaps you should post your thoughts.
Cheers, Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
It shouldn't be too hard to do this. The question then becomes: what is necessary for gcj to pick up ecj as the compiler? As I recall from eclipse.spec, it just set a .so in its LD_LIBRARY_PATH. This won't work for the bytecode-only version. I should look myself, but because of the issues stated, I don't have gcj-compat installed on my system at this time.
Also, I guess katana has been dumped for fc4 and beyond? So what is the plan for nativifying jars from now on? Ideally, I wish that it was transparent to other non-native javac's. For example, it would be handled by gcj's javac script and then a macro (or whatever) could be added to pick up any extra files produced.
A minor issue seems to be that classpathx-mail requires classpath-inetlib-javadoc, only I can't find a separate classpath-inetlib package. Instead, it seems to be in the classpathx-mail rpm, in which case no package can provide the classpath-inetlib-javadoc dependency that is needed.
Is this classpath-inetlib-javadoc dependency erroneous? Remember that inetlib got merged in with classpathx-mail. I seem to remember that there was a separate classpath-inetlib package that used to be in fedora development. In any case, it's no longer there, nor did it find its way into JPackage.
I'm working on a patch that will merge Jessie into GNU Classpath/libgcj which will eliminate this dependency.
You mentioned that the ecj stuff was targeted for fc5. Is this also targeted for much later? In that case, I don't think it would hurt to remove jessie as a requirement for gcj-compat (for my purposes at least). After all, any package which needs what it provides will pull it in separately anyway. What package required this that it was necessary to put it into the core? It is only a provider for jce, when jce is provided by gnu-crypto. Perhaps gnu-crypto should require a provider (virtual) and jessie should provide this. The point is that no core package needs a crypto provider as far as I can tell, so there's not much of a point tying it to the core system.
- -- Sincerely,
David Walluck david@zarb.org
Hi,
On Wed, 2005-05-04 at 23:14 -0400, David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
In the meantime it would be very useful to create a pure bytecode eclipse-ecj package, buildable by gcj -C, for distribution by jpackage.org. I wanted to do this when I first submitted java-gcj- compat to JPackage but I never got around to it. All the logic will be in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C.
It shouldn't be too hard to do this. The question then becomes: what is necessary for gcj to pick up ecj as the compiler? As I recall from eclipse.spec, it just set a .so in its LD_LIBRARY_PATH. This won't work for the bytecode-only version. I should look myself, but because of the issues stated, I don't have gcj-compat installed on my system at this time.
I'd recommend looking at eclipse.spec from Rawhide to see how this is done.
Also, I guess katana has been dumped for fc4 and beyond? So what is the plan for nativifying jars from now on? Ideally, I wish that it was transparent to other non-native javac's. For example, it would be handled by gcj's javac script and then a macro (or whatever) could be added to pick up any extra files produced.
See /usr/bin/find-and-aot-compile, /usr/bin/aot-compile and /usr/bin/rebuild-gcj-db in Rawhide java-1.4.2-gcj-compat.
A minor issue seems to be that classpathx-mail requires classpath-inetlib-javadoc, only I can't find a separate classpath-inetlib package. Instead, it seems to be in the classpathx-mail rpm, in which case no package can provide the classpath-inetlib-javadoc dependency that is needed.
Is this classpath-inetlib-javadoc dependency erroneous?
Yes, likely. I'm going to work on classpathx-mail this week; I'll keep this in mind.
Remember that inetlib got merged in with classpathx-mail. I seem to remember that there was a separate classpath-inetlib package that used to be in fedora development. In any case, it's no longer there, nor did it find its way into JPackage.
I'm working on a patch that will merge Jessie into GNU Classpath/libgcj which will eliminate this dependency.
You mentioned that the ecj stuff was targeted for fc5. Is this also targeted for much later?
This will land after FC4 but likely only shortly after, in Rawhide.
In that case, I don't think it would hurt to remove jessie as a requirement for gcj-compat (for my purposes at least).
No, we want java-gcj-compat to depend on jessie because jessie provides an SSLv3 implementation. Sun's SDK has an SSLv3 implementation, so we need one in java-gcj-compat by default.
We put this in the core so that https would work. Eclipse's bugzilla plugin and gcjappletviewer both require https.
So this dependency will be present when FC4 ships, but will be eliminated shortly after.
Tom
java-devel@lists.fedoraproject.org
-
Benjamin Konrath -
David Walluck -
Thomas Fitzsimmons