My first suggestion is to completely separate the development and
release cycle of your common modules.
Otherwise:
> \- Shared parent project
> -- Simple Weather API
> +- Simple Parent Project
> -- Simple Web Application Project
> +- Simple Parent Project
> -- Simple Web Application Project 2
And in the pom of your shared parent project create a <modules> tag
with the "Simple Weather API" module and two profiles, each one adding
one of the other modules.
<profiles>
<profile>
<id>WAP</id>
<modules>
<module>Simple Parent Project</module>
</modules>
</profile>
<profile>
<id>WAP-2</id>
<modules>
<module>Simple Parent Project 2</module>
</modules>
</profile>
</profiles>
mvn install will now only compile the common module.
mvn install -PWAP will install the common module and the first web app.
mvn install -PWAP,WAP-2 will install the common module and both of the webapps.
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Thu, Nov 13, 2008 at 7:23 PM, Wayne Fay <[EMAIL PROTECTED]> wrote:
>> Is there any way to set up multi-module projects so that they can share a
>> module, and both projects can detect when that module's source code is
>> out-of-date? Thanks,
>
> Well this is the first obvious approach:
>> \- Simple Parent Project
>> +- Simple Weather API
>> +- Simple Web Application Project
>> +- Simple Web Application Project 2
>
> or this:
> \- Shared parent project
>> +- Simple Parent Project
>> -- Simple Weather API
>> -- Simple Web Application Project
>> +- Simple Parent Project 2
>> -- Simple Web Application Project 2
>
> Or you could use a "builder pom" that some people advocate, which
> looks something like:
> \- builder pom (modules "..\parent1" and "..\parent2")
> \- Simple Parent Project
> +- Simple Weather API
> +- Simple Web Application Project
> \- Simple Parent Project 2
> +- Simple Web Application Project 2
>
> One note, I personally do not like/use the third approach myself. 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. The
> fact that the projects are "completely independent" is not
> particularly important IMO.
>
> Another option would be to simply break the API out as its own
> project. Then changes would be "detected" by no one, and you would
> have to forcibly update/rebuild the webapps on an as-needed basis.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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]
