[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pdt-dev] Ambitious composer plans

Hi Thomas,

I would bet on Sapphire. AFAIK, it was designed for XML-based descriptors (like the Java EE XML descriptors), but perhaps it evolved over the years to support also JSON-based descriptors like composer.json.Â

I would recommend that you first describe the Composer use case in the Sapphire forum and ask for guidance how to start modeling it. Most probably, it will be again Konstantin that will answer you - he is leading the Sapphire project.

Greetings,
Kaloyan

On Thu, Oct 29, 2015 at 11:20 AM, Thomas Gossmann <eclipse@xxxxxx> wrote:
Hi guys,

I send a mail to ide-dev@xxxxxxxxxxx [1] and get an answer [2]. Konstantin was so kind to point me to three eclipse projects. I roughly scanned through them.

Scout: Might not be for us, looks more like web-technics
EFF: This might be a place to contribute my code
Sapphire: This is a totally different approach and I really like it. I'd rather look into this than contributing code (I haven't tried it out yet).

Would like to get your opinions about it - maybe you even know about other alternatives.

[1] https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00885.html
[2] https://dev.eclipse.org/mhonarc/lists/ide-dev/msg00886.html

gossi

Am 09.10.15 um 11:45 schrieb Kaloyan Raev:
Hi Gossi,

Regarding this:
Â> 2. Eclipse components: That's to sort out were to put them, then port
them to e4 and put them at their desired location (whom to talk to?)

I suggest that you write to the ide-dev@xxxxxxxxxxx
<mailto:ide-dev@xxxxxxxxxxx> mailing list. Describe what you have in
your project and ask which Eclipse project is the best target for
contribution.

Greetings,
Kaloyan

