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 <[email protected]
> 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 <[email protected]>
> Reply-To: E4 Project developer mailing list <[email protected]>
> Date: Monday, January 20, 2014 at 10:30 AM
> To: E4 Project developer mailing list <[email protected]>
> 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 <[email protected]>
> To:        E4 Project developer mailing list <[email protected]>,
> Date:        01/19/2014 11:11 AM
> Subject:        Re: [e4-dev] e4 tools build moving to Luna?
> Sent by:        [email protected]
> ------------------------------
>
>
>
> 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 <[email protected]>
> To:        E4 Project developer mailing list <[email protected]>,
> Date:        01/18/2014 05:02 AM
> Subject:        Re: [e4-dev] e4 tools build moving to Luna?
> Sent by:        [email protected]
>  ------------------------------
>
>
>
> 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" 
> <*[email protected]*<[email protected]>>:
>
> 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
> *[email protected]* <[email protected]>
> *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing 
> [email protected]https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to