[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] e4 tools build moving to Luna?
|
Hi,
I've started the editor but the ones doing the job must say where they
want to go. I'm only contributing when I come across a miss behavior
like a few weeks ago.
If you ask me the L&F of the editor has to be rewritten to match other
editors in the platform.
My biggest wish would have been that I can make use of the LiveEditor as
well in JavaFX applications where I naturally have no SWT (well there's
my SWT => JavaFX port) but this would involve a major refactoring and a
big set of facade APIs so it will stay a pipe dream of myself ;-)
Tom
On 18.02.14 11:13, Jonas Helming wrote:
> Thanks Wim!
> Before we start to do anything,
> Tom, as you did most of the initial contribution, what is your opinion
> on this?
> Same question for Lars, as you did much of the more recent improvements?
>
> Regards
>
> Jonas
>
>
> Am 17.02.2014 21:13, schrieb Wim Jongman:
>> Filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=428375 (Adopt the
>> E4 tools Model Editor)
>>
>>
>> On Mon, Feb 17, 2014 at 5:00 PM, John Arthorne
>> <John_Arthorne@xxxxxxxxxx <mailto:John_Arthorne@xxxxxxxxxx>> wrote:
>>
>> 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
>> <mailto:jonas.helming@xxxxxxxxxxxxxx>>
>> To: e4-dev@xxxxxxxxxxx <mailto: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
>> <mailto: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_
>> <http://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@googlemail.com_
>> <mailto: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@xxxxxx.com_
>> <mailto:david_williams@xxxxxxxxxx>>*
>> Reply-To: *E4 Project developer mailing list <_e4-dev@eclipse.org_
>> <mailto:e4-dev@xxxxxxxxxxx>>*
>> Date: *Monday, January 20, 2014 at 10:30 AM*
>> To: *E4 Project developer mailing list <_e4-dev@eclipse.org_
>> <mailto: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@xxxxxx.com_
>> <mailto:John_Arthorne@xxxxxxxxxx>>
>> To: E4 Project developer mailing list <_e4-dev@eclipse.org_
>> <mailto: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@eclipse.org_
>> <mailto: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@gmail.com_
>> <mailto:lars.vogel@xxxxxxxxx>>
>> To: E4 Project developer mailing list <_e4-dev@eclipse.org_
>> <mailto: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@eclipse.org_
>> <mailto: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@gmail.com_
>> <mailto: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@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>_
>> __https://dev.eclipse.org/mailman/listinfo/e4-dev_
>> _______________________________________________
>> e4-dev mailing list_
>> __e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>_
>> __https://dev.eclipse.org/mailman/listinfo/e4-dev_
>> _______________________________________________
>> e4-dev mailing list_
>> __e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>_
>> __https://dev.eclipse.org/mailman/listinfo/e4-dev_
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> _e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>
>> _https://dev.eclipse.org/mailman/listinfo/e4-dev_
>>
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list_
>> __e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>_
>> __https://dev.eclipse.org/mailman/listinfo/e4-dev_
>>
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> _e4-dev@eclipse.org_ <mailto:e4-dev@xxxxxxxxxxx>
>> _https://dev.eclipse.org/mailman/listinfo/e4-dev_
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx <mailto:e4-dev@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx <mailto: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
>
