Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: domain of xavier.hanin@gmail.com
 designates 209.85.198.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=CQ9R5NBffMWNLFDQteyVTnTLd+R4NSn06leH0Mon56OMU+WpTM3yOqHdutqp7EHpZN
         xm83J+xBeTJpf1l/kzXm8XKXUlfZOuyr5c/p4TYHV+/3a+B09DAoQ9hYOmqLerMH1Ke+
         FILrdB5YwthFZBDEOK0CZolf8jb9U2Pw4DYUo=
Message-ID: <635a05060807232356p26593301l3de1ff8beece830d@mail.gmail.com>
Date: Thu, 24 Jul 2008 08:56:17 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: Re: Extracting common ide features from IvyDE
In-Reply-To: <56B8E1E6-6083-4D7B-A3F6-4B1CEBDDB4C0@hibnet.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1740_6884768.1216882577631"
References: <635a05060807110126s1b20818ck7ea41091dd6968e6@mail.gmail.com>
	 <200807111355.35306.nicolas.lalevee@hibnet.org>
	 <635a05060807140910j4940b7ffq395d63d8c1bb1159@mail.gmail.com>
	 <200807231752.45276.nicolas.lalevee@hibnet.org>
	 <635a05060807231058o3938760etfa116058f44ad483@mail.gmail.com>
	 <56B8E1E6-6083-4D7B-A3F6-4B1CEBDDB4C0@hibnet.org>

------=_Part_1740_6884768.1216882577631
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalev=E9e <nicolas.lalevee@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 y=
ou
> are wondering about it, it probably means that you expect some new featur=
es
> 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 no=
t
>> 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 anothe=
r
> project.
>
> And what about common.ide included in IvyDE's release cycle, and having a=
n
> 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 depe=
nds
> 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 Luc=
ene
> (http://svn.apache.org/repos/asf/lucene/solr/tags/release-1.2.0/lib/). An=
d
> 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
>
>


--=20
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

------=_Part_1740_6884768.1216882577631--