ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Extracting common ide features from IvyDE
Date Thu, 24 Jul 2008 06:13:54 GMT

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
>>> <nicolas.lalevee@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


Mime
View raw message