On Thu, Jul 24, 2008 at 8:13 AM, Nicolas Lalevée <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> Xavier Hanin - Independent Java Consultant >> http://xhab.blogspot.com/ >> http://ant.apache.org/ivy/ >> http://www.xoocode.org/ >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
