New Central Source Repository for Plugins

Hello,

Plugins is one of the few areas that the IDEA editor trails behind the other
Editors (like Eclipse, Netbeans and JBuilder). I believe that the best way
to promote, develop and improve the IDEA plugins is to have a central source
repository.

This will:
- Allow the community (and maybe even the IDEA developers) to contribute
ideas, support and bug / version fixes to
the plugins
- Help manage plugin development (instead of leaving it up to the individual
plugin developer). This includes bug tracking, release plans, feature
requests, etc.
- Lower plugin development barriers by providing a development standard,
package structure and a hosting location.
- Speed up development by having many very good examples of actual plugins
- Provide a single place to download plugins
- Ease the migration of a plugin from one release to the next release of
IDEA
- Share code, ideas and tips.

I believe that this will lift IDEA plugins above those of other Editors.

I have registered a project at: https://sourceforge.net/projects/ideaplugin/
It is only in a very early stage.

What I would like to know is:
1) Is there support for this idea?
2) Would other plugin developer be prepared to contribute their plugins
3) Is there anything else that we can do to promote IDEA plugin development
(i.e. maybe there should be a free (but limited) version)

Cheers



4 comments
Comment actions Permalink

Dear Gavin, your enthusiasm and attitude is something we should praise.
And try to keep.

However:

My reasons why I don't like this idea as it is:
- there is already intellij.org
- most of things you describe you can achieve with Wiki @ intellij.org
- since the plugins are relatively simple development projects, I believe
there is no need for full-size CVS and team/project management.
- todo notes and requests are easily manageable as textual descriptions
for each plugin
- some plugin developers don't want to disclose the sources (since they
may be copyrighted or used commercially).

What I like is to have usable project zipped in the plugin download area
so anybody can download it, unzip, change, build and use (or upload new
version). See for example DiffFile plugin (I stole the project structure and
use it in all plugins I work on). There are of course several other examples
of plugins with complete development environment. That's much more than
what sf.net can offer us.

r.


0
Comment actions Permalink

Hello,

Thanks for your reply.

Similar thoughts crossed my mind. Here are the reasons that I think an sf
project has great value to the IDEA community:

- most of things you describe you can achieve with Wiki @ intellij.org

Yes, the wiki can do most things but it is not the best mechanism for
community software development. Most important is CVS. Development without
source control is very risky and difficult. The bug tracking, etc are
useful, but just an added bonus.

- since the plugins are relatively simple development projects

Some may be small, some may be big. One of the advantages of team
development is that it is easier to maintain the software. For example, at
the moment it is up to a single developer to ensure that the plugin works
with a particular version of IDEA. If the plugin breaks or has bugs,
everyone has to wait until the developer fixes the plugin and uploads it. If
the developer loses interest or does not find time or does not bother
upgrading to the new version, the plugin dies. Why not share the development
task. If it is all well structured, checked into cvs, etc, anyone can make
the fixes.

- some plugin developers don't want to disclose the sources (since they

may be copyrighted or used commercially).
Yes that is a possibility. However, I think that most plugins are created by
developers saying "I wish IDEA did..." and
then writing the plugin in their own time. Most of the they can not wait to
share the idea, plugin and code with their peers.

- What I like is to have useable project zipped in the plugin download

area.
This is provided by sf. They have very powerful servers from which you can
download. Also, versions, patches, bugfixes etc can be easily managed.
Normally the code is build and available in binary form.

- See for example DiffFile plugin (I stole the project structure and use

it in all plugins I work on).
There are many good examples from which I have learnt a great deal. However,
it is nice to see the history of the code, to use the code knowing 1) you
have the latest version and 2) you are not duplicating someone else's work
fixing a bug or adding a feature.

By using sf, we share the ideas and responsibility of developing plugins.
For example, when version 3.0 is released, it would be very quick to fix all
the plugins so they conform to the final version (may even be done by one
developer). If it was up to the individual developers this may take months
to be completed.

Finally, many plugins already have their own sf project. However, it would
make it easier it they all shared a project. Also, for most plugins it is
not worth creating a whole new project. However, if the project is already
created, you could donate the code and know that it would be maintained and
enahnced in future.

Cheer

Gavin




0
Comment actions Permalink

For summary and peaceful conclusion see the very end...

- most of things you describe you can achieve with Wiki @ intellij.org

Yes, the wiki can do most things but it is not the best mechanism for
community software development. Most important is CVS. Development without
source control is very risky and difficult. The bug tracking, etc are
useful, but just an added bonus.


For me, for example, CVS in SF.NET is a disadvantage:
- for a small plugin project it is too big gun
- I have to use other VCS-s and this would make my development
environment a mess

- since the plugins are relatively simple development projects

Some may be small, some may be big. One of the advantages of team
development is that it is easier to maintain the software. For example, at
the moment it is up to a single developer to ensure that the plugin works
with a particular version of IDEA. If the plugin breaks or has bugs,
everyone has to wait until the developer fixes the plugin and uploads it.

If

the developer loses interest or does not find time or does not bother
upgrading to the new version, the plugin dies. Why not share the

development

task. If it is all well structured, checked into cvs, etc, anyone can make
the fixes.


- as you can see at intellij.org, many plugins are developed by various
people,
and as long as the sources are available, anybody can pick them up and
continue developing the plugin (or modify for his/her purposes).
- few more examples: SimpleUML is big enough plugin but (unles I'm
mistaken) it cannot be opensourced - contains too much code that is
probably
commercial property. On the other side: the SF.NET based Perforce plugin
is not growing fast enough because (IMHO) it is too complicated to join
the development.

Finally, many plugins already have their own sf project. However, it would
make it easier it they all shared a project. Also, for most plugins it is
not worth creating a whole new project. However, if the project is already
created, you could donate the code and know that it would be maintained

and

enahnced in future.


That makes sense. Now I realize that one of things that scared me most
was that I thought you want to REPLACE intellij.org as the primary plugin
reference with the SF project. If we agree that intellij.org is the place
where
all plugins are described and referenced from (being developed as ZIPs
in Wiki, or in SF, or privately) then I must agree that it's everybody's
decision
where to put the plugin and why.

I'm tired... good night.

r.


0
Comment actions Permalink

Hello,

My idea is to open the repository to all plugin developers. I know some
plugins are better developed in other ways and places. However, the
repository would offer a free, easy accessable place to share the
development.

What I would do if I were you, it put a link there, and welcome anyone and

everyone with open arms. Each plugin would then have its own module... in
time common code could be refactored out into a "plugins-common" module
for all to use... makes perfect sense to me.

Exactly what I intend to do (as long as there is enough demand.)

Cheers

Gavin


0

Please sign in to leave a comment.