On Nov 13, 2008, at 1:23 PM, Wayne Fay wrote:
I would tend towards the first one if you require both projects to
"detect when a shared module is out-of-date" as you have stated.
That's actually the approach our team is using now. The problem is
that we've got quite a large number of projects. Something like this:
\- Simple Parent Project
+- Simple Weather API
+- Simple Web Application Project
+- Simple Web Application Project 2
+- Simple Web Application Project 3
+- ...
+- ...
+- Simple Web Application Project 17
And so when we do "mvn install" on the parent project, Maven goes
through every module and does an install on it, copying the JAR to the
local repository. This takes a lot of time, even if there's only one
source code change.
Perhaps something like this would work better:
\- Simple Parent Project (does not include module definitions, only
repository and SCM info)
\- Libraries (specifies each child as a module)
+- Simple Weather API
+- Some Other API
+- Yet Another API
\- Applications (no module definitions)
+- Simple Web Application Project
+- Simple Web Application Project 2
+- Simple Web Application Project 3
With this approach, each application project would declare "Libraries"
as a module. I could then do "mvn install" on an application project,
and it would build only the Libraries module (with all of its
children) and the one application, filtering out the rest.
The only problem is that as the number of libraries grows, so too does
the build time, even if the application only depends on one or two
libraries. So I'm back to the same issue of the build taking too long
as Maven goes through each module and does an "install" on it.
But then, this seems like a Maven bug. Why go through the install
process for a project if its source code hasn't changed?
Trevor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
