[jbosstools-dev] Core Plugins

[Rob Stryker]

Hi. Just thought I'd let you all know what I'm doing in SVN right now, 
and with the core plugins.

As Marshall outlined a month ago in email, most of the core plugins are 
simply legacy. Some do contain functionality we'd like to keep, others 
do not. Last night I moved several of the ones that are definitely not 
going to be included into a new legacy folder. The structure now (thanks 
to Marshall) should also conform to the rest of the SVN structure.

So, what I plan to do is as follows:
   1) move xdoclet, the old web services, aop, and defunct test cases 
into legacy immediately (done)
   2) refactor / remove the ejb3 plugin. As per Marshall's reply 
yesterday, his old classpath containers will be restored so that a user 
can add ejb3 jars to any project that they want.
   3) combine the J2EE API / source libraries (J2EE 1.3, 1.4 libraries), 
with the ejb3 classpath container, into one plugin, tentatively to be 
placed under the AS Tools module in a plugin dedicated to housing 
classpath containers of these types.  (EJB3 source API will also be added)
   4)  move to legacy any jdt.* plugins who's APIs are not being used by 
others.
   5)  move to legacy org.jboss.ide.eclipse.product
   6)  continue with the goal of consolidating similar code into fewer 
plugins and excising old outdated code.

Eventually, I may look to see what in XDoclet is broken and remedy it. I 
realize it's an old technology and not to be encouraged anymore, 
however, if it turns out, as I suspect, that the breakage right now is 
minimal, I'll patch it up but it will remain in legacy.

I personally would like to see two levels of legacy modules, one which 
is essentially a garbage pail, and the other being a lost-and-found / 
abandoned one. For example, old web services would go to the trash heap, 
but xdoclet would go to abandoned. Your input is most welcome on this, 
but there's plenty of time to decide on that. That isn't a rush situation.

Either way, my goal here is to consolidate the good, trim away the bad, 
and take ownership of these areas.

Of these changes, the only one I'm going to try to sneak in before this 
week's release is the ejb3 change, for several reasons. First, I think 
having two ejb3 project types will confuse the user. Second, any user 
who does use our ejb3 project type will see it snatched out from under 
him by next month's release, and he'll have to re-import all of his code 
from source, which could become a royal pain. 

All other changes will be executed on a branch of the core module to 
refrain from build-breaking, because otherwise I'd have to anticipate an 
angwy smiley wiking and all the loud hagar-ish noises that come with it ;)

- Rob Stryker