You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ole Ersoy <ol...@yahoo.com> on 2006/06/26 05:27:05 UTC
DefaultArchetype Code
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArchetype Code
Posted by Ole Ersoy <ol...@yahoo.com>.
comments inline
--- Milos Kleint <mk...@gmail.com> wrote:
> comments inline.
>
> On 6/27/06, Ole Ersoy <ol...@yahoo.com> 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 <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArchetype Code
Posted by Milos Kleint <mk...@gmail.com>.
comments inline.
On 6/27/06, Ole Ersoy <ol...@yahoo.com> 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 <br...@apache.org> 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:
> > dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail:
> > dev-help@maven.apache.org
> > >
> >
> >
> > --
> > Brett Porter <br...@apache.org>
> > Apache Maven - http://maven.apache.org/
> > Better Builds with Maven -
> > http://library.mergere.com/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail:
> > dev-help@maven.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArchetype Code
Posted by Ole Ersoy <ol...@yahoo.com>.
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 <br...@apache.org> 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:
> dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail:
> dev-help@maven.apache.org
> >
>
>
> --
> Brett Porter <br...@apache.org>
> Apache Maven - http://maven.apache.org/
> Better Builds with Maven -
> http://library.mergere.com/
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> For additional commands, e-mail:
> dev-help@maven.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: DefaultArchetype Code
Posted by Brett Porter <br...@apache.org>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter <br...@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org