Re: Eclipse 3 packaging
On Mon, Mar 07, 2005 at 03:30:08AM -0500, Barry Hawkins wrote:
> 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.
I totally agree. Having completely componized Eclipse will give us big
benefits when its done. We need to think about installing other plugins
not in the core distribution too.
> 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.
I don thin the UI issues in current free VMs will not hit as Eclipse
uses its own widget set which is already proven to work. We should use
free software from start but dont deny support for other
implementations. We should really recommend a free runtime.
> ~ 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.
We should focus on moving it to main. I know this is not possible yet
becuase of dependencies not in main yet but main is the big goal we
should aim for.
> 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.
I totally agree on using 3.1 (3.1M5 currently).
Michael
--
Java Trap: http://www.gnu.org/philosophy/java-trap.html
Reply to: