In general I think we can move the stuff to trunk as long as it doesn't break the build for everyone, even if the stuff is in flux and might be completely changed over time. We ahve consensus that we want to do this in the Sling project and having it in trunk gives it more visibility and the sooner other people join the effort the better. However, this means we can't use vlt in trunk unless it is in jackrabbit *and* we have a released version of it. I don't want to have a snapshot dependency to an external project. And we have to check with jackrabbit when we can expect a first release.
Carsten 2013/7/25 Antonio Sanso <asa...@adobe.com> > > On Jul 24, 2013, at 11:33 PM, Robert Munteanu wrote: > > > On Thu, Jul 25, 2013 at 12:12 AM, Antonio Sanso <asa...@adobe.com> > 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 <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 > >> > > -- Carsten Ziegeler cziege...@apache.org
