comments inline --- Milos Kleint <[EMAIL PROTECTED]> wrote:
> comments inline. > > On 6/27/06, Ole Ersoy <[EMAIL PROTECTED]> wrote: > > Hey Brett, > > > > I've seen modello mentioned a few times on the > maven > > site, but I have not had a chance to do a head to > head > > comparison with EMF yet, I'm sure they both do a > good > > job at realizing the benefit of not having to > update > > hardcoded Strings. > > > > The reason I suggested EMF is that it can generate > > the entire model based on the xml schema, so that > any > > time there is a change in the schema, the code can > be > > regenerated. > > exactly what modello does, except it's not the > schema that is the > ultimate source of code, it's the modello's model. > (I guess equivalent > to emf's model, but never actually used emf) > It sounds like modello has something equivalent to EMF's ecore meta model, which is a subset of OMG's meta object facility. It also integrates / is integrated with the ecipse UML2 API. One nice thing about generating directly from the XML Schema is that the Ecore model and the XML Schema are kept in Sync. If one changes, the other can be automatically generated. EMF can also generate an XSD (XML Schema Definition) to Ecore Map and has a corresponding editor for viewing this map. > > > > EMF is also eclipse's modeling framework, and it > is > > used for code generation in a lot of the eclipse > > projects - like BIRT, so if Maven were to adopt > it, > > I'm thinking it would speed integration with other > > eclipse projects, as well as maven eclipse > plugins, > > like the Mergere one. > > can you elaborate how it's supposed to speed up > integration when all > it does is generated java code? or are there some > additional features? There are a lot of additional features. Most, if not all, of eclipse's MDA effort and plugins is built around it and UML2. See www.eclipse.org/emf and check out emf corner which is where other open source projects / vendors build on top of EMF and UML2. I'll give a quick example that I discovered was not necessary for what I was doing, but it may apply to others. I'm writing a code generator for Java Server Faces components. I did not want to duplicate template variables in models. In other words I wanted to take some of the initial project variables and pull them from the POM and then get the rest from the EMF Java Server Faces model. So I grabbed the Maven XML Schema and generated all the model code from it. Then I created a reference to the Maven POM from the JSF EMF model. Now when generating code I could grab parameters from the Maven POM and the JSF EMF model at the same time inside the code generator. Now since the code generator is a mojo, Maven automatically injects the parameters, so it turns out I did'nt need the reference, but someone else might (Could be someone wants to integrate with maven through an application that does not embed Maven). An other benefit I would have realized from having the defaults in the model would be in writing unit tests. Since I could not just ask, for instance Build, to give me the default for sourceDirectory, it would make the unit tests a little more robust, without the need to embed maven in the unit tests. So in other words it lets me work with Maven's default POM values, without embedding maven. I'm sure embedding maven is no big deal either, but it's nice to have the flexibility. > > > > > Anyways, the suggestion would just mean that > > components like DefaultArchetype would > > get their maven pom default values from the > generated > > model defaults. > > > > So for instance to apply this generically to > > DefaultArchetype, DefaultArchetype would import > the > > generated model implementation for the pom > element(s) > > that it needs. > > > > So for instance for the source directory default > EMF > > would generated code that looks like this: > > > > protected static final String > > SOURCE_DIRECTORY_EDEFAULT = "src/main/java"; > > > > protected String sourceDirectory = > > SOURCE_DIRECTORY_EDEFAULT; > > > > And then ofcoarse public getter and setters for > > sourceDirectory. > > > > So now DefaultArchetype would create an instance > of > > Build, call it build say, and then do > > build.getSourceDirectory(); > > > > to get the default value. > > > > So the "micro" process for doing this type of > > refactoring would be (And I'm sure I'm preaching > to > > the quire here and everywhere else, but I'd rather > be > > more thorough for the benefit of everyone on the > > list): > > > > - Generate the entire POM model from the XML > Schema > > - Whenever defaults are needed in the maven > > components, > > create an instance of the element that was > generated > > > > and then just call > getWhateverAttributeIsNeeded() > > which will return the default. > > how is that more clear than having a static constant > value defined > (either in the component or in the model's classes)? If it's defined in the model's classes and referenced in the component, then we are saying the same thing. The main goal to keep all the constants / default values defined in one place so that all code is updated when the defaults are updated, and no code refactoring has to take place. Right now if the default source directory changes in the POM Schema (It's not there yet - but suppose it was), someone would have to go and change it in DefaultArchetype by hand and everywhere else where the default has a manually coded static constant. > > > > > > The "Macro" process would be: > > > > - Go through all the source code and remove > hardcoded > > model defaults, or any other Strings that could be > put > > in the Schema and generated into the EMF model > code. > > - Source the defaults from the model code > > - Make the entire team aware that this process is > > going on so that the codebase follows the same > > standard, that way whenever there is a code > review, > > and someone sees hard coded strings, they know to > put > > it in JIRA to be updated. > > > > So I'm sure the same benefits will be achieved > with > > modello, if it generates code from the Schema, > > including defaults. > > modello has a notion of default values and makes use > of it. Does modello generate code from the XML Schema? If not the XML Schema has to be updated manually whenever the modello model changes. > > > > > I could put together a little tutorial on how an > EMF > > based model would be integrated with the maven > code if > > that sounds useful? Something like taking a > single > > XML Schema element with defaults, using eclipse to > > generate an emf model from it, and then using the > emf > > model to generate the java code for the POM > element. > > Then using the defaults for the attributes on the > POM > > element in sample maven code. > > > is starting up eclipse and regenerating the model a > required step in > the process? the generating of code is then eclipse > independent? The EMF api comes in a standalone package, which is the one I'm using to write the mojo that generates the java server faces components. Generating code with EMF is done by first selecting a source for the model, like: - XML Schema - Annotated Java Intefaces - An Ecore Model - A Rational Rose model This generates the Ecore model (If the ecore model was not the original source) and a genmodel which wraps the ecore model. The purpose of the genmodel is just to provide EMF with additional code generation settings. For instance, one of the settings is for indicating whether the code should be generating independent of the EMF API, so the only dependency would be the JDK. So right now when I update a model, I do it through eclipse because it keeps the ecore model and the generator model in sync, but it is straightforward to write a mojo that does this as well. The mojo could then be tied in with something like a toolset for maven code refactoring. So the mojo would read the XML Schema, update the ecore model and genmodel correspondingly, regenerate the POM's model, and then if any of the XML Schema Complex Type name's were changed, traverse the maven code base and update all reference handles to the complex types. Ofcoarse this requires that there are no "Hand coded" references to POM default's anywhere in the maven code base. The other reason I update the model in eclipse is because EMF generates a pretty good editor for any custom model. So for instance when editing the POM ecore model, I would fire up eclipse and use the generated EMF editor for the POM Schema and corresponding ecore model to update the model, and then sync it with the genmodel. Then regenerate the model code base and also the code for the editor. The EMF corner also has additional editor generation plugins. Cheers, - Ole > > Regards > > > Milos Kleint > > > > > > Cheers, > > - Ole > > > > > > > > > > --- Brett Porter <[EMAIL PROTECTED]> wrote: > > > > > I thought there was already a model generated > with > > > modello in trunk? > > > > > > Certainly a good idea to move these out of the > code, > > > though. > > > > > > We're interested - just let us know what you > propose > > > before doing it :) > > > > > > - Brett > > > > > > On 26/06/2006 1:27 PM, Ole Ersoy wrote: > > > > Hey Guys, > > > > > > > > Just looking over some of the code, and > noticed > > > this > > > > in > > > > DefaultArchetype. > > > > > > > > private static final String > > > > DEFAULT_TEST_RESOURCE_DIR = > "/src/test/resources"; > > > > > > > > private static final String > > > > DEFAULT_TEST_SOURCE_DIR = "/src/test/java"; > > > > > > > > private static final String > > > DEFAULT_RESOURCE_DIR = > > > > "/src/main/resources"; > > > > > > > > private static final String > DEFAULT_SOURCE_DIR > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
