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
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
Show replies by date