beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kaufman" <>
Subject RE: Removing Beehive dependency on APT?
Date Fri, 08 Oct 2004 20:55:16 GMT

Hi Carl, 

Since a big goal of beehive is to be IDE-agnostic, I am opposed to having a beehive dependency
on JDT.  Also, I still think APT is the right choice for beehive.    

APT was chosen for a couple of reasons.  First, APT is IDE-agnostic.  Second, since APT is
shipped with the JDK, we felt it was the most "standard" option, as well as the option most
likely to have developer adoption in the future.  We felt that any IDE that wants to have
a high-fidelity controls experience could do so by implementing the appropriate APT interfaces.

I should also mention that I think it is really important that Pollinate finds a way to support
APT.  I think a lot of value in the controls story is the dev-time experience that can be
achieved when custom control authors write APT annotation processors to do extra processing
(e.g., semantic validation & file generation) when their controls are used.  I hope that
all of the IDEs that host controls support APT to achieve this high-fidelity experience, and
I hope that custom controls take advantage of this feature to make their controls easy to

Also, can you send me a pointer to the license issue concerning distribution of tools.jar?


Mike Kaufman

> -----Original Message-----
> From: Carl McConnell []
> Sent: Friday, October 08, 2004 12:43 PM
> To:
> Subject: Removing Beehive dependency on APT?
> Hi all,
> I'd like to raise an issue we've run into on the Eclipse 
> Pollinate project; 
> namely, the dependence of Beehive on Sun's APT tool for 
> generating the 
> necessary web artifacts. Having APT in the picture has posed some 
> difficulties for Pollinate. Since Sun's license precludes 
> tools.jar from 
> being included in the Pollinate distribution, Pollinate can't 
> be used out 
> of the box without some configuration (pointing it to 
> tools.jar) that's 
> unusual for an Eclipse feature like this. Also, due to the 
> way that APT 
> uses class loaders, Eclipse itself has to be invoked in an 
> unusual way so 
> that tools.jar is included in its class path. I consider the 
> latter an APT 
> bug that I'll take up with the APT developers, but my point 
> is that APT is 
> an uncomfortable fit with the Eclipse world.
> It would be nice if Beehive could avoid using APT, perhaps by 
> basing its 
> processing on JDT (the Java development technology in 
> Eclipse) a la Tomcat 
> 1.5. Perhaps an APT-workalike could be written based on JDT 
> as yet another 
> open-source project. Or perhaps Beehive could use JDT 
> directly to do its 
> processing, since in my limited understanding Beehive 
> essentially uses APT 
> to parse Java files, examine the annotations on Java elements 
> in those 
> files, and generate other files based on those annotations. I 
> think JDT 
> could be used for this purpose, although I should point out 
> that the JDK 
> 1.5 support in JDT is still under development.
> I understand that moving away from APT would be a lot of work, and is 
> unlikely to become a high priority for Beehive. I just wanted 
> to get the 
> issue on the table. Thanks.
> 	Carl McConnell
> 	Eclipse Pollinate Project

View raw message