Is there a specific reason that Sculptor's archetypes favor having a
completely flat project structure, rather than the standard maven
nested module structure?
I've also noticed that some of the pom files reference other pom
files resources using the file system rather than relying upon
dependencies or other standard ways to make the individual modules
"standalone"
One of the things I like about maven is how you can nest your modules
and how each module is (typically) standalone and can be worked on by
whomever on the team and then built in isolation and the artifacts
that it produces can be deployed - and then other modules that depend
upon those can retrieve them from the repository.
Here's how I currently understand it is happening:
- You create your main model.design file in a module such as
helloworld. This file resides in src/main/resources
- When you go to make another module such as helloworld-web, this one
has the oaw workflow looking for that file using the filesystem to
traverse up and grab that file.
Here's what would feel more natural to me:
- Create a module to hold the model.design files
-- this module can simply hold the text files, and nothing more
-- build and deploy this module as a .zip archive
- For every module which depends upon the model.design file - use
maven's build in dependencies to specify the model fill that it is
dependent upon.
-- in the generate-sources phase of maven's execution, use the
copy-dependencies to unzip the model.design file and put it somewhere
local to the actual project
(unless the oaW can work on a zipped or jarred DSL file - in
which case just work from that jar or zip file and treat it in the
mojo like you would when you link against some other external
dependency... i.e. use it to do the work, but don't save it in the
target directory)
The other thought I have is about the project structure in general...
having the parent at the same level as the children feels very strange.
Instead of something like this:
- foo-parent
- foo-web
- foo-ear
- foo-jsf
- foo
wouldn't something like this be better?
-foo-parent
+ foo
+ foo-ear
+ foo-web
+ foo-jsf
(the above might not be the best - I'm assuming the ear depends upon
the web and the jsf, but if it doesn't they can be all flat next to
each other, at least by the parent)
or even something like this:
- foo-parent
+ foo-model-design
+ foo
+ foo-ear
+ foo-web
+ foo-jsf
Which only adds one level deep, but at least it puts the parent above
the children. The benefit of a more nested structure, of course, is
that you can easily descend into the tree and build/test just the
piece you care about and it will rebuild all of its dependencies that
are below it - but if you have them all at the same flat level, its
only going to be using whatever versions are built and deployed.
Does the flat project structure have something to do with the quirky
maven support in Eclipse?
I'm just trying to get a feel for what some of the thinking was
behind these things - I'm not suggesting changing it right now...
(although I am going to be tweaking my local setup for my own sanity)
Ryan
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Fornax-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fornax-developer