On Fri, Oct 9, 2015 at 12:35 PM, Thomas Gossmann <eclipse@xxxxxx
<mailto:eclipse@xxxxxx>> wrote:

  Guys,

  I need to catch up on a couple of things here, I guess:

  1) A plan sounds great. This would require a greater strategy than
  we thought at first (see below).

  2) PEX Composer + Zend Composer = PDT Composer:
  I love this merge. I can only judge Zend Composer from screenshots,
  so I think from the UI perspective and with composer java bindings,
  this is were PEX composer shines, when it comes to provide APIs to
  other tools, there is nothing PEX composer can offer, so the zend
  composer APIs would be a great addition (I just assume there are
  some, based on what Michal said).

  3) Dependencies:
  There are a lot of dependencies involved, though not all of them
  need to be reused as there might be newer alternatives available.
  I'll quickly go through them for PEX composer (I summarize them as
  "The Challenges" in my blog post):
  - Composer Java Bindings: They were mainly written by me, however
  they depend on "json-simple", both of them needs to be made
  available to eclipse - that's where you guys know how to do that.
  Maybe it also makes sense to include the bindings into eclipse as well.
  - JSON-Editor: Using the new json editor for wtp is the way to go
  here (see my planning below)
  - Eclipse elements/widgets: That's what I extracted from the
  PDE-Editor and reused it first in the composer plugin and then
  extracted it into its own lib:
  https://github.com/gossi/eclipse-components which should be ported
  to e4 and then made available to eclipse
  - Running CLI-Tools: That's a very tricky part and I explained a lot
  about this in the blog post. As this is not only a task for composer
  but also for npm/bower/all the other cli tools you use nowadays you
  might run from eclipse. We should reach out and create a solid API
  within the WTP or DLTK? E.g. the npm/bower editor might also have a
  similar editor to composer someday, with install/update actions on top.

  4) Planning:
  (I need to make a personal note here: I am currently taking my final
  university exams (one more to go) and afterwards will be working for
  6 months on my thesis as you can imagine I won't be of that much
  help during that time)
  Nevertheless, the code for the composer related stuff is ready to
  port, yet it's about the dependencies. The first step would be to
  sort this out and work on them first.

  A) Dependencies:
  1. JSON-Editor will be around for neon. We are in no time pressure
  or hurry, I expect the other dependencies to be ready at this time
  as well.
  2. Eclipse components: That's to sort out were to put them, then
  port them to e4 and put them at their desired location (whom to talk
  to?)
  3. Cli-Tools: Reach out for the npm/bower guys, talk with them and
  work on the foundation for that.
  4. Manage all IP/CQ, whatever needs to be done.

  Dependencies should be ready and shipped with neon.

  B) Composer:
  Now that everything is sorted out, the composer codebases can be
  merged into PDT, creating nice APIs, etc.


  PS. Maybe create a wiki page with a plan and items that are todo?

  gossi

  Am 09.10.15 um 08:59 schrieb MichaÅ NiewrzaÅ:

      ÂMaybe we should resurrect pdt.incubator ?


    +1

      ÂBTW, I also think that at least two most active commiters
    should be
      Âinvited to PDT team.


    Sounds good to me.

    Greetings,
    Michal

    On Wed, Oct 7, 2015 at 5:47 PM, Dawid PakuÅa <zulus@xxxxxxxxx
    <mailto:zulus@xxxxxxxxx>
    <mailto:zulus@xxxxxxxxx <mailto:zulus@xxxxxxxxx>>> wrote:

      ÂHi,

      ÂPlan looks good. Gossi?
      ÂProblem are not library dependencies. Composer plugin use
    code from
      Âother projects:
      Â1. Provide metadata for class/interface wizard, so probably
    should
      Âbe moved to PDT
      Â2. Require E4, fortunately we decide to keep api
    compatibility with
      Âprevious eclipse release only
      Â3. Use JSON editor from outside eclipse, JSON-WTP is still
    in CQ phase
      Â4. Is based on Robert Composer Java Bindings. This library
    probably
      Âalso should be moved to PDT and released in eclipse maven
    repository.

      ÂMaybe we should resurrect pdt.incubator ?

      ÂBTW, I also think that at least two most active commiters
    should be
      Âinvited to PDT team.

      Â--
      ÂDawid PakuÅa
    +48 795 996 064 <tel:%2B48%20795%20996%20064>
    <tel:%2B48%20795%20996%20064>

      ÂOn 7 October 2015 at 08:12:15, Kaloyan Raev
    (kaloyan.r@xxxxxxxx <mailto:kaloyan.r@xxxxxxxx>
      Â<mailto:kaloyan.r@xxxxxxxx <mailto:kaloyan.r@xxxxxxxx>>) wrote:

        ÂHi,

        ÂI think we need to build a plan and start executing it.
      How about
        Âthis:

        Â1. Open CQs with code contributions to PDT. This may be
      quite a
        Âheavy step. As far as I understand, the PEX Composer
      has a lot of
        Âdependencies. We need to clarify what gets contributed
      to PDT and
        Âwhat is removed as dependency. We (Zend) can also
      contribute via
        ÂCQ our Composer plugin from Zend Studio. Once we have
      the code of
        Âboth PEX and Zend Composer plugins under EPL and
      IP-verified we
        Âcan start thinking how to merge them in the ultimate
      PDT Composer
        Âplugin.

        Â2. Agree and implement a common Core API part for both PEX
        ÂComposer and Zend Composer plugins. The goal is that we
      have all
        Âplugins depending on Composer (like the Symfony plugin
      from PEX
        Âand the Apigility plugin from Zend Studio) to use a common
        ÂComposer Core API.

        Â3. Start merging the UI.

        ÂWhat do you think?

        ÂKaloyan

        ÂOn Tue, Oct 6, 2015 at 5:37 PM, Dawid PakuÅa
      <zulus@xxxxxxxxx <mailto:zulus@xxxxxxxxx>
        Â<mailto:zulus@xxxxxxxxx <mailto:zulus@xxxxxxxxx>>> wrote:

          ÂHi,

          ÂI want refresh this topic because we are in post 3.6.

           Would be good to start IP cleanup process.
          Â--
          ÂDawid PakuÅa
      +48 795 996 064 <tel:%2B48%20795%20996%20064>
      <tel:%2B48%20795%20996%20064>

          ÂOn 22 September 2015 at 15:02:26, Dawid PakuÅa
          Â(zulus@xxxxxxxxx <mailto:zulus@xxxxxxxxx>
      <mailto:zulus@xxxxxxxxx <mailto:zulus@xxxxxxxxx>>) wrote:

            ÂHI,

            ÂThanks for that!

            ÂTwo comment from me for now:
            Â1. JSON: On JSDT gerrit pending WTP-based JSON
        editor [1][2]
            ÂI hope it will be merged in Neon (together with
        bower support)
            Â2. Namespace support: I opened bug to add class
        loader
            Âmetadata into build path [3]. Composer / puli
        or any other
            Âplugin can provide such information.

            Â[1] -
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=471820
            Â[2] - https://git.eclipse.org/r/#/c/51516/
            Â[3] -
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=472758

            Â--
            ÂDawid PakuÅa
        +48 795 996 064 <tel:%2B48%20795%20996%20064>
        <tel:%2B48%20795%20996%20064>

            ÂOn 22 September 2015 at 14:50:02, Thomas Gossmann
            Â(eclipse@xxxxxx <mailto:eclipse@xxxxxx>
        <mailto:eclipse@xxxxxx <mailto:eclipse@xxxxxx>>) wrote:

              ÂHey guys,

              ÂI write a blog post about the composer
          plans [1] that Robert
              Âand me
              Âdiscovered when we initially created the
          plugin and also
              Âtalks about
              Âmerging this into PDT. So, despite having
          the idea of
              Âmerging composer
              Âinto PDT, it is much more interessting to
          get the original
              Âidea of the
              Âcomposer plugin. Especially since it has a
          lot potential for
              ÂPDT.

              ÂI unfortunately had to cancel the GSOC
          project even before
              Âit was
              Âsubmitted. Yet next summer still may be an
          opportunity for this
              Â(depending on how fast I finish).

              ÂNevertheless, merging composer into PDT is
          a huge effort and
              Âthere are a
              Âlot of challenges ahead (which I address in
          my post). It is
              Âalso way
              Âmore than just refactoring the appropriate
          package names. I
              Âassume the
              Âworkload for one person to be 3 month
          (likely higher).

              ÂThis thread should be used to think about
          the options we
              Âhave, what
              Âneeds to be prepared (and how) and probably
          create a
              Âstrategy merging this.

              Â[1]
          http://gos.si/blog/pdt-and-composer-a-visionary-concept

              Âgossi
              Â_______________________________________________
              Âpdt-dev mailing list
          pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
          <mailto:pdt-dev@xxxxxxxxxxx
          <mailto:pdt-dev@xxxxxxxxxxx>>
              ÂTo change your delivery options, retrieve
          your password, or
              Âunsubscribe from this list, visit
          https://dev.eclipse.org/mailman/listinfo/pdt-dev


          Â_______________________________________________
          Âpdt-dev mailing list
      pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
      <mailto:pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>>
          ÂTo change your delivery options, retrieve your
      password, or
          Âunsubscribe from this list, visit
      https://dev.eclipse.org/mailman/listinfo/pdt-dev


        Â_______________________________________________
        Âpdt-dev mailing list
      pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
      <mailto:pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>>
        ÂTo change your delivery options, retrieve your password, or
        Âunsubscribe from this list, visit
      https://dev.eclipse.org/mailman/listinfo/pdt-dev


      Â_______________________________________________
      Âpdt-dev mailing list
    pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
    <mailto:pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>>

      ÂTo change your delivery options, retrieve your password, or
      Âunsubscribe from this list, visit
    https://dev.eclipse.org/mailman/listinfo/pdt-dev




    _______________________________________________
    pdt-dev mailing list
    pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit
    https://dev.eclipse.org/mailman/listinfo/pdt-dev

  _______________________________________________
  pdt-dev mailing list
  pdt-dev@xxxxxxxxxxx <mailto:pdt-dev@xxxxxxxxxxx>
  To change your delivery options, retrieve your password, or
  unsubscribe from this list, visit
  https://dev.eclipse.org/mailman/listinfo/pdt-dev




_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev

_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/pdt-dev