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. 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. 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. 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. 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. 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 > = > > "/src/main/java"; > > > > I thought I'd suggest putting these defaults in > the > > xml schema, and then generating the model using > > eclipse emf, that way the defaults are built into > the > > model and the code that emf generates. > > > > It generates very elegant code (Interface, > > Implementation, Factories, etc.) and whenever the > xml > > schema changes/the maven model changes, all the > > changes it's just a few clicks and the model is > > updated. > > > > I'd be glad to help with this refactoring if there > is > > any interest. > > > > Cheers, > > - Ole > > > > __________________________________________________ > > 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] > > > > > -- > Brett Porter <[EMAIL PROTECTED]> > Apache Maven - http://maven.apache.org/ > Better Builds with Maven - > http://library.mergere.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ 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]
