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 07:44:04 GMT
Le jeudi 24 juillet 2008, Xavier Hanin a écrit :
> On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalevée
> <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
> > 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


Mime
View raw message