I'm more than happy to have some "real" things to get
my teeth into ... I am getting pretty miserable with life at
What exactly do you mean by re-uniting them?
I am guessing that you mean we can re-consolidate stuff
that is "read-only" with the "write" stuff in the internal
Are we going to change all of the package and class
names? Can I get rid of the stupid "Iext" convention that I made up???
And how far should we go in terms of fixing some of the
stupid bits in the API - there are some things we should add for sure, but a
couple that should go.
Finally, none of the Collections are generic at the
moment - maybe we should be looking at using Collection<IArtifact>
wherever possible - this would make the plugin development a lot
Of course, if I can't connect to the CVS repository it
doesn't really matter!
As part of the legacy code clean-up
activities, I think we need to take a close look at the API(s).
First of all the split between
internal and external API kind of made sense when we weren’t open-source, but it
certainly doesn’t anymore. On top of that, it makes the code very messy and
inconsistent. This may even get worse, as we currently have 2 APIs, 1 for
Eclipse plugins, 1 for TS plugins but as we will (I think I understand how now)
migrate TS plugins to be proper Eclipse plugins too (you will finally get a
debugger I guess J), this doesn’t make
Second, there is a convention in
Eclipse plugins that API code should be exported to other plugins, and that this
API is considered stable. Anything that is not stable, or not part of the API
should be under a “.internal.*” package.
Third… since we in the process of
migrating the plugins, we need to make this change now, rather than forcing
another plugin migration.
So… I know I asked you to split up
the API into ext and non-ext a while back… how about you re-unite them now
I’d put that on the agenda for this
coming Monday’s call… but it appears to be a holiday in the US… and I don’t
want to delay the discussion until the following