Right. See a very recent discussion with Bruno and I regarding that. BTW, who is the expert on that? Stan?
sean On 6/21/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Wait a minute: WML is nothing that should be in tools, right? > > WML is the renderkit, isn't it? > > regards, > > Martin > > On 6/21/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > OK what if we create a root level dir called "tools"? So we have: > > > > tools/codegen > > tools/xdoclet > > tools/wml > > > > With the codegen, xdoclet and wml directories the same as what's under > > src in the current structure now. > > > > I can rearrange like this and then we can eventually clean up the > > build scripts so that they work again. > > > > Sound good? > > > > sean > > > > On 6/21/05, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > Yes, right. It's not needed to compile. > > > But it is still usable as convenient tool for new components *and* it > > > is still needed to (indirectly) change code that is embedded in those > > > "do not change generated code" sections. > > > > > > -Manfred > > > > > > > > > 2005/6/21, Sean Schofield <[EMAIL PROTECTED]>: > > > > Its not currently needed to build the source right? My understanding > > > > was that it was used by Manfred and others back in the day when they > > > > were creating the source code. So its not needed to compile right? > > > > > > > > Let me take a look at where this would go in the svn reorg ... (I > > > > agree that as far as artifacts go, it would be in the source bundle) > > > > > > > > sean > > > > > > > > > > > > On 6/21/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > > Of course yes, I didn't mean in the binary release, but in the source > > > > > release, sorry... > > > > > > > > > > regards, > > > > > > > > > > Martin > > > > > > > > > > On 6/21/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > > > > > I do also think that this code generation stuff should not be > > > > > > included > > > > > > in the binary release. I think it is only used by developers who > > > > > > create components, so they already have the sources. And, moreover, > > > > > > the build.xml is always used, and it comes with the source, so > > > > > > shipping the codegen stuff with the source should be enoguh... > > > > > > > > > > > > Regards, > > > > > > > > > > > > Bruno > > > > > > > > > > > > 2005/6/21, Manfred Geiler <[EMAIL PROTECTED]>: > > > > > > > Thanks Martin, > > > > > > > perfect explanation. > > > > > > > (These classes where perpetrated by me and are undocumented at > > > > > > > all - > > > > > > > shame on me) > > > > > > > > > > > > > > I am not sure if we really should ship this stuff with binary > > > > > > > release, > > > > > > > because it only makes sense for experienced component developers. > > > > > > > So > > > > > > > shipping it together with source should be enough, IMO. > > > > > > > > > > > > > > -Manfred > > > > > > > > > > > > > > 2005/6/21, Martin Marinschek <[EMAIL PROTECTED]>: > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > yes, I think something like a tools directory would be > > > > > > > > appropriate. I > > > > > > > > would ship it with myfaces-all.jar though, cause some users > > > > > > > > might want > > > > > > > > to use it. > > > > > > > > > > > > > > > > The code generation stuff is really easy to use: > > > > > > > > > > > > > > > > - go to the directory of one of the custom components > > > > > > > > - you find a xxx.xml file there which tells you details about > > > > > > > > the > > > > > > > > component, the code generator uses these files. > > > > > > > > > > > > > > > > just implement the one you need to do for your component! > > > > > > > > > > > > > > > > next up, go to build/codegen, and use the build.xml file there > > > > > > > > for > > > > > > > > creating the generated code - you need to set the component you > > > > > > > > want > > > > > > > > to work on in the properties file. > > > > > > > > > > > > > > > > Finished - the code generator replaces all code in the > > > > > > > > component class > > > > > > > > between the predefined markes with the generated code, > > > > > > > > especially the > > > > > > > > value binding things are a pretty neat thing to have generated. > > > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > > > Martin > > > > > > > > > > > > > > > > On 6/21/05, John Fallows <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hey Sean, > > > > > > > > > > > > > > > > > > We originally created a separate tools project for code that > > > > > > > > > is only > > > > > > > > > used at build time and never ships. This code is currently > > > > > > > > > being > > > > > > > > > migrated to Maven Plugins to decrease complexity within each > > > > > > > > > project > > > > > > > > > that uses the build tools. > > > > > > > > > > > > > > > > > > Kind Regards, > > > > > > > > > John Fallows. > > > > > > > > > > > > > > > > > > On 6/20/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I'm doing a test run of the svn reorg. I'm not sure where > > > > > > > > > > the code in > > > > > > > > > > myfaces/trunk/src/codegen belongs. Is this api, impl, > > > > > > > > > > share or > > > > > > > > > > component? > > > > > > > > > > > > > > > > > > > > I'm also not sure how the codegen works in MyFaces in > > > > > > > > > > general so if > > > > > > > > > > someone could provide me an explanation of how this works > > > > > > > > > > that would > > > > > > > > > > ne nice :-) > > > > > > > > > > > > > > > > > > > > I will have more of these types of questions over the next > > > > > > > > > > few days as > > > > > > > > > > I try to sort out everything in the repository. Please try > > > > > > > > > > to provide > > > > > > > > > > answers ASAP so we can move on to the other cool stuff > > > > > > > > > > after the reorg > > > > > > > > > > (like adding new sandbox components!) > > > > > > > > > > > > > > > > > > > > sean > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
