The JavaOne dates have shifted back a day. The conference is now
May 16-19, 2006 instead of May 15-18, 2006. I hope no one's made unrefundable
plane reservations yet.
Subversion 1.3, an open source version control system designed to replace CVS, has been released.
"Subversion 1.3.0 is the first new feature release since 1.2.0 and includes a
number of new improvements and features." Some of the most significant updates include:
- Path-based authorization for svnserve
- Improved logging and repository listing in mod_dav_svn
- Better Python and Ruby bindings
- Several new commandline switches
- Some client and server performance improvements
- Many improved APIs
- Over 30 bug fixes
Oracle has also posted the proposed final draft specification of
JSR-198 A Standard Extension API for Integrated Development Environment .
According to the draft,
There are a diverse set of IDE products that are designed from the
ground up to be extensible platforms where third parties can plug-in
new
extensions that enhance the IDE with additional features. In general,
the layer that integrates an extension to an IDE is only compatible
with
the integration API of that single IDE. If we examine the IDE
integration layer that typical IDE platforms provide we can see that:
- It is a very thin layer of code (compared to the amount of code
generally written by the third party to implement a useful feature)
- There are many areas of similarity between the integration layers
of the different IDEs
The Extension Software Development Kit (ESDK) proposed by this
specification
defines a standard application programming framework for extending IDEs
written in Java with new functionality. It is designed to eliminate the
need to write multiple versions of the integration layer that plugs-in
the new functionality across different IDEs.
1.1 Specification Scope
Where there are many areas of integration that
could be addressed by this specification, for purposes of the first
scope, viability, and time, this version of the ESDK covers integration
points that allow extension writers to:
- Extend the IDE with new menus and commands
- Extend the IDE data model with additional document types
- Extend the IDE with new document creation wizards
- Extend the IDE with new editor types
- Extend the IDE new log pages
- Extend the IDE preferences and project settings with new property
pages
- Define extension specific extension points
- Access the IDE Environment information
- Access extension registration information
- Access project information
- Access the Java structure model
- Access the XML structure model
- Access textual data
- Manipulate documents through a virtual file system
- Listen for data model change events
- Listen for IDE events
- Interact with the compiler
- Interact with the debugger
- Use IDE utilities such as message, warning, and error dialogs
While this is a good idea in theory, I'm not sur ehow practical it is notw that IntelliJ IDEA, Eclipse, and NetBeans all have their own plugin APIs and actvie developer communities. This might fly if plugin developers demand it, or if adapters can be written that map between this API and the native plugin APIs.