On Wed, Jul 24, 2013 at 10:11 PM, Antonio Sanso <asa...@adobe.com> 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 >> <jus...@justinedelson.com> 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 <rob...@lmn.ro> wrote: >>> >>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz >>>> <bdelacre...@apache.org> wrote: >>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fmesc...@adobe.com> >>>> 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
