From Fedora Project Wiki
m (1 revision(s)) |
(Remove old items) |
||
| Line 12: | Line 12: | ||
* Investigate why plugins cannot be built if they are already installed on the build system. We use a shell script to copy over the SDK and required plugins without copying the plugin that is being built. See http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-copy-platform.sh | * Investigate why plugins cannot be built if they are already installed on the build system. We use a shell script to copy over the SDK and required plugins without copying the plugin that is being built. See http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-copy-platform.sh | ||
* Build cairo JNI bits. See this patch http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-5/eclipse-libswt-cairo1.0-3.patch that was carried in Fedora Core 5. We think the above patch may be an incorrect approach for getting it upstream, but it's a starting point. | * Build cairo JNI bits. See this patch http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-5/eclipse-libswt-cairo1.0-3.patch that was carried in Fedora Core 5. We think the above patch may be an incorrect approach for getting it upstream, but it's a starting point. | ||
| Line 36: | Line 34: | ||
* Investigate http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-ecj-rpmdebuginfo.patch for getEnv changes in the JDK. | * Investigate http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-ecj-rpmdebuginfo.patch for getEnv changes in the JDK. | ||
* Move the OSGi-ified jsch manifest to the jsch jar. Will upstream take this? This needs investigation because Eclipse is moving to using these OSGi-ified jars for all of its dependencies. | * Move the OSGi-ified jsch manifest to the jsch jar. Will upstream take this? This needs investigation because Eclipse is moving to using these OSGi-ified jars for all of its dependencies. | ||
* Help out with the various [https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&component=eclipse&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= Fedora Eclipse bugs] | * Help out with the various [https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&component=eclipse&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= Fedora Eclipse bugs] | ||
=== Development Oriented Tasks === | === Development Oriented Tasks === | ||
| Line 50: | Line 44: | ||
* Investigate and create a way for src zips to be automatically attached to external jars when they are added to the build path of a project. These src zips are useful for debugging and browsing the source of these external jars. See this thread for some more information: https://www.redhat.com/archives/fedora-devel-java-list/2006-November/msg00023.html | * Investigate and create a way for src zips to be automatically attached to external jars when they are added to the build path of a project. These src zips are useful for debugging and browsing the source of these external jars. See this thread for some more information: https://www.redhat.com/archives/fedora-devel-java-list/2006-November/msg00023.html | ||
* As part of the making the Eclipse packages multilib compatible, we had to move the platform dependent files from /usr/share/eclipse/ to /usr/lib{,64}/eclipse. This caused two problems: (1) The Product Configuration manager thinks that these 4 fragments are missing and (2) it's possible for a user to disable the extension location and therefore disable all those fragments. The next time the user starts Eclipse, it doesn't work because it can't find the SWT fragment. The user must delete their configuration (i.e. 'rm -rf ~/.eclipse') to get Eclipse to start again. To fix this problem, the update manager code needs to become OSGi aware. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=162798 for more information. | * As part of the making the Eclipse packages multilib compatible, we had to move the platform dependent files from /usr/share/eclipse/ to /usr/lib{,64}/eclipse. This caused two problems: (1) The Product Configuration manager thinks that these 4 fragments are missing and (2) it's possible for a user to disable the extension location and therefore disable all those fragments. The next time the user starts Eclipse, it doesn't work because it can't find the SWT fragment. The user must delete their configuration (i.e. 'rm -rf ~/.eclipse') to get Eclipse to start again. To fix this problem, the update manager code needs to become OSGi aware. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=162798 for more information. | ||
* Write an app that can re-write the timestamps of jar/zip files so that they have the same md5sum accross builds. This needs to support jars/zips within jars/zips. | * Write an app that can re-write the timestamps of jar/zip files so that they have the same md5sum accross builds. This needs to support jars/zips within jars/zips. | ||
Revision as of 20:23, 9 February 2009
Eclipse Help Wanted
Mentor
Ben Konrath - <bkonrath@redhat.com> - scsibear on irc.freenode.net
Overview
As you can see, there is a lot of work to do on the Eclipse packages for Fedora. I listed my name beside the tasks that I'm planning to tackle in the near future. If you would like to help with anything listed here, feel free to contact me and/or list your name beside the task that you are interested in working on. If there is a name already listed on a task you want to help with, you should contact that person to see if there is anything you can help with - some tasks could use more than one person.
Packaging Oriented Tasks
- Investigate why plugins cannot be built if they are already installed on the build system. We use a shell script to copy over the SDK and required plugins without copying the plugin that is being built. See http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-copy-platform.sh
- Build cairo JNI bits. See this patch http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-5/eclipse-libswt-cairo1.0-3.patch that was carried in Fedora Core 5. We think the above patch may be an incorrect approach for getting it upstream, but it's a starting point.
- Get an upstream source for the file initializer plugin. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=90535 for details.
- Make a patch to not redirect javadoc generation output to .txt files (rather than what we do with sed commands). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=144942 for more information.
- Fedora carries two patches to build libupdate on all platforms and with -fPIC. These patches http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-libupdatebuild.patch http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-libupdatebuild2.patch should be submitted to the update team.
- Investigate support for building native code as part of pde.build. See patches in https://bugs.eclipse.org/bugs/show_bug.cgi?id=71637 Also, see Ben's proposed solution (which may need some updating) http://www.bagu.org/eclipse/plugin-source-drops.html Right now in Fedora, we carry a http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-build.patch to build liblocalfile and libupdate in the main SDK build.xml.
- Investigate building of swttools.jar during SDK build: http://cvs.fedora.redhat.com/viewcvs/devel/eclipse/eclipse-swttools.patch?view
- investigate building of launcher. Why unzip launchersrc.zip? This makes us have to unzip, patch, and re-zip.
- The HTML of the javadocs in org.eclipse.platform.doc.isv_3.2.1.r321_v2006030.jar are generated differently on different architectures therefore multililb conflicts are present if this plugin is included in /usr/share/eclipse/. As a workaround, we are including this plugin in /usr/lib{,64}/eclipse/plugins. This problem needs to be investigated and fixed so that this plugin can move back to /usr/share/eclipse/plugins/.
- WEB-INF/web.xml in org.eclipse.help.webapp_3.2.1.R321_v20060803 is generated differently on different architectures therefore multililb conflicts are present if this plugin is included in /usr/share/eclipse. As a workaround, we are including this plugin in /usr/lib{,64}/eclipse/plugins. This problem needs to be investigated and fixed so that this plugin can move back to /usr/share/eclipse/plugins/.
- It would be nice if the launcher source zip could be removed from org.eclipse.platform.source_3.2.1 or the patch could be made in such a way that it would not produce arch-dependent source code. This might not be possible but it should be investigated.
- Investigate http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/devel/eclipse-ecj-rpmdebuginfo.patch for getEnv changes in the JDK.
- Move the OSGi-ified jsch manifest to the jsch jar. Will upstream take this? This needs investigation because Eclipse is moving to using these OSGi-ified jars for all of its dependencies.
- Help out with the various Fedora Eclipse bugs
Development Oriented Tasks
- Create an Extension Point to the JDT for contributing source foramatting configurations. This would allow the various linux distros to include GNU formatting conventions without the need for patches. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=91770 http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-5/eclipse-gnuformatterjdt.patch http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-5/eclipse-gnuformatterjdtui.patch for more details.
- Investigate and create a way for src zips to be automatically attached to external jars when they are added to the build path of a project. These src zips are useful for debugging and browsing the source of these external jars. See this thread for some more information: https://www.redhat.com/archives/fedora-devel-java-list/2006-November/msg00023.html
- As part of the making the Eclipse packages multilib compatible, we had to move the platform dependent files from /usr/share/eclipse/ to /usr/lib{,64}/eclipse. This caused two problems: (1) The Product Configuration manager thinks that these 4 fragments are missing and (2) it's possible for a user to disable the extension location and therefore disable all those fragments. The next time the user starts Eclipse, it doesn't work because it can't find the SWT fragment. The user must delete their configuration (i.e. 'rm -rf ~/.eclipse') to get Eclipse to start again. To fix this problem, the update manager code needs to become OSGi aware. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=162798 for more information.
- Write an app that can re-write the timestamps of jar/zip files so that they have the same md5sum accross builds. This needs to support jars/zips within jars/zips.