Re: Eclipse 3 packaging
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Koch wrote:
[...]
| You said in earlier thread on this list that you wanted to setup a
| repository at svn.debian.org.
Michael,
~ In a thread[0] on the little-known pkg-eclipse mailing list, Joerg
indicated that setup of an svn repository had been completed, but not
tested. The svn repository web interface[1] seems to come up fine.
~ There is another thread[2] from that list that contains some key
questions about approaching Eclipse packaging that we should further
discuss. Some issues have changed since then and Jerry Haltom's great
progress in packaging Eclipse have really moved things forward outside
official Debian activity. I will try to summarize the key issues as I
understand them.
I. Choosing A Packaging Approach
~ Part of what makes Eclipse packaging a challenge is that it is not
one thing. Eclipse as we commonly refer to it in Java contexts consists of:
The Eclipse Platform
The SWT Libraries
The Eclipse Java Development Tool, or JDT
The Eclipse Compiler for Java, or ECJ
and others...
~ Each of these is its own project within Eclipse, and the Eclipse
source that most folks (including myself) download is a monolithic
bundle of snapshots from all these CVS repositories. Approaches to
Eclipse packaging must choose a point somewhere along the following
continuum:
A <--------------------------------> B
where A can represent the approach of a convenient, single, large
package/project for source, and B represents a less-convenient,
completely modular, less-redundant packaging approach.
~ The SWT libraries and the Eclipse platform itself need to be
packaged in such a way that applications beside the JDT can also easily
use them without having to install a professional IDE on an average
user's workstation just to get, say, an RSS aggregator.
II. Distribution Targeting Strategy
~ This is a topic that can get unnecessarily inflamed when other
choose to use it as a platform for the free Java movement and/or their
favorite free VM. Let's please avoid that in this discussion. Eclipse
is a desktop application. As such, this makes an attempt to push
Eclipse to main right away rather problematic, even if one chose to just
support x86 and ignore powerpc and the other architectures. Free Java
for the UI is on its way, but I think we can all agree that it is still
on a rather distant horizon.
~ Targeting an interim step, where the goal is to get a really
well-formed, modular packaging of Eclipse's components in contrib with
it running on non-free VMs would serve to break the work into more
manageable steps or phases. Once a really solid, buttoned-down package
that at least builds well on x86 and PowerPC is in place, effort can
focus on a move to main, with the assurance of a solid packaging
foundation beneath us.
III. Choosing An Initial Source Version
~ There has been some talk about this on IRC #debian-java of late, and
the consensus seems to be that going with 3.1 as an initial version is a
good idea. I personally endorse this, as I assisted on a bug report
with Eclipse[3] that enables a successful build on PowerPC Linux with
GTK. Prior to the 3.1 development stream, this build was very broken.
Starting with anything prior to 3.1 will require us to fix/patch quite a
bit of stuff that has been remediated in the 3.1 stream.
[0] -
http://lists.alioth.debian.org/pipermail/pkg-eclipse-maintainers/2005-January/000037.html
[1] - http://svn.debian.org/wsvn/pkg-eclipse
[2] -
http://lists.alioth.debian.org/pipermail/pkg-eclipse-maintainers/2005-January/000004.html
[3] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=57897
Regards,
- --
Barry Hawkins
All Things Computed
site: www.alltc.com
weblog: www.yepthatsme.com
Registered Linux User #368650
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCLBEQ7bZ6kUftWZwRAjy9AJ9w/3vI0YTHHB4D3RJFBN9yWUKLIACeK/M3
nl6gRFyAyq/y9dplKQjWES0=
=/J60
-----END PGP SIGNATURE-----
Reply to: