| 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. 
 
 
            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
 
 
 |