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)
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?
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)?
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.
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?
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
> =
> > "/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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
