Le 23 juil. 08 à 19:58, Xavier Hanin a écrit :
On Wed, Jul 23, 2008 at 5:52 PM, Nicolas Lalevée <[EMAIL PROTECTED]
>
wrote:
Le lundi 14 juillet 2008, Xavier Hanin a écrit :
On Fri, Jul 11, 2008 at 1:55 PM, Nicolas Lalevée
<[EMAIL PROTECTED]>
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: [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]
