[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] e4 tools build moving to Luna?
|
I think the only location for tools that
makes sense is PDE. We don't include plug-in tooling with the core platform
because end users don't need it unless they are doing plugin/app development.
To me the model editor belongs right alongside the product editor, manifest
editors, etc as part of the main PDE install.
You had a concern about the tools needing
to evolve in parallel: that is not a problem since PDE is produced in the
same build as the platform and they always evolve together. Your other
concern was about PDE developers not being as well connected. Any contributors
to the tools will be nominated as committers as part of the graduation
process, so everyone connected with the tools will continue to have the
same access.
John
From:
Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>
To:
e4-dev@xxxxxxxxxxx,
Date:
02/17/2014 09:58 AM
Subject:
Re: [e4-dev]
e4 tools build moving to Luna?
Sent by:
e4-dev-bounces@xxxxxxxxxxx
OK, open questions for me are:
1. Where to move: Platform or PDE (as I wrote I rather prefer Platform)
2. Shall we split org.eclipse.e4.tools.services into one bundle which remains
in e4 and move the services, which are used by the tools to a new bundle
(or maybe just into the tools bundle.
I really would like to get the opinion of committers of the target projects
(PDE or Platform). I am willing to contribute here, but it does not make
sense, if we do not know, whether you are willing to accept the tools then
or which things you require to do it.
Regards
Jonas
Am 14.02.2014 15:54, schrieb Wim Jongman:
The question is, do we want to graduate the tools without
full NLS and without testcases and documentation.
My 2 cents: I am happy with the current state of the model
editor and would not mind to graduate that. If we graduate "as is"
then we get a lot more feedback from the community. We could even build
something in the model editor to install the rest of the tooling (from
incubation) on request.
About documentation: Lars has documented almost everything
so there is no direct need for "official" documentation this
instance. However, in time, I think we need to provide "official"
documentation from Eclipse. If Lars wants to donate some of his work to
become official (and hosted from eclipse.org)
then this would be awesome. I would not be surprised that the bylaws
don't allow to point to Lars' site for documentation.
Also we would publish no API.
In other words, I am +1 for graduating the model editor
if we still have time.
Cheers,
Wim
On Fri, Feb 14, 2014 at 2:59 PM, Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>
wrote:
Hi,
I never received an answer to this mail, does no one have a opinion on
this? Is anyone still interested in this topic?
Best Regards
Jonas
Am 20.01.2014 19:35, schrieb Jonas Helming:
Hi,
for me the relavant questions are:
1. Which bundles to we want to graduate and move?
IMHO, the Application Model Editor and the e4 project wizards would be
most important and already a huge improvement of the situation. Everybody
who wants to create a native e4 applications needs this editor.
Far behind, I would consider th CSS editor, but I think it would be acceptable
to still install this one.
2. Where do we want to move it?
Until now, most people mentioned, that the e4 tools should be moved to
PDE. I personally would prefer to move them to the platform. The editor
is really closely connected to the platform, it even accesses some internal
API. The editor must also evolve in parallel to the Application Model.
Finally I think the developers of the plattform are more connected to the
tools.
3. What do we need to do to make this happen?
I think we should identify the shortest path to a good result.
- I don't think it is essential that the editor provides a public API.
Extending it is a rather advanced use cases. If people extended a non-graduated
tool in the past, I think they can live with internal API or SPI in the
future. From an API stability point of view, this does not make a difference.
- We need to check, which bundles must be moved. I am worried most about
org.eclipse.e4.tools.services, it contains parts, which are not only
used by the Application Model editor. So we might need to move some things
around.
- We need to define our goals for documentation and test coverage
Finally I do not think this will slow down the evolution of the tools.
If people want to contribute, they can still do. In turn, I think it makes
it easier and more visible to create native e4 applications.
What do you think?
Cheers
Jonas
P.S.: Doug, thanks fro pushing this forward, I think an opinion from a
user point of view is very valuable for this discussion
Am 20.01.2014 18:18, schrieb Doug Schaefer:
These tools are equals to the plugin.xml and *.product
editors. Not sure what you are getting at below. I’m pretty sure users
who need these tools really don’t get it.
Doug.
From: David M Williams <david_williams@xxxxxxxxxx>
Reply-To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Date: Monday, January 20, 2014 at 10:30 AM
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
Subject: Re: [e4-dev] e4 tools build moving to Luna?
Sorry if this is obvious to others,
but is this tool intended to be a "delivery" of the "e4/sdk"
product? In the sense it has APIs and/or could be extended? Or it is intended
for use only by "Eclipse committers" in making Eclipse IDE?
I ask since the "requirements" are quite a bit different for
the two. If simply a "releng tool" it could be provided similar
to how we deliver the "releng tools" from Platform (which provides
copyright tools, and a validator for MANIFEST and POM versions (and some
old cvs 'release' tools not used much these days). While the description
is needs improvement, I think it's pretty clear it is not intended to provide
API or be extended (therefore "compatibility", etc. is not considered
that important ... we tell people to use the same version built with their
dev. environment.
But, if meant to be extendable, and provide API, etc, then there are higher
criteria.
I should add, it would be "hard" to "build with the SDK"
because it depends on some emf components (such as emf.edit.ui?) which
is not apart of the "base" EMF we get "early" from
EMF.
Hope these comments help inform the final decision.
From: John
Arthorne <John_Arthorne@xxxxxxxxxx>
To: E4
Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date: 01/19/2014
11:11 AM
Subject: Re:
[e4-dev] e4 tools build moving to Luna?
Sent by: e4-dev-bounces@xxxxxxxxxxx
If parts of the e4 tools graduated into PDE, then all active contributors
to those tools would be granted PDE commit rights as part of the graduation/restructuring.
We did the same thing with commit rights on other parts of e4 that graduated
into the platform. So I don't think commit rights will be a problem at
all. It does of course require active committers to keep maintaining it
wherever it ends up.
John
From: Lars
Vogel <lars.vogel@xxxxxxxxx>
To: E4
Project developer mailing list <e4-dev@xxxxxxxxxxx>,
Date: 01/18/2014
05:02 AM
Subject: Re:
[e4-dev] e4 tools build moving to Luna?
Sent by: e4-dev-bounces@xxxxxxxxxxx
I personally like that we can adjust the tooling as needed. PDE seems very
inactive at the moment.
But test, better Javadoc and fixing the outstanding bugs
is good in general, no matter if the tools get officially released or not,
so no need to hold such activities of.
Best regards, Lars
Am 18.01.2014 09:40 schrieb "Wim Jongman" <wim.jongman@xxxxxxxxx>:
There are things missing in the model editor and in the tooling in general.
Most notably unit tests, javadoc and user documentation. We need to fix
these before a release can be considered.
I am also happy to join a dedicated team that tackles this. So that makes
two. Who wants to join us?
Regards,
Wim
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
