On Jul 24, 2013, at 11:33 PM, Robert Munteanu wrote: > On Thu, Jul 25, 2013 at 12:12 AM, Antonio Sanso <[email protected]> wrote: >> sorry for misunderstanding but what I really meant is : >> >> would it be impossible to have ONLY one API that is agnostic of VLT vs >> resource based? >> >> regards > > If what you mean is having three bundles > > * ide-api > * resource-impl > * vlt-impl > > and then having the eclipse plugin work with only the ide-api bundle, > not knowing what the implementations are,
yes I meant that :) regards antonio > then I think it is possible. > > Robert > >> >> antonio >> >> On Jul 24, 2013, at 10:23 PM, Robert Munteanu wrote: >> >>> On Wed, Jul 24, 2013 at 10:11 PM, Antonio Sanso <[email protected]> wrote: >>>> just taking a stab here , >>>> would it be impossible to have an API that is agnostic of VLT vs resource >>>> based? >>>> >>> >>> From a technical point of view it's possible, and that's why I tried >>> to separate things into API + implementation. >>> >>> I think that there is a concern that from a support / development >>> effort point of view it makes no sense to support two APIs at the same >>> time. On the long term we should (probably) pick one. >>> >>> But we also need to see which of those has the better IDE embedding >>> story, or at least we'll find out how to drive VLT towards better IDE >>> embeddability. >>> >>> Robert >>> >>>> regards >>>> >>>> antonio >>>> >>>> >>>> On Jul 24, 2013, at 7:54 PM, Robert Munteanu wrote: >>>> >>>>> On Wed, Jul 24, 2013 at 8:44 PM, Justin Edelson >>>>> <[email protected]> wrote: >>>>>> +1 to tooling and moving Maven stuff there. >>>>>> -0 to moving IDE out of the whiteboard until we have a consensus on a >>>>>> serialization/transport form. >>>>>> >>>>>> My understanding is that the current IDE codebase is being used to >>>>>> prototype a serialization form and transport protocol and that we will >>>>>> eventually be trying to reach consensus on using that, vlt, or something >>>>>> else. >>>>> >>>>> I've waited to propose move out of whiteboard until we had a solid >>>>> module structure which can be used to evolve the IDE stuff into what >>>>> we want it to be. >>>>> >>>>> The serialization form is more or less a draft which I'm using until >>>>> FileVault is accepted into Jackrabbit. The transport protocol is based >>>>> on the Sling HTTP Get/Post servlets, which is a de facto standard for >>>>> Sling applications, at least for those not using FileVault. >>>>> >>>>> The point here is that I don't have vlt to work with _now_ and I can >>>>> evolve the Eclipse mechanisms ( UI , servers, modules, change >>>>> detection ) - which are not trivial - without waiting for vlt. And I >>>>> can gather feedback from people brave enough to try it without waiting >>>>> for vlt. >>>>> >>>>> Once we can use VLT, we'll see what fits best. I admit that I have an >>>>> inclination towards the resource-based API, but it's not my personal >>>>> decision to make. >>>>> >>>>> Of course, I can put a hold on moving the codebase to trunk/tooling, >>>>> but that would not gain anything for now, since the codebase is in >>>>> flux anyway. >>>>> >>>>> Instead, my suggestion is not to make any sort of releases, not even >>>>> technology previews, until we have consensus on the VLT vs >>>>> Resource-based implementation. >>>>> >>>>> WDYT? >>>>> >>>>> Robert >>>>> >>>>>> >>>>>> An alternative would be to create the tooling top-level directory and >>>>>> then >>>>>> put the IDE in a branch. >>>>>> >>>>>> Justin >>>>>> >>>>>> >>>>>> On Wed, Jul 24, 2013 at 10:42 AM, Robert Munteanu <[email protected]> wrote: >>>>>> >>>>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz >>>>>>> <[email protected]> wrote: >>>>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <[email protected]> >>>>>>> wrote: >>>>>>>>> ...create a top level "tooling" (or so) folder and put the "ide" and >>>>>>> "maven" stuff in there ?... >>>>>>> >>>>>>> I've created [0] to track this move and will do that later on today - >>>>>>> lots of stuff to adjust in the poms under maven. >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> [0]: https://issues.apache.org/jira/browse/SLING-2978 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sent from my (old) computer >>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from my (old) computer >>>> >>> >>> >>> >>> -- >>> Sent from my (old) computer >>
