Hi Anders The codebase is the same. So having 2 separate directories (for modules) and pom in each of them is not required right ?
I can have <modules> in parent pom to specify the 2 child poms that are present in the same project level. Tried below and seems it is working. parent pom will have : <modules> <module>pom-war.xml</module> <module>pom-jar.xml</module> <modules> In both child poms, <parent> <relativePath>./pom-parent.xml</relativePath> </parent> Currently including the jar artifact dependency in war project cannot be done due to some restrictions in our development. Narayanan On Tue, Apr 22, 2014 at 11:37 AM, Anders Hammar <[email protected]> wrote: >> My new maven project structure will be : >> >> . >> | -- pom.xml (parent pom) >> | -- pom-war.xml (inherits from parent, generates a war) >> | -- pom-jar.xml (inherits from parent, generates a jar) >> >> There are no modules in the project. All poms are going to be in the >> root path of the project. >> > > Wrong! > You should create two modules; one for the jar project and one for the war > project. Follow the Maven standards and you can use any of the many > examples of this on the Internet. > I believe we haven't pushed the mantra for some time now, so here it comes: > Don't fight Maven! > > /Anders > > >> >> 1. Any examples on how to write the parent pom referencing the same >> codebase for the child poms. >> Will there be a <module> tag for parent pom. I understand that the >> packaging for parent pom will be "pom". >> >> 2. The child poms will have <relativePath> in <parent> tag as >> ./pom.xml. Please correct me if this is wrong. >> >> Thanks >> Narayanan >> >> >> >> >> >> Narayanan >> >> On Tue, Apr 22, 2014 at 12:38 AM, Stephen Connolly >> <[email protected]> wrote: >> > On 22 April 2014 01:18, Narayanan K <[email protected]> wrote: >> > >> >> Hi >> >> >> >> We have a default pom file with packaging "war" for our codebase. >> >> >> >> From the same code base we also want to generate a normal jar and a >> >> fat jar with dependencies. >> >> >> >> Currently solution that has been implemented is another pom-jar.xml >> >> file that has the packaging as jar and maven-assembly-plugin to >> >> generate the jar with dependencies. We use mvn install -f pom-jar.xml. >> >> >> >> But we are in a situation where if any new dependency is added to >> >> pom.xml, we need to add to pom-jar.xml as well as it is the same >> >> codebase. >> >> >> >> To avoid this we thought of couple of solutions - >> >> >> >> 1. Add maven-jar-plugin and maven-assembly-plugin to the default pom >> >> with packaging war - so it generates a war file, a normal jar file and >> >> fat jar out of the same pom. So we can do away with the pom-jar.xml. >> >> >> >> Not sure if this is a good solution. We tried this, but this is >> >> working well only in maven 3.0.4. The assembly plugin is not working >> >> well with Maven 2 (which is in our build environment) while generating >> >> the fat jar. >> >> >> >> 2. Have a parent pom and put all the dependencies and plugins in that >> >> and have 2 child poms in the same codebase with different names >> >> inherit from parent pom, one that has packaging of war that generates >> >> war file and the other child pom has packaging jar with maven assembly >> >> plugin to generate both normal and fat jar. And all new dependencies >> >> need to be added only to parent pom. >> >> >> >> This solution will make us have 3 pom files in codebase, doesnt look >> >> very elegant, >> > >> > >> > actually depends on your point of view. To me this is the more elegant >> > solution as you clearly see the relationship between inputs (pom.xml) and >> > outputs (artifacts, e.g. jars wars, etc) >> > >> > >> >> but will solve our dependency management issues between >> >> the 2 packaging. >> >> >> >> >> >> Are these good solutions? Is there any other good solution available >> >> for this scenario ? >> >> >> >> >> >> Regards >> >> Narayanan >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
