Eclipse 3.4 packaging - help needed
Michael Koch
We need help to package Eclipse 3.4. If you have some free time you can
help.
Eclipse 3.4 depends on much 3rd party libraries. The libraries we dont
have packaged yet are sat4j and Eclipse ECF. If someone could package
these this would be of great help.
I have uploaded a prelimary orig.tar.gz to
http://people.debian.org/~mkoch/eclipse/
This is probably not the last one before an potential upload. It may
change in the future. This one is just for making distributed work on
eclipse packaging possible.
The needed debian/ directory can checked out from pkg-java SVN on
alioth.debian.org.
If you have time and want to help please speak up here so we can
coordinate work.
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-ja...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jens Kapitza
> Hello folks,
hi,
> If you have time and want to help please speak up here so we can
> coordinate work.
>
i have some free time but i'm a beginner in building debs.
if help still wanted just give me a short answer or some instructions.
>
> Cheers,
> Michael
>
>
Jens
Onkar Shinde
> Hello folks,
>
>
> We need help to package Eclipse 3.4. If you have some free time you can
> help.
>
> Eclipse 3.4 depends on much 3rd party libraries. The libraries we dont
> have packaged yet are sat4j and Eclipse ECF. If someone could package
> these this would be of great help.
>
> I have uploaded a prelimary orig.tar.gz to
>
> http://people.debian.org/~mkoch/eclipse/
>
> This is probably not the last one before an potential upload. It may
> change in the future. This one is just for making distributed work on
> eclipse packaging possible.
>
> The needed debian/ directory can checked out from pkg-java SVN on
> alioth.debian.org.
>
> If you have time and want to help please speak up here so we can
> coordinate work.
I am interested in getting Eclipse 3.4 in Debian/Ubuntu. As of now I
don't have any debian installation. Either I will create a chroot for
building or probably have a virtual box setup by end of week.
I have brief experience in packaging java apps, libs but I have never
explored eclipse code or even built it on my own.
By the way, I suppose ECF means 'Eclipse Communication Framework'.
Does the default build really depend on that? The classic build
available at [1] doesn't include ECF.
1. http://www.eclipse.org/downloads/packages/eclipse-classic-34/ganymeder
Onkar
Markus Knauer
> By the way, I suppose ECF means 'Eclipse Communication Framework'.
> Does the default build really depend on that? The classic build
> available at [1] doesn't include ECF.
>
> 1. http://www.eclipse.org/downloads/packages/eclipse-classic-34/ganymeder
Yes, ECF means Eclipse Communication Framework and
Yes, even the 'Classic' download depends on it, see feature
org.eclipse.equinox.p2.user.ui that contains the required ECF plug-ins for
the p2 functionality, such as
org.eclipse.ecf
org.eclipse.ecf.filetransfer
org.eclipse.ecf.identity
org.eclipse.ecf.provider.filetransfer
org.eclipse.ecf.provider.filetransfer.ssl
org.eclipse.ecf.ssl
Markus
Andrew Overholt
* Michael Koch <konq...@gmx.de> [2008-06-30 02:11]:
>
> Eclipse 3.4 depends on much 3rd party libraries. The libraries we dont
> have packaged yet are sat4j and Eclipse ECF.
For Fedora, I've decided to just build the ECF plugins that 3.4 needs as
part of the SDK build. ECF 2.0 -- which includes the filetransfer
plugins that are dependencies of the SDK -- requires version 3.4 of the
SDK to build so I've avoided this circular dep. for now. At some point
in the future we can create an eclipse-ecf package.
HTH,
Andrew
Michael Tautschnig
> We need help to package Eclipse 3.4. If you have some free time you can
> help.
>
> Eclipse 3.4 depends on much 3rd party libraries. The libraries we dont
> have packaged yet are sat4j and Eclipse ECF. If someone could package
> these this would be of great help.
>
[...]
Actually, I'm about to package sat4j [0], but haven't fully succeeded yet. I'll
try to speed up to help you out, but most likely we'll require further
coordination.
My suggestions would thus be: I'll try to finalize packaging, and ping you
afterwards.
Best,
Michael
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485127
PS.: Please CC me on replies, I'm not subscribed to debian-java.
Andrew Overholt
* Michael Tautschnig <m...@debian.org> [2008-07-21 17:29]:
>
> Actually, I'm about to package sat4j [0], but haven't fully succeeded yet.
Feel free to look at my Fedora packages (and suggest improvements :):
http://cvs.fedoraproject.org/viewcvs/rpms/sat4j/devel/
Also, Daniel (upstream) asked me to package 2.0.2 when he releases it
soon as that will contain all of the tests and data (so they can all be
run) and a few other cleanups.
Michael Tautschnig
> > Actually, I'm about to package sat4j [0], but haven't fully succeeded yet.
>
> Feel free to look at my Fedora packages (and suggest improvements :):
>
> http://cvs.fedoraproject.org/viewcvs/rpms/sat4j/devel/
>
> Also, Daniel (upstream) asked me to package 2.0.2 when he releases it
> soon as that will contain all of the tests and data (so they can all be
> run) and a few other cleanups.
>
Daniel already informed me about your packaging efforts and I've also read your
postings in the forum.
It seems you don't use the maven build system either (that currently seems to be
impossible in an offline build environment), but I tried not to pull in eclipse
as a build dependency. I thus adapted one of the old build-2.4.xml files.
Further, I removed all the tests (for now), because most of them lack proper
license info. I'll talk to Daniel about this. Otherwise, no patching was
necessary when using the 2_0_1 tag in upstream SVN.
As far as eclipse is concerned: sat4j now resides in NEW. As I'm new to Java
packaging in Debian the package may be broken in some way, so I'd be happy to
get lots of input from the eclipse maintainers on the usability of the package
for your purpose.
Best,
Michael
Andrew Overholt
* Michael Tautschnig <m...@debian.org> [2008-07-23 03:33]:
>
> It seems you don't use the maven build system either (that currently seems to be
> impossible in an offline build environment)
I am using PDE Build so that I get the same JAR as what Orbit [1] provides.
FWIW, the maven2 package in Fedora works fully offline. Perhaps the
Debian maven maintainer should speak to the Fedora maintainer because
apparently upstream has resisted patches to make it work fully offline
so it looks like distros will all unfortunately have to carry the same
patches.
> Further, I removed all the tests (for now), because most of them lack proper
> license info. I'll talk to Daniel about this.
Cool, please keep me posted on this.
> Otherwise, no patching was necessary when using the 2_0_1 tag in
> upstream SVN.
That's great. I am still on 2.0.0 so that I get the same as what Orbit
has and was going to wait until 2.0.2 to upgrade.
Andrew
[1]
http://www.eclipse.org/orbit
Michael Tautschnig
sat4j finally found its way into unstable, so you might want to start testing it
for your eclipse packaging effort.
I had still used sun-java6-jdk for building it, thus it currently resides in
contrib. I'll switch over to openjdk-6-jdk with the next upload (build already
tested, works fine), but for testing your eclipse builds that should not matter
terribly much.
[...]
@Andrew:
>
> > Further, I removed all the tests (for now), because most of them lack proper
> > license info. I'll talk to Daniel about this.
>
> Cool, please keep me posted on this.
>
> > Otherwise, no patching was necessary when using the 2_0_1 tag in
> > upstream SVN.
>
> That's great. I am still on 2.0.0 so that I get the same as what Orbit
> has and was going to wait until 2.0.2 to upgrade.
>
2.0.2 is out (2008-08-06), but tests still lack proper license information. The
new version has been reported as #493917 in the Debian BTS, and I'll probably
clone this bug to track the license issue. Daniel is tracking this as
http://forge.objectweb.org/tracker/index.php?func=detail&aid=310644&group_id=228&atid=350289
One thing I'm still not too sure about is the versioning. Daniel uses 2.0.X in
the SVN repository, but releases using, e.g., 20080806.
Best,
Michael
Pablo Duboue
I am very interested in getting a newer Eclipse into Debian. Any
chances we can use
http://wiki.debian.org/Eclipse
to coordinate efforts?
I maintain a set of Debian boxes (running stable) with eclipse for a
small development
team (12+ people).
We need Eclipse 3.4 and we're running it from /opt right now. I would
rather have
3.4 integrated into Debian and would happily move the machines to
testing for that.
>From what I gather from earlier e-mails, the issues are:
* Packaging the new third party packages required by eclipse,
particularly ECF that
require a Maven2 toolchain for compilation that doesn't run off-line
in upstream (but
there are Fedora patches we can use).
* Testing with the fast changing set of JDK currently available in
unstable and make
a pick. I guess this will have to be changed as the JDKs change.
* (Haven't been mentioned, but I'll throw it in) Getting the existing
PyDev, C++ Dev and
SVN plugins also working under 3.4.
(I have added these bullets to the above referred wiki page, of
course, I can be _dead wrong_
about this stuff, please correct the page or even remove the whole
thing altogether if you
think it is going in the wrong direction.)
Thanks!
Pablo
Pantelis Koukousoulas
>
> * Packaging the new third party packages required by eclipse,
> particularly ECF that
> require a Maven2 toolchain for compilation that doesn't run off-line
> in upstream (but
> there are Fedora patches we can use).
Eclipse has quite a few jar dependencies that need to be "OSGIfied"
some (most) times this just needs a small patch for the Manifest.MF
so it should not be such a big deal (but still someone has to do it).
Indeed Fedora has all the needed patches.
>
> * Testing with the fast changing set of JDK currently available in
> unstable and make
> a pick. I guess this will have to be changed as the JDKs change.
Why not just use OpenJDK? it is free software (from what I can tell)
and works fine at least
for 3.4 and above.
>
> * (Haven't been mentioned, but I'll throw it in) Getting the existing
> PyDev, C++ Dev and
> SVN plugins also working under 3.4.
Those really shouldn't be that hard. CDT might be the most problematic
because it contains native code besides Java, but the eclipse core
is an order of magnitude bigger PITA than that.
>
> (I have added these bullets to the above referred wiki page, of
> course, I can be _dead wrong_
> about this stuff, please correct the page or even remove the whole
> thing altogether if you
> think it is going in the wrong direction.)
The biggest problems have to do with e.g., handling native libraries,
the build system,
modularization, proper integration with P2, ...
You could see https://bugs.launchpad.net/eclipse-debian for some tasks
that need to be done. (also https://bugs.launchpad.net/eclipse-ubuntu).
Cheers,
Pantelis
Andrew Overholt
I encourage all those interested in/working on packaging the Eclipse SDK
and Eclipse plugins for Linux distributions to get involved with the
Linux Tools (aka Linux Distros) project at eclipse.org.
One of our sub-projects is imaginately called "eclipse-build" and is an
attempt to provide a simple, buildable-out-of-the-box tarball of the
Eclipse SDK. We're almost at the stage of it producing a working
Eclipse SDK installation and we'd love to see all distributions
standardize on it as the input to their "eclipse" packages.
We have other sub-projects on the go including:
- a wrapper around the Eclipse SDK test suite that makes them runnable
against a set of installed packages
- scripts to ease the building of Eclipse plugins
- a tool to create a skeleton of an RPM .spec file for Eclipse plugins
which we'd love to see extended to Debian packages
Please join us on linuxto...@eclipse.org [1] and #eclipse-linux on
Freenode.
Looking forward to collaborating,
Andrew
[1]
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev