[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform] Re: No solution found because the problem in /tmp/p2Encoding13004.opb is unsatisfiable.
On 12/12/2008 1:15 PM, John J. Barton wrote:
Eric Rizzo wrote:
On 12/11/2008 2:54 PM, John J Barton wrote: 
...
I'll try your practical solutions, but I want to discuss the philosophy:


I do *not* want to do this. It's not practical for me or my users. What
is practical is what we already do: "use ecilpse jee 3.4.0".


Of course I meant "3.4.x", see below.


That is fine as a user instruction, but is not enough for the platform
(OSGi) to go on. Remember that, although Eclipse has coordinated
releases (named things like Europa, Ganymede, Galileo) and the EPP
project produces convenient packages that include sets of plugins from
those coordinated releases, each plugin can evolve independently AND a
user is free to update or install new plugins at any time. Therefore
it is impossible to define "Eclipse JEE 3.4.0" unless you spell out
what versions of what features and plugins that includes. Plus, that
is a very specific case, not one that most plugins or Eclipse-based
products want because it would be VERY restrictive. For example, I
can't use the SR2 (Ganymede 3.4.2, if you want to call it that) with
your plugins? Really? There's no API changes allowed in an increment
release (3.4.x) so there should not be such a restriction in most
cases. See what I mean by the balance between guaranteed compatibility
and overly restrictive?

I understand the issues, but I still claim that Eclipse has gotten this
wrong.

You say "There's no API changes allowed in an increment release
(3.4.x)". That is exactly the kind of information I rely on when I tell
uses "this plugin works with 3.4". So when I build my plugin I should
say "test with 3.4" and when it ships and users install the answer
should be "success" or "requires 3.4". This is not impossible or
difficult, it's what people do all of the time.

As I've already said, there really is no "Eclispe 3.4" unless you are limiting the discussion to just the core platform (which is NOT what the vast majority of Eclipse users have, BTW - most have one of the packages that include LOTS more stuff).
So you can not only say "Requires 3.4" - it would be about as meaningful as saying "Requires Eggplant." Sure, some users might want such a simplified view of the things but, it would be a misleading, distorted, and incomplete view. And the fact that Eclipse is a collection of features and plugins can not be hidden that much unless you're willing to go down the RCP route. It was not designed or intended to be so simplistic.



It's great that eclipse *allows* much finer detail, but it needs to get
the basic function working first. It's great that it supports all kinds
of configs, but it should get the basic IDE configs that thousands of
developers rely on working first. And it should not matter what I put in
to the dev API, the end user should always get some information that
helps them or helps the developer move forward. I like seeing debug
output from a tool, but not as the primary UI from a tool for end users.

The UI for p2 is undergoing some major overhauling and I encourage you to get involved in those discussions before it is too late (Milestone 4 is nearly complete).
You can start here:
http://wiki.eclipse.org/Equinox_p2_UI_3.5_workflows
(and the bug reports listed at the bottom of that page)


Sorry I am so negative on this but its very frustrating to work on a
plugin and then find users can't install it.

Don't you find it telling that thousands of other developers are successfully writing plugins? I'm trying to say that I think your problems are mostly due to either misunderstanding how the platform works or a desire for unrealistic over-simplification.

Eric