beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Marvin <>
Subject Re: changing the system controls from .jcs to .java
Date Fri, 07 Oct 2005 13:53:09 GMT
On 10/6/05, Kenneth Tam <> wrote:
> On 10/5/05, Kyle Marvin <> wrote:
> > On 10/4/05, Eddie O'Neil <> wrote:
> > > All--
> > >
> > >  I'm going to rename the system controls from being *.jcs files to
> > > being *.java files so that they're easier to work with in the IDE.
> > > Shouldn't be any other changes as a result except for a bit of code
> > > reformatting.
> > >
> > >  Dissenters, weigh in.  :)
> >
> > I think this is fine.  Ironically, the reason why custom filename
> > extensions exist at all was to make things easier for an IDE (so it
> > could present different file types w/out having to open/scan the file
> > for annotations).
> >
> > But the actual handling of .jcs and .java is identical from a
> > bulid/runtime perspective, so there shouldn't be any problems.
> >
> > -- Kyle
> >
> I haven't checked on this recently, but there may actually be an issue
> wrt build-time with eliminating .jcs.

The specific issue involved here is if you have two different controls
(say XControl and YControl) you are trying to build in a single <apt>
pass, and the implementation of one control (XControlImpl) has a
nested instance of the other control (YControlBean).

The reason for the issue is that APT doesn't know about or all
code-generated classes to participate in the parse of a particular APT
phase.   So in the example above, it is doing syntactic validation of
XControlImpl, but isn't yet aware of YControlBean because it won't
exist until after the current APT compile phase is complete (because
YControl, which generates it, is also part of that phase).

There are two potential workarounds:

- declared the nested instance as 'YControl' instead of
'YControlBean'.  This is generally acceptible if XControlImpl doesn't
need to call any of the YControlBean setter/getter or event
registration methods, that only exist on the bean class, not the base

- break the build into two separate <apt> invocations, where you first
run APT on YControl, then again on XControl.    This avoids the
dependency problem above.


-- Kyle

View raw message