On 10/6/05, Kenneth Tam <[EMAIL PROTECTED]> wrote: > On 10/5/05, Kyle Marvin <[EMAIL PROTECTED]> wrote: > > On 10/4/05, Eddie O'Neil <[EMAIL PROTECTED]> 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 ControlInterface. - 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. Cheers! -- Kyle
