Agreed.
Eclipse projects have scope. An image viewer may fall into a bit of
a gray area, until you start the inevitable expansion of scope to
include modest image manipulation tools, etc.
I have some image tools in the Examples project that I'd love to
find a new home for; I could help with the project creation process
if there are others interested in participating.
Wayne
On 10/21/2013 02:58 PM, Konstantin
Komissarchik wrote:
I
don’t think we need another container project or a
monolithic “IDE” project to hold features that don’t find
place in existing projects. These days, it is a lot easier
to create a micro-project under say Tools or Technology than
it used to be. It isn’t a matter of a few clicks, like it
should be, but it is a lot better than what it used to be
and you meet a lot less resistance along the way.
I
am personally of the opinion that it isn’t good to keep
growing the size of the platform. The platform should stay
small to be suitable to a wide variety of usecases and be
mainly concerned with facilitating work happening elsewhere.
We do not need to stuff more into the platform to improve
Eclipse IDE.
-
Konstantin
Maybe
this is a case where the Eclipse IDE Project makes sense.
Then we wouldn't be having this discussion and the Eclipse
IDE would have it's image viewer. Mind you, we still might
need changes to the Platform to enable it, but they would
be in the right direction of making the Platform more
pluggable.
BTW,
we have a lot of functionality in the CDT that really
belongs in the Platform, In Our Humble Opinion. We just
found it easier (back in the dark times), to just
implement it close to home. I wonder how many other
projects have done the same. I'd bet we could build up an
IDE project with a lot of functionality day one.
But
I'd like to hear from Platform leadership team first. Does
the Platform want to open up more in this direction? Or
would they prefer we find a different home for these
common features.
Having
been involved in the discussion and having made several
attempts to facilitate a solution, I see the image
viewer story as most illustrative of what happens when a
contributor is unwilling to be flexible. Various options
were offered that would have led to an image view in
Eclipse IDE packages, but it was either in platform or
nowhere, so in the end we have no image viewer in
Eclipse IDE to date.
Projects
will reject features for various reasons. We need to be
ready to find alternate accommodations and contributors
need to be flexible enough to work with such
accommodations. We are certainly better prepared for
this today than six years ago. EMO is more willing than
before to accept micro-projects and improvements in
common infrastructure (such as the common build system)
make it a lot less costly to have a project around a
single feature, if such thing is necessary.
-
Konstantin
BTW,
to be fair fair about the image viewer story, the
rejection happened 6 years ago near the end of the
dark times…
I
do not make purchasing/consortium participation
decisions on behalf of NVIDIA. I am an input to
such decisions made by my superiors.
What
I am writing to this list is my personal opinion.
At
NVIDIA, I am working on "Nsight Eclipse Edition" -
that is an Eclipse-based IDE for CUDA developers.
Before NVIDIA I was working on other Eclipse-based
IDEs (paid or not).
I
find it ironic that it is possible to get GSoC
student work on adding generics to the JFace into
the main repo, while experienced developer's
contribution of image viewer (I mentioned the bug
number in my original letter) was rejected with
prejudice. I personally had to implement similar
viewer more then once for different projects.
I
am looking at this WG from a point of view "what
would we get for participation" - as this is the
question I need to answer if I raise this topic
with my manager.
Personally,
I believe there is a need for a more open
collaboration place for adopters to work on what
they see as a better Eclipse Platform for IDEs.
Currently adopters are forced to ship their own
forks - so I wonder if this project could become
some sort of unified fork that better suits the
needs of IDEs.
One
thing I would like to point out is that for some
teams it might be easier to contribute developer
time than money as those decisions are made on
different levels and development teams more
readily recognize the value of collaboration.
Before
playing this back-and-forth:
What's
your position on the WG - or funding
developers in general that work on, say, JDT,
CDT or EMF? Are you looking at this from an
investors view point or more from a
developer's view point. Not sure what the role
of a lead architect at nvidia is.
In
any case, from your writing I get the
impression that you don't see any good way to
contribute to the existing platform (no critic
in here). If that's true, what can we do? Will
all tries to modernize the Eclipse IDE fail?
So
let's imagine some company is
really bothered by such issues
and joins this working group
(note the hefty price tag of
$120k/year).
The
price tags are just a proposal and
haven't been validated currently.
But I think you are referring to
the highest one which includes
steering committee membership.
My
understanding is that non-steering
participation does not give any
voting rights.
1.
Are there any guarantees
somebody would actually
implement these enhancements?
What may prevent these funds
from being spent on EMF
enhancements if they get more
votes?
I
think it will be important to make
that the working group operates
open and transparent. Therefore,
the whole funding and wishlist
including voting will be visible.
That allows to make a clear
judgment on what impact specific
funding will make.
This
means that either companies invested
in CDT or EMF will not get what they
joined for.
2.
What would be a timeframe before
implementation starts? Would
there be a committed delivery
schedule?
I
expect this to happen as part of
the work item analysis and upon
assignment of such items to the
implementation partner.
How
will this happen? A lot of time will
be spent defining the "wish list",
then RFPs will be sent out,
prospecting "implementation
partners" will submit proposals,
voting on proposals will commence,
so on? Sounds like years will pass
without any output.
3.
How could such a general-purpose
text editor avoid sharing the
fate of Bug 155323?
It's
an important role of the working
group steering committee to find
solutions to such problems. I
could imagine that if no project
is willing to accept a feature
such as a general purpose image
viewer or text file editor, the
work is brought in as a new
project and made available as part
of the release train and in the
downloadable packages.
I
do not think these two items can
happen without at least some platform
changes (I am only familiar with E3 -
and at least hooks will have to be put
there).
This
email message is for the sole use of
the intended recipient(s) and may
contain confidential information. Any
unauthorized review, use, disclosure
or distribution is prohibited. If you
are not the intended recipient, please
contact the sender by reply email and
destroy all copies of the original
message.
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide-dev
|