You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2013/07/24 15:53:53 UTC
[ide] Moving the IDE tools to contrib
Hi,
The 'Sling IDE tools' ( née Slingclipse ) have been restructured ( see
[1] ) and are now ready to get more attention from a development point
of view.
I'd like to propose moving them from Antonio's whiteboard [2] to the
contrib directory, at contrib/ide . Since they are a bit different
from the regular bundle/test builds, they should be excluded from the
contrib reactor build and built independently if needed.
I think they should also get a Jira component and a separate Jenkins job.
Thoughts?
Robert
[1]: https://issues.apache.org/jira/browse/SLING-2973
[2]: http://svn.apache.org/repos/asf/sling/whiteboard/asanso/plugins/eclipse/
Re: [ide] Moving the IDE tools to contrib
Posted by Antonio Sanso <as...@adobe.com>.
+1
On Jul 24, 2013, at 3:53 PM, Robert Munteanu wrote:
> Hi,
>
> The 'Sling IDE tools' ( née Slingclipse ) have been restructured ( see
> [1] ) and are now ready to get more attention from a development point
> of view.
>
> I'd like to propose moving them from Antonio's whiteboard [2] to the
> contrib directory, at contrib/ide . Since they are a bit different
> from the regular bundle/test builds, they should be excluded from the
> contrib reactor build and built independently if needed.
>
> I think they should also get a Jira component and a separate Jenkins job.
>
> Thoughts?
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/SLING-2973
> [2]: http://svn.apache.org/repos/asf/sling/whiteboard/asanso/plugins/eclipse/
Re: [ide] Moving the IDE tools to contrib
Posted by Ian Boston <ie...@tfd.co.uk>.
+1, also, for tooling.
Ian
On 24 July 2013 15:11, Carsten Ziegeler <cz...@apache.org> wrote:
> +1 for tooling
>
>
> 2013/7/24 Felix Meschberger <fm...@adobe.com>
>
> > Hi
> >
> > I think we should put them in their own top level folder -- e.g. ide ?
> >
> > or even create a top level "tooling" (or so) folder and put the "ide" and
> > "maven" stuff in there ?
> >
> > I would not put them into contrib because that is just "bundles" with a
> > different release policy.
> >
> > Regards
> > Felix
> >
> > Am 24.07.2013 um 15:53 schrieb Robert Munteanu:
> >
> > > Hi,
> > >
> > > The 'Sling IDE tools' ( née Slingclipse ) have been restructured ( see
> > > [1] ) and are now ready to get more attention from a development point
> > > of view.
> > >
> > > I'd like to propose moving them from Antonio's whiteboard [2] to the
> > > contrib directory, at contrib/ide . Since they are a bit different
> > > from the regular bundle/test builds, they should be excluded from the
> > > contrib reactor build and built independently if needed.
> > >
> > > I think they should also get a Jira component and a separate Jenkins
> job.
> > >
> > > Thoughts?
> > >
> > > Robert
> > >
> > >
> > > [1]: https://issues.apache.org/jira/browse/SLING-2973
> > > [2]:
> > http://svn.apache.org/repos/asf/sling/whiteboard/asanso/plugins/eclipse/
> >
> >
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: [ide] Moving the IDE tools to contrib
Posted by Carsten Ziegeler <cz...@apache.org>.
+1 for tooling
2013/7/24 Felix Meschberger <fm...@adobe.com>
> Hi
>
> I think we should put them in their own top level folder -- e.g. ide ?
>
> or even create a top level "tooling" (or so) folder and put the "ide" and
> "maven" stuff in there ?
>
> I would not put them into contrib because that is just "bundles" with a
> different release policy.
>
> Regards
> Felix
>
> Am 24.07.2013 um 15:53 schrieb Robert Munteanu:
>
> > Hi,
> >
> > The 'Sling IDE tools' ( née Slingclipse ) have been restructured ( see
> > [1] ) and are now ready to get more attention from a development point
> > of view.
> >
> > I'd like to propose moving them from Antonio's whiteboard [2] to the
> > contrib directory, at contrib/ide . Since they are a bit different
> > from the regular bundle/test builds, they should be excluded from the
> > contrib reactor build and built independently if needed.
> >
> > I think they should also get a Jira component and a separate Jenkins job.
> >
> > Thoughts?
> >
> > Robert
> >
> >
> > [1]: https://issues.apache.org/jira/browse/SLING-2973
> > [2]:
> http://svn.apache.org/repos/asf/sling/whiteboard/asanso/plugins/eclipse/
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [ide] VLT vs Resource-based (was: [ide] Moving the IDE tools to contrib)
Posted by Carsten Ziegeler <cz...@apache.org>.
I completely agree - and I hope that we soon have a VLT release as this is
currently blocking if we go the VLT way.
Carsten
2013/7/25 Stefan Egli <eg...@adobe.com>
> Hi,
>
> On 7/24/13 11:42 PM, "Justin Edelson" <ju...@justinedelson.com> wrote:
>
> >
> >On Wed, Jul 24, 2013 at 1:54 PM, Robert Munteanu <ro...@lmn.ro> wrote:
> >
> >>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.
> >>
> >
> >I think to make an apples-to-apples comparison, the packaging format and
> >installaion services will also need to be at least defined (better yet
> >would be to have prototypes available). I thought that was the outcome of
> >the prior thread we had on this subject. As I said at that point, the
> >advantage of leveraging VLT is that the existing packaging tool ecosystem
> >would not need to be recreated.
>
>
> Seems still to be a hot topic - VLT vs Resource-based. And I think we
> should soon get to a decision on this. I think the decision which one to
> choose is not only related to how well it fits into the IDE, but also
> related to the impact on the overall picture. Especially given that there
> is quite some existing packaging ecosystem around, as Justin mentioned. So
> IMHO if the tooling chooses to go another direction than VLT, that either
> means that the packaging ecosystem should switch as well - or it ends up
> not being used by many people.
>
> For the short term I dont see a problem having the possibility to play
> with both - but I think we are in some sort of agreement that in the end
> result there should only be one way.
>
> Cheers,
> Stefan
>
>
--
Carsten Ziegeler
cziegeler@apache.org
[ide] VLT vs Resource-based (was: [ide] Moving the IDE tools to
contrib)
Posted by Stefan Egli <eg...@adobe.com>.
Hi,
On 7/24/13 11:42 PM, "Justin Edelson" <ju...@justinedelson.com> wrote:
>
>On Wed, Jul 24, 2013 at 1:54 PM, Robert Munteanu <ro...@lmn.ro> wrote:
>
>>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.
>>
>
>I think to make an apples-to-apples comparison, the packaging format and
>installaion services will also need to be at least defined (better yet
>would be to have prototypes available). I thought that was the outcome of
>the prior thread we had on this subject. As I said at that point, the
>advantage of leveraging VLT is that the existing packaging tool ecosystem
>would not need to be recreated.
Seems still to be a hot topic - VLT vs Resource-based. And I think we
should soon get to a decision on this. I think the decision which one to
choose is not only related to how well it fits into the IDE, but also
related to the impact on the overall picture. Especially given that there
is quite some existing packaging ecosystem around, as Justin mentioned. So
IMHO if the tooling chooses to go another direction than VLT, that either
means that the packaging ecosystem should switch as well - or it ends up
not being used by many people.
For the short term I dont see a problem having the possibility to play
with both - but I think we are in some sort of agreement that in the end
result there should only be one way.
Cheers,
Stefan
Re: [ide] Moving the IDE tools to contrib
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi Robert,
On Wed, Jul 24, 2013 at 1:54 PM, Robert Munteanu <ro...@lmn.ro> wrote:
> On Wed, Jul 24, 2013 at 8:44 PM, Justin Edelson
> <ju...@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.
>
Can't you do all of that in a whiteboard or branch?
>
> 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.
>
I think to make an apples-to-apples comparison, the packaging format and
installaion services will also need to be at least defined (better yet
would be to have prototypes available). I thought that was the outcome of
the prior thread we had on this subject. As I said at that point, the
advantage of leveraging VLT is that the existing packaging tool ecosystem
would not need to be recreated.
>
> 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.
>
I guess I just don't see the driver to move anything. But I'm not going to
veto such a move.
Justin
>
> 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 <ro...@lmn.ro> wrote:
> >
> >> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
> >> <bd...@apache.org> wrote:
> >> > On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <
> fmeschbe@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
>
Re: [ide] Moving the IDE tools to contrib
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <as...@adobe.com>
>
> On Jul 24, 2013, at 11:33 PM, Robert Munteanu wrote:
>
> > On Thu, Jul 25, 2013 at 12:12 AM, Antonio Sanso <as...@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 <as...@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
> >>>>> <ju...@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 <ro...@lmn.ro>
> wrote:
> >>>>>>
> >>>>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
> >>>>>>> <bd...@apache.org> wrote:
> >>>>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <
> fmeschbe@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
cziegeler@apache.org
Re: [ide] Moving the IDE tools to contrib
Posted by Antonio Sanso <as...@adobe.com>.
On Jul 24, 2013, at 11:33 PM, Robert Munteanu wrote:
> On Thu, Jul 25, 2013 at 12:12 AM, Antonio Sanso <as...@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 <as...@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
>>>>> <ju...@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 <ro...@lmn.ro> wrote:
>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>>>>>>> <bd...@apache.org> wrote:
>>>>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
>>
Re: [ide] Moving the IDE tools to contrib
Posted by Robert Munteanu <ro...@apache.org>.
On Thu, Jul 25, 2013 at 12:12 AM, Antonio Sanso <as...@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, 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 <as...@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
>>>> <ju...@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 <ro...@lmn.ro> wrote:
>>>>>
>>>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>>>>>> <bd...@apache.org> wrote:
>>>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
>
Re: [ide] Moving the IDE tools to contrib
Posted by Antonio Sanso <as...@adobe.com>.
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
antonio
On Jul 24, 2013, at 10:23 PM, Robert Munteanu wrote:
> On Wed, Jul 24, 2013 at 10:11 PM, Antonio Sanso <as...@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
>>> <ju...@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 <ro...@lmn.ro> wrote:
>>>>
>>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>>>>> <bd...@apache.org> wrote:
>>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Robert Munteanu <ro...@lmn.ro>.
On Wed, Jul 24, 2013 at 10:11 PM, Antonio Sanso <as...@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
>> <ju...@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 <ro...@lmn.ro> wrote:
>>>
>>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>>>> <bd...@apache.org> wrote:
>>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Antonio Sanso <as...@adobe.com>.
just taking a stab here ,
would it be impossible to have an API that is agnostic of VLT vs resource based?
regards
antonio
On Jul 24, 2013, at 7:54 PM, Robert Munteanu wrote:
> On Wed, Jul 24, 2013 at 8:44 PM, Justin Edelson
> <ju...@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 <ro...@lmn.ro> wrote:
>>
>>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>>> <bd...@apache.org> wrote:
>>>> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Robert Munteanu <ro...@lmn.ro>.
On Wed, Jul 24, 2013 at 8:44 PM, Justin Edelson
<ju...@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 <ro...@lmn.ro> wrote:
>
>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> > On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Justin Edelson <ju...@justinedelson.com>.
+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.
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 <ro...@lmn.ro> wrote:
> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
>
Re: [ide] Moving the IDE tools to contrib
Posted by Robert Munteanu <ro...@lmn.ro>.
Given the discussions, I've moved the codebase from the whiteboard to
tooling/ide. I've created a Sling job at
https://builds.apache.org/view/S-Z/view/Sling/job/sling-ide-1.6/ and
also applied exclusions for tooling/ide when building the
sling-trunk-{1.6,1.7} jobs.
The tooling/ide reactor is not yet part of the default reactor. It's a
good question whether it should be – or rather whether the whole
tooling directory should be part of the default reactor. But that's
another topic.
For now, it builds separately and I'll follow up on different Jira
issues/discussions for incremental improvements.
BTW, should we have a Jira component for it or keep using 'Extensions'
like we did so far?
Thanks,
Robert
On Wed, Jul 24, 2013 at 6:49 PM, Daniel Klco <da...@gmail.com> wrote:
> +1
>
>
> On Wed, Jul 24, 2013 at 10:42 AM, Robert Munteanu <ro...@lmn.ro> wrote:
>
>> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> > On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Daniel Klco <da...@gmail.com>.
+1
On Wed, Jul 24, 2013 at 10:42 AM, Robert Munteanu <ro...@lmn.ro> wrote:
> On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
>
Re: [ide] Moving the IDE tools to contrib
Posted by Robert Munteanu <ro...@lmn.ro>.
On Wed, Jul 24, 2013 at 5:15 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@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
Re: [ide] Moving the IDE tools to contrib
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 24, 2013 at 4:02 PM, Felix Meschberger <fm...@adobe.com> wrote:
> ...create a top level "tooling" (or so) folder and put the "ide" and "maven" stuff in there ?...
+1
-Bertrand
Re: [ide] Moving the IDE tools to contrib
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
I think we should put them in their own top level folder -- e.g. ide ?
or even create a top level "tooling" (or so) folder and put the "ide" and "maven" stuff in there ?
I would not put them into contrib because that is just "bundles" with a different release policy.
Regards
Felix
Am 24.07.2013 um 15:53 schrieb Robert Munteanu:
> Hi,
>
> The 'Sling IDE tools' ( née Slingclipse ) have been restructured ( see
> [1] ) and are now ready to get more attention from a development point
> of view.
>
> I'd like to propose moving them from Antonio's whiteboard [2] to the
> contrib directory, at contrib/ide . Since they are a bit different
> from the regular bundle/test builds, they should be excluded from the
> contrib reactor build and built independently if needed.
>
> I think they should also get a Jira component and a separate Jenkins job.
>
> Thoughts?
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/SLING-2973
> [2]: http://svn.apache.org/repos/asf/sling/whiteboard/asanso/plugins/eclipse/