You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Xavier Hanin <xa...@gmail.com> on 2008/07/11 10:26:17 UTC
Extracting common ide features from IvyDE
Hi,
As you may already know I'm currently working on Ivybeans [1], a kind of
IvyDE for Netbeans for which we have won a grant from Sun [2].
In this plugin I need to implement features very similar to what has been
done in IvyDE, like code completion for Ivy files. I also need to implement
some features which are not currently supported by IvyDE like settings files
code completion, or a way to easily add dependencies to an existing Ivy
file.
These features are somewhat IDE agnostic (or at least can be based on common
roots), and I think it would benefit both community and all users if we
shared what can be shared. So I consider refactoring some code in IvyDE
(especially code used for code completion) to make it reusable (actually
I've already done the refactoring...). I'd move this code to a
org.apache.ivyde.common package, which could be used by any IDE plugin
developer. The next step would be to move this package in a separate module,
so that other plugin developers can use it without embedding the whole
eclipse plugin. Then I could add new features to this common package, which
would ease the reuse of work I do for Netbeans plugin in eclipse plugin.
So, do you think it makes sense to do that? Any objection?
Xavier
[1] http://code.google.com/p/ivybeans/
[2] http://www.netbeans.org/grant/
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Extracting common ide features from IvyDE
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le jeudi 24 juillet 2008, Xavier Hanin a écrit :
> On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalevée
> <ni...@hibnet.org>
>
> wrote:
> > [...]
> >
> >
> > The main problem IMO
> >
> >> is that it would then have the same release cycles, whilst the evolution
> >> needs may be very different.
> >
> > I don't now really what would be the new features of common.ide. But as
> > you are wondering about it, it probably means that you expect some new
> > features brought by IvyBeans ;).
>
> For IvyBeans it's not the problem since I'm a committer on IvyDE too, I can
> do pretty much what I want (and yes I have some new feature, well, at least
> one, settings code completion). But if in the future people want to use
> IvyDE commons in another plugin (let's say IDEA) and want to improve
> something they will need to go through the "provide patch" line. Not that
> much a problem but I think in the case of a small library reused by several
> plugins it can slow down development.
>
> >>> So I am in favor in integrating that common.ide in Ivy. Then I would
> >>> prefer
> >>> keeping it in IvyDE. And last have a new project with its own release
> >>> cycle.
> >>
> >> I think I prefer to either put it in IvyDE, or really split it as a
> >> separate
> >> project. Maybe even a project hosted somewhere else. After all ASF is
> >> not against having dependencies on Apache licensed libraries which are
> >> not from
> >> the ASF. The advantage I see with hosting it elsewhere is that it would
> >> be much easier to have people using the library in any plugin become a
> >> committer on the library.
> >
> > I have to admit that I don't "like" having some new external
> > dependencies. But I have no strong argument to show :p
> >
> > So my order of preferences is kept inside IvyDE, then having it in
> > another project.
> >
> > And what about common.ide included in IvyDE's release cycle, and having
> > an independent build ?
> > It would be an new project org.apache.ivy.common.ide under the trunk
> > directory of IvyDE. Used by IvyDE it would be just another plugin it
> > depends on. But it would have a standalone build.xml that you can build
> > yourself the jar, and then import that jar into IvyBeans, just like Solr
> > does with Lucene
> > (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/).
> > And that component would have it own Change.txt, as it could have somehow
> > independent features.
>
> That sounds like the easiest thing to setup for now, so I'm ok to go this
> way, then later we may decide to move the project out if we see that
> there's a real need from the community.
sounds good
>
> So I'll proceed with thesee changes in the coming days, unless you (or
> someone else) object before.
please do.
cheers,
Nicolas
>
> Xavier
>
> > NIcolas
> >
> >>> Just my feelings, I won't put any veto there.
> >>>
> >>> Nicolas
> >>>
> >>>> Xavier
> >>>>
> >>>> I'd move this code to a
> >>>>
> >>>>>> org.apache.ivyde.common package, which could be used by any IDE
> >>>>>
> >>>>> plugin
> >>>>
> >>>> developer. The next step would be to move this package in a separate
> >>>>
> >>>>>> module, so that other plugin developers can use it without embedding
> >>>>>> the whole eclipse plugin. Then I could add new features to this
> >>>>>
> >>>>> common
> >>>>>
> >>>>>
> >>>>> package,
> >>>>>
> >>>>> which would ease the reuse of work I do for Netbeans plugin in
> >>>>>
> >>>>> eclipse
> >>>>
> >>>> plugin.
> >>>>
> >>>>>> So, do you think it makes sense to do that? Any objection?
> >>>>>
> >>>>> No objection on the idea of sharing common code. The question is then
> >>>>> how.
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >>>>> For additional commands, e-mail: dev-help@ant.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >>> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >> --
> >> Xavier Hanin - Independent Java Consultant
> >> http://xhab.blogspot.com/
> >> http://ant.apache.org/ivy/
> >> http://www.xoocode.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Extracting common ide features from IvyDE
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalevée <ni...@hibnet.org>
wrote:
>
> [...]
>
>
> The main problem IMO
>> is that it would then have the same release cycles, whilst the evolution
>> needs may be very different.
>>
>
> I don't now really what would be the new features of common.ide. But as you
> are wondering about it, it probably means that you expect some new features
> brought by IvyBeans ;).
For IvyBeans it's not the problem since I'm a committer on IvyDE too, I can
do pretty much what I want (and yes I have some new feature, well, at least
one, settings code completion). But if in the future people want to use
IvyDE commons in another plugin (let's say IDEA) and want to improve
something they will need to go through the "provide patch" line. Not that
much a problem but I think in the case of a small library reused by several
plugins it can slow down development.
>
>
>
>>
>>
>>
>>> So I am in favor in integrating that common.ide in Ivy. Then I would
>>> prefer
>>> keeping it in IvyDE. And last have a new project with its own release
>>> cycle.
>>>
>>
>> I think I prefer to either put it in IvyDE, or really split it as a
>> separate
>> project. Maybe even a project hosted somewhere else. After all ASF is not
>> against having dependencies on Apache licensed libraries which are not
>> from
>> the ASF. The advantage I see with hosting it elsewhere is that it would be
>> much easier to have people using the library in any plugin become a
>> committer on the library.
>>
>
> I have to admit that I don't "like" having some new external dependencies.
> But I have no strong argument to show :p
>
> So my order of preferences is kept inside IvyDE, then having it in another
> project.
>
> And what about common.ide included in IvyDE's release cycle, and having an
> independent build ?
> It would be an new project org.apache.ivy.common.ide under the trunk
> directory of IvyDE. Used by IvyDE it would be just another plugin it depends
> on. But it would have a standalone build.xml that you can build yourself the
> jar, and then import that jar into IvyBeans, just like Solr does with Lucene
> (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/). And
> that component would have it own Change.txt, as it could have somehow
> independent features.
That sounds like the easiest thing to setup for now, so I'm ok to go this
way, then later we may decide to move the project out if we see that there's
a real need from the community.
So I'll proceed with thesee changes in the coming days, unless you (or
someone else) object before.
Xavier
>
>
> NIcolas
>
>
>
>
>>
>>>
>>> Just my feelings, I won't put any veto there.
>>>
>>> Nicolas
>>>
>>>
>>>> Xavier
>>>>
>>>> I'd move this code to a
>>>>>> org.apache.ivyde.common package, which could be used by any IDE
>>>>>>
>>>>> plugin
>>>
>>>> developer. The next step would be to move this package in a separate
>>>>>> module, so that other plugin developers can use it without embedding
>>>>>> the whole eclipse plugin. Then I could add new features to this
>>>>>>
>>>>> common
>>>
>>>>
>>>>> package,
>>>>>
>>>>> which would ease the reuse of work I do for Netbeans plugin in
>>>>>>
>>>>> eclipse
>>>
>>>> plugin.
>>>>>>
>>>>>> So, do you think it makes sense to do that? Any objection?
>>>>>>
>>>>>
>>>>> No objection on the idea of sharing common code. The question is then
>>>>> how.
>>>>>
>>>>> Nicolas
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>> For additional commands, e-mail: dev-help@ant.apache.org
>>>
>>>
>>>
>>
>> --
>> Xavier Hanin - Independent Java Consultant
>> http://xhab.blogspot.com/
>> http://ant.apache.org/ivy/
>> http://www.xoocode.org/
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Extracting common ide features from IvyDE
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 23 juil. 08 à 19:58, Xavier Hanin a écrit :
> On Wed, Jul 23, 2008 at 5:52 PM, Nicolas Lalevée <nicolas.lalevee@hibnet.org
> >
> wrote:
>
>> Le lundi 14 juillet 2008, Xavier Hanin a écrit :
>>> On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
>>> <ni...@hibnet.org>
>>>
>>> wrote:
>>>> Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
>>>>> Hi,
>>>>>
>>>>> As you may already know I'm currently working on Ivybeans [1], a
>>>>> kind
>>>>> of IvyDE for Netbeans for which we have won a grant from Sun [2].
>>>>>
>>>>> In this plugin I need to implement features very similar to what
>>>>> has
>>>>> been done in IvyDE, like code completion for Ivy files. I also
>>>>> need
>> to
>>>>
>>>> implement
>>>>
>>>>> some features which are not currently supported by IvyDE like
>> settings
>>>>> files code completion, or a way to easily add dependencies to an
>>>>> existing Ivy file.
>>>>>
>>>>> These features are somewhat IDE agnostic (or at least can be
>>>>> based on
>>>>> common roots), and I think it would benefit both community and all
>>>>> users
>>>>
>>>> if
>>>>
>>>>> we shared what can be shared. So I consider refactoring some
>>>>> code in
>>>>
>>>> IvyDE
>>>>
>>>>> (especially code used for code completion) to make it reusable
>>>>> (actually I've already done the refactoring...).
>>>>
>>>> Can I have a look to that new package ?
>>>> In fact I was asking myself if a such refactoring could be
>>>> integrated
>>>> into Ivy.
>>>
>>> Sure, for the moment I've commited the code to IvyBeans:
>>>
>> http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src
>>> /org/apache/ivyde/common/
>>>
>>> Obviously the eclipse specific bits are missing from there, but you
>> should
>>> get the idea pretty easily.
>>
>> got it.
>> So yes there are code that would be great to share.
>>
>> Then I am wondering: should it have its own release cycle, or
>> included in
>> Ivy of IvyDE's ones ?
>
> That's a good question. I think it would deserve its own release
> cycle, to
> avoid making any IDE plugin developed on this basis too tied to
> release
> cycle of either Ivy or IvyDE.
>
>>
>> Having it own release cycle, it brings more release work,
>
> Indeed.
>
>
>> and more
>> dependency handling (on IvyDE part).
>
> Yes, but I think it shouldn't be a show stopper.
>
>>
>> Having it included in IvyDE seems to be overkill compared to the
>> need of
>> Ivybeans.
>
> Agreed.
>
>>
>> Then there is the inclusion in Ivy: would it make sense to have
>> some code
>> completion algorithm on Ivy ? I don't think it would hurt.
>
> It wouldn't hurt too much, even though I think ivy.jar is already big
> enough, and we should start trying to watch its size.
Yep the more code there is the more maintenance it needs.
> The main problem IMO
> is that it would then have the same release cycles, whilst the
> evolution
> needs may be very different.
I don't now really what would be the new features of common.ide. But
as you are wondering about it, it probably means that you expect some
new features brought by IvyBeans ;).
>
>
>
>>
>> So I am in favor in integrating that common.ide in Ivy. Then I
>> would prefer
>> keeping it in IvyDE. And last have a new project with its own release
>> cycle.
>
> I think I prefer to either put it in IvyDE, or really split it as a
> separate
> project. Maybe even a project hosted somewhere else. After all ASF
> is not
> against having dependencies on Apache licensed libraries which are
> not from
> the ASF. The advantage I see with hosting it elsewhere is that it
> would be
> much easier to have people using the library in any plugin become a
> committer on the library.
I have to admit that I don't "like" having some new external
dependencies. But I have no strong argument to show :p
So my order of preferences is kept inside IvyDE, then having it in
another project.
And what about common.ide included in IvyDE's release cycle, and
having an independent build ?
It would be an new project org.apache.ivy.common.ide under the trunk
directory of IvyDE. Used by IvyDE it would be just another plugin it
depends on. But it would have a standalone build.xml that you can
build yourself the jar, and then import that jar into IvyBeans, just
like Solr does with Lucene (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/
). And that component would have it own Change.txt, as it could have
somehow independent features.
NIcolas
>
>>
>>
>> Just my feelings, I won't put any veto there.
>>
>> Nicolas
>>
>>>
>>> Xavier
>>>
>>>>> I'd move this code to a
>>>>> org.apache.ivyde.common package, which could be used by any IDE
>> plugin
>>>>> developer. The next step would be to move this package in a
>>>>> separate
>>>>> module, so that other plugin developers can use it without
>>>>> embedding
>>>>> the whole eclipse plugin. Then I could add new features to this
>> common
>>>>
>>>> package,
>>>>
>>>>> which would ease the reuse of work I do for Netbeans plugin in
>> eclipse
>>>>> plugin.
>>>>>
>>>>> So, do you think it makes sense to do that? Any objection?
>>>>
>>>> No objection on the idea of sharing common code. The question is
>>>> then
>>>> how.
>>>>
>>>> Nicolas
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>
>
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Extracting common ide features from IvyDE
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Jul 23, 2008 at 5:52 PM, Nicolas Lalevée <ni...@hibnet.org>
wrote:
> Le lundi 14 juillet 2008, Xavier Hanin a écrit :
> > On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
> > <ni...@hibnet.org>
> >
> > wrote:
> > > Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> > > > Hi,
> > > >
> > > > As you may already know I'm currently working on Ivybeans [1], a kind
> > > > of IvyDE for Netbeans for which we have won a grant from Sun [2].
> > > >
> > > > In this plugin I need to implement features very similar to what has
> > > > been done in IvyDE, like code completion for Ivy files. I also need
> to
> > >
> > > implement
> > >
> > > > some features which are not currently supported by IvyDE like
> settings
> > > > files code completion, or a way to easily add dependencies to an
> > > > existing Ivy file.
> > > >
> > > > These features are somewhat IDE agnostic (or at least can be based on
> > > > common roots), and I think it would benefit both community and all
> > > > users
> > >
> > > if
> > >
> > > > we shared what can be shared. So I consider refactoring some code in
> > >
> > > IvyDE
> > >
> > > > (especially code used for code completion) to make it reusable
> > > > (actually I've already done the refactoring...).
> > >
> > > Can I have a look to that new package ?
> > > In fact I was asking myself if a such refactoring could be integrated
> > > into Ivy.
> >
> > Sure, for the moment I've commited the code to IvyBeans:
> >
> http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src
> >/org/apache/ivyde/common/
> >
> > Obviously the eclipse specific bits are missing from there, but you
> should
> > get the idea pretty easily.
>
> got it.
> So yes there are code that would be great to share.
>
> Then I am wondering: should it have its own release cycle, or included in
> Ivy of IvyDE's ones ?
That's a good question. I think it would deserve its own release cycle, to
avoid making any IDE plugin developed on this basis too tied to release
cycle of either Ivy or IvyDE.
>
> Having it own release cycle, it brings more release work,
Indeed.
> and more
> dependency handling (on IvyDE part).
Yes, but I think it shouldn't be a show stopper.
>
> Having it included in IvyDE seems to be overkill compared to the need of
> Ivybeans.
Agreed.
>
> Then there is the inclusion in Ivy: would it make sense to have some code
> completion algorithm on Ivy ? I don't think it would hurt.
It wouldn't hurt too much, even though I think ivy.jar is already big
enough, and we should start trying to watch its size. The main problem IMO
is that it would then have the same release cycles, whilst the evolution
needs may be very different.
>
> So I am in favor in integrating that common.ide in Ivy. Then I would prefer
> keeping it in IvyDE. And last have a new project with its own release
> cycle.
I think I prefer to either put it in IvyDE, or really split it as a separate
project. Maybe even a project hosted somewhere else. After all ASF is not
against having dependencies on Apache licensed libraries which are not from
the ASF. The advantage I see with hosting it elsewhere is that it would be
much easier to have people using the library in any plugin become a
committer on the library.
WDYT?
Xavier
>
>
> Just my feelings, I won't put any veto there.
>
> Nicolas
>
> >
> > Xavier
> >
> > > > I'd move this code to a
> > > > org.apache.ivyde.common package, which could be used by any IDE
> plugin
> > > > developer. The next step would be to move this package in a separate
> > > > module, so that other plugin developers can use it without embedding
> > > > the whole eclipse plugin. Then I could add new features to this
> common
> > >
> > > package,
> > >
> > > > which would ease the reuse of work I do for Netbeans plugin in
> eclipse
> > > > plugin.
> > > >
> > > > So, do you think it makes sense to do that? Any objection?
> > >
> > > No objection on the idea of sharing common code. The question is then
> > > how.
> > >
> > > Nicolas
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > > For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Extracting common ide features from IvyDE
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le lundi 14 juillet 2008, Xavier Hanin a écrit :
> On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
> <ni...@hibnet.org>
>
> wrote:
> > Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> > > Hi,
> > >
> > > As you may already know I'm currently working on Ivybeans [1], a kind
> > > of IvyDE for Netbeans for which we have won a grant from Sun [2].
> > >
> > > In this plugin I need to implement features very similar to what has
> > > been done in IvyDE, like code completion for Ivy files. I also need to
> >
> > implement
> >
> > > some features which are not currently supported by IvyDE like settings
> > > files code completion, or a way to easily add dependencies to an
> > > existing Ivy file.
> > >
> > > These features are somewhat IDE agnostic (or at least can be based on
> > > common roots), and I think it would benefit both community and all
> > > users
> >
> > if
> >
> > > we shared what can be shared. So I consider refactoring some code in
> >
> > IvyDE
> >
> > > (especially code used for code completion) to make it reusable
> > > (actually I've already done the refactoring...).
> >
> > Can I have a look to that new package ?
> > In fact I was asking myself if a such refactoring could be integrated
> > into Ivy.
>
> Sure, for the moment I've commited the code to IvyBeans:
> http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src
>/org/apache/ivyde/common/
>
> Obviously the eclipse specific bits are missing from there, but you should
> get the idea pretty easily.
got it.
So yes there are code that would be great to share.
Then I am wondering: should it have its own release cycle, or included in
Ivy of IvyDE's ones ?
Having it own release cycle, it brings more release work, and more
dependency handling (on IvyDE part).
Having it included in IvyDE seems to be overkill compared to the need of
Ivybeans.
Then there is the inclusion in Ivy: would it make sense to have some code
completion algorithm on Ivy ? I don't think it would hurt.
So I am in favor in integrating that common.ide in Ivy. Then I would prefer
keeping it in IvyDE. And last have a new project with its own release cycle.
Just my feelings, I won't put any veto there.
Nicolas
>
> Xavier
>
> > > I'd move this code to a
> > > org.apache.ivyde.common package, which could be used by any IDE plugin
> > > developer. The next step would be to move this package in a separate
> > > module, so that other plugin developers can use it without embedding
> > > the whole eclipse plugin. Then I could add new features to this common
> >
> > package,
> >
> > > which would ease the reuse of work I do for Netbeans plugin in eclipse
> > > plugin.
> > >
> > > So, do you think it makes sense to do that? Any objection?
> >
> > No objection on the idea of sharing common code. The question is then
> > how.
> >
> > Nicolas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Extracting common ide features from IvyDE
Posted by Xavier Hanin <xa...@gmail.com>.
On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée <ni...@hibnet.org>
wrote:
> Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> > Hi,
> >
> > As you may already know I'm currently working on Ivybeans [1], a kind of
> > IvyDE for Netbeans for which we have won a grant from Sun [2].
> >
> > In this plugin I need to implement features very similar to what has been
> > done in IvyDE, like code completion for Ivy files. I also need to
> implement
> > some features which are not currently supported by IvyDE like settings
> > files code completion, or a way to easily add dependencies to an existing
> > Ivy file.
> >
> > These features are somewhat IDE agnostic (or at least can be based on
> > common roots), and I think it would benefit both community and all users
> if
> > we shared what can be shared. So I consider refactoring some code in
> IvyDE
> > (especially code used for code completion) to make it reusable (actually
> > I've already done the refactoring...).
>
> Can I have a look to that new package ?
> In fact I was asking myself if a such refactoring could be integrated into
> Ivy.
Sure, for the moment I've commited the code to IvyBeans:
http://code.google.com/p/ivybeans/source/browse/trunk/ivybeans/ivy-libs/src/org/apache/ivyde/common/
Obviously the eclipse specific bits are missing from there, but you should
get the idea pretty easily.
Xavier
>
>
> > I'd move this code to a
> > org.apache.ivyde.common package, which could be used by any IDE plugin
> > developer. The next step would be to move this package in a separate
> > module, so that other plugin developers can use it without embedding the
> > whole eclipse plugin. Then I could add new features to this common
> package,
> > which would ease the reuse of work I do for Netbeans plugin in eclipse
> > plugin.
> >
> > So, do you think it makes sense to do that? Any objection?
>
> No objection on the idea of sharing common code. The question is then how.
>
> Nicolas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
Re: Extracting common ide features from IvyDE
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le vendredi 11 juillet 2008, Xavier Hanin a écrit :
> Hi,
>
> As you may already know I'm currently working on Ivybeans [1], a kind of
> IvyDE for Netbeans for which we have won a grant from Sun [2].
>
> In this plugin I need to implement features very similar to what has been
> done in IvyDE, like code completion for Ivy files. I also need to implement
> some features which are not currently supported by IvyDE like settings
> files code completion, or a way to easily add dependencies to an existing
> Ivy file.
>
> These features are somewhat IDE agnostic (or at least can be based on
> common roots), and I think it would benefit both community and all users if
> we shared what can be shared. So I consider refactoring some code in IvyDE
> (especially code used for code completion) to make it reusable (actually
> I've already done the refactoring...).
Can I have a look to that new package ?
In fact I was asking myself if a such refactoring could be integrated into
Ivy.
> I'd move this code to a
> org.apache.ivyde.common package, which could be used by any IDE plugin
> developer. The next step would be to move this package in a separate
> module, so that other plugin developers can use it without embedding the
> whole eclipse plugin. Then I could add new features to this common package,
> which would ease the reuse of work I do for Netbeans plugin in eclipse
> plugin.
>
> So, do you think it makes sense to do that? Any objection?
No objection on the idea of sharing common code. The question is then how.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org