Yeah, given that we've shipped it and that it can be used to resolve build-time dependencies between controls, specifically in the case of using a generated Control Bean, I don't think we can remove it.
Personally, I wouldn't use it because I think dependencies should be resolved in Ant, but it can be used to resolve the dependencies Kyle described here http://mail-archives.apache.org/mod_mbox/beehive-dev/200510.mbox/[EMAIL PROTECTED] Eddie On 10/10/05, Rich Feit <[EMAIL PROTECTED]> wrote: > Since it went out with 1.0, I'd vote for deprecating it (can we output a > warning message if it's used?), and removing it in a future release. > > Rich > > Chad Schoettger wrote: > > >After completing a patch for BEEHIVE-372, 'Change AptTask to do up-front > >copying of all files', it occurred to me that the apt task's > >'compileByExtension' doesn't really have any effect on the apt compilation > >after this change. > > > >The current apt task behavior is: > > > >foreach srcExtension > >build a list of files whose ext = srcExtension > >copy and rename each file to have a '.java' extension in the apt gen dir > >if ( compileByExtension) > >compile the files with apt > >end foreach > >if (!compileByExtension) > >compile all src files with apt > > > >After the fix for BEEHIVE-372 the apt task behavior would be: > > > >foreach srcExtension > >build a list of files whose ext = srcExtension > >copy and rename each file to have a '.java' extension in the apt gen dir > >end foreach > >compile all src files with apt > > > >Does any one on the list have an opinion on whether or not the > >'compileByExtension' attribute should be removed? It seems that with the > >move to '.java' extensions for controls, pageflows and webservices coupled > >with this change there isn't really a need for it anymore. I am fine with > >keeping it around for backwards compatibility if that is the feedback I > >receive. > > > >- Chad > > > > > > >
