-----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-----
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
