Re: Resolve root directory in a multi-project build

[Hervé BOUTEMY]

I wrote a doc for deploying to local staging directory [1] in Maven Deploy 
Plugin documentation (not yet released)

perhaps this can be of use

Regards,

Hervé

[1] 
https://maven.apache.org/plugins-archives/maven-deploy-plugin-LATEST/examples/deploy-network-issues.html

Le vendredi 5 février 2021, 18:52:09 CET Andres Almiray a écrit :
> @Tamás: Right, should had explained the use case. I want to deploy all
> artifacts to a local directory so that I can inspect everything which will
> be deployed given certain conditions.
> I managed to do that by forcing a stable, absolute directory as shown at
> 
> https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa57992921
> 1aac20bef3f5e00
> 
> I'd prefer if the target directory be ${rootProject.build.directory} if
> there were such things as {$rootProject}, which is why I'm asking for a way
> to find out that value.
> As you may appreciate in that commit the value is used as part of
>  in a profile.
> 
> @Lasse: I thought using that plugin would work but not in my case as the
> computed property is not available during model interpolation which is my
> case for setting the correct value in 
> 
> Cheers,
> Andres
> 
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
> 
> 
> On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist 
> wrote:
> > Using directory-maven-plugin and highest-basedir goal from it has worked
> > just fine for me.
> > https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
> > 
> > pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> > 
> > kirjoitti:
> > > Howdy,
> > > Grab somehow (you did not state from where if "outside of plugins")
> > > MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> > > what you want, as one may use -f param for example...
> > > 
> > > So, I'd shoot back: WHY do you need the root of a multi module build and
> > > FROM WHAT you need it? Extension?
> > > Are you sure you can expect maven is invoked from root? Could it be
> > 
> > simpler
> > 
> > > just to pass in as some parameter maybe, instead of doing all sorts of
> > > hoops and loops?
> > > 
> > > T
> > > 
> > > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> > 
> > wrote:
> > > > Hello everyone,
> > > > 
> > > > Is there a way to reliably resolve the value of the root directory for
> > 
> > a
> > 
> > > > given multi-project build?
> > > > Unfortunately ${session.executionRootDirectory} does not seem to work
> > 
> > for
> > 
> > > > all cases, it might work when used inside a plugin's 
> > > > section but does not when used outside of plugins
> > > > 
> > > > TIA
> > > > 
> > > > Cheers,
> > > > Andres
> > > > 
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > http://andresalmiray.com
> > > > http://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> > > > binary,
> > > 
> > > and
> > > 
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Andres Almiray]

t;> 
>>>>>> 
>>>>>> Delany schrieb am 06.02.2021 17:24 (GMT +07:00):
>>>>>> 
>>>>>>> This only works if the parent is the root. If you extend to a third
>>>>>> level
>>>>>>> of pom, it will report the rootlocation as the project directory.
>>>>>>> 
>>>>>>> On Sat, 6 Feb 2021 at 04:22, Alexander Kriegisch
>>>>>> >>>>> <mailto:alexan...@kriegisch.name> >
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> I had some discussion with Karl Heinz Marbaise about
>>>>>>>> maven.multiModuleProjectDirectory a while ago (cannot remember
>> where
>>>>>>>> exactly) and he strongly advised me not to use it as it is for
>>>>>> internal
>>>>>>>> use only. Even so, other tools such as IntelliJ IDEA use it
>>>>>> internally,
>>>>>>>> but not consequently, the situationis a bit messy.
>>>>>>>> 
>>>>>>>> What I ended up doing was to use Build Helper Maven Plugin >=
>> 3.2.0
>>>>>>>> (because of
>>>>>>>> 
>>>>>> https://github.com/mojohaus/build-helper-maven-plugin/issues/48)
>>>>>> and
>>>>>>>> there to use the "rootlocation" goal. I am not sure if that is
>>>> working
>>>>>>>> for you here because you said you need it somewhere in a plugin
>> and I
>>>>>>>> just use it in my project's root POM. For IDEA I still need need
>>>>>>>> "-DprojectRootDir=..." in /.mvn/jvm.config, but
>> from
>>>>>> the
>>>>>>>> command line it works, even when building from a module
>> subdirectory.
>>>>>>>> Here is my POM (just search for the string "rootlocation" there,
>> you
>>>>>>>> should find 4 places):
>>>>>>>> 
>>>>>>>> https://github.com/SarekTest/Sarek/blob/master/pom.xml
>>>>>>>> --
>>>>>>>> Alexander Kriegisch
>>>>>>>> https://scrum-master.de
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
>>>>>>>> 
>>>>>>>>> For me, no problem on Jenkins either (using "withMaven" pipeline
>>>>>> step).
>>>>>>>>> There used to be this issue:
>>>>>>>> https://issues.jenkins.io/browse/JENKINS-35335
>>>>>>>>> Which turned out to be a Maven bug which was fixed in 3.5.0:
>>>>>>>>> https://issues.apache.org/jira/browse/MNG-5889
>>>>>>>>> 
>>>>>>>>> As far as MNG-5830 is concerned, I don't know what (special)
>> setup
>>>>>> the
>>>>>>>>> affected people are using.
>>>>>>>>> 
>>>>>>>>> I can only say/repeat that you need a .mvn directory to have the
>>>>>>>>> property point to your root directory.
>>>>>>>>> But even without .mvn, there should not be such an error
>> message,
>>>> so
>>>>>> IDK
>>>>>>>>> what's going on in those cases.
>>>>>>>>> 
>>>>>>>>> Am 05.02.2021 um 22:13 schrieb Delany:
>>>>>>>>>> Maybe for you Falko, but not my Jenkins server with Maven
>> 3.6.3,
>>>> or
>>>>>>>> these
>>>>>>>>>> other users
>>>>>>>>>> 
>>>>>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>>>>>>>>>> Delany
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, 5 Feb 2021, 22:25 Falko Modler, >>>>> <mailto:f.mod...@gmx.net> > wrote:
>>>>>>>>>> 
>>>>>>>>>>> I've been using maven.multiModuleProjectDirectory in various
>>>>>> projects
>>>>>>>>>>> (and have also seen it in others)

Re: Resolve root directory in a multi-project build

[Delany]

;> use only. Even so, other tools such as IntelliJ IDEA use it
> >> >> internally,
> >> >> >> but not consequently, the situationis a bit messy.
> >> >> >>
> >> >> >> What I ended up doing was to use Build Helper Maven Plugin >=
> 3.2.0
> >> >> >> (because of
> >> >> >>
> >> >> https://github.com/mojohaus/build-helper-maven-plugin/issues/48)
> >> >> and
> >> >> >> there to use the "rootlocation" goal. I am not sure if that is
> >> working
> >> >> >> for you here because you said you need it somewhere in a plugin
> and I
> >> >> >> just use it in my project's root POM. For IDEA I still need need
> >> >> >> "-DprojectRootDir=..." in /.mvn/jvm.config, but
> from
> >> >> the
> >> >> >> command line it works, even when building from a module
> subdirectory.
> >> >> >> Here is my POM (just search for the string "rootlocation" there,
> you
> >> >> >> should find 4 places):
> >> >> >>
> >> >> >> https://github.com/SarekTest/Sarek/blob/master/pom.xml
> >> >> >> --
> >> >> >> Alexander Kriegisch
> >> >> >> https://scrum-master.de
> >> >> >>
> >> >> >>
> >> >> >> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
> >> >> >>
> >> >> >> > For me, no problem on Jenkins either (using "withMaven" pipeline
> >> >> step).
> >> >> >> > There used to be this issue:
> >> >> >> https://issues.jenkins.io/browse/JENKINS-35335
> >> >> >> > Which turned out to be a Maven bug which was fixed in 3.5.0:
> >> >> >> > https://issues.apache.org/jira/browse/MNG-5889
> >> >> >> >
> >> >> >> > As far as MNG-5830 is concerned, I don't know what (special)
> setup
> >> >> the
> >> >> >> > affected people are using.
> >> >> >> >
> >> >> >> > I can only say/repeat that you need a .mvn directory to have the
> >> >> >> > property point to your root directory.
> >> >> >> > But even without .mvn, there should not be such an error
> message,
> >> so
> >> >> IDK
> >> >> >> > what's going on in those cases.
> >> >> >> >
> >> >> >> > Am 05.02.2021 um 22:13 schrieb Delany:
> >> >> >> >> Maybe for you Falko, but not my Jenkins server with Maven
> 3.6.3,
> >> or
> >> >> >> these
> >> >> >> >> other users
> >> >> >> >>
> >> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
> >> >> >> >> Delany
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Fri, 5 Feb 2021, 22:25 Falko Modler,  >> >> <mailto:f.mod...@gmx.net> > wrote:
> >> >> >> >>
> >> >> >> >>> I've been using maven.multiModuleProjectDirectory in various
> >> >> projects
> >> >> >> >>> (and have also seen it in others).
> >> >> >> >>> You'll need a .mvn directory in your root directory to make it
> >> >> work.
> >> >> >> >>>
> >> >> >> >>> PS: I know that there has been some controvery about this
> >> property
> >> >> but
> >> >> >> >>> well, it works! ;-)
> >> >> >> >>>
> >> >> >> >>> Cheers,
> >> >> >> >>> Falko
> >> >> >> >>>
> >> >> >> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> >> >> >> >>>> Hello everyone,
> >> >> >> >>>>
> >> >> >> >>>> Is there a way to reliably resolve the value of the root
> >> >> directory
> >> >> >> for a
> >> >> >> >>>> given multi-project build?
> >> >> >> >>>> Unfortunately ${session.executionRootDirectory} does not
> seem to
> >> >> work
> >> >> >> for
> >> >> >> >>>> all cases, it might work when used inside a plugin's
> >> >> 
> >> >> >> >>>> section but does not when used outside of plugins
> >> >> >> >>>>
> >> >> >> >>>> TIA
> >> >> >> >>>>
> >> >> >> >>>> Cheers,
> >> >> >> >>>> Andres
> >> >> >> >>>>
> >> >> >> >>>> ---
> >> >> >> >>>> Java Champion; Groovy Enthusiast
> >> >> >> >>>> http://andresalmiray.com
> >> >> >> >>>> http://www.linkedin.com/in/aalmiray
> >> >> >> >>>> --
> >> >> >> >>>> What goes up, must come down. Ask any system administrator.
> >> >> >> >>>> There are 10 types of people in the world: Those who
> understand
> >> >> >> binary,
> >> >> >> >>> and
> >> >> >> >>>> those who don't.
> >> >> >> >>>> To understand recursion, we must first understand recursion.
> >> >> >> >>>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> -
> >> >> >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> >> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >> >> <mailto:users-h...@maven.apache.org>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> -
> >> >> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> >> <mailto:users-h...@maven.apache.org>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> -
> >> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> >> <mailto:users-h...@maven.apache.org>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> >> <mailto:users-h...@maven.apache.org>
> >> >>
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Resolve root directory in a multi-project build

[Alexander Kriegisch]

xander Kriegisch
>> >> >> https://scrum-master.de
>> >> >>
>> >> >>
>> >> >> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
>> >> >>
>> >> >> > For me, no problem on Jenkins either (using "withMaven" pipeline
>> >> step).
>> >> >> > There used to be this issue:
>> >> >> https://issues.jenkins.io/browse/JENKINS-35335
>> >> >> > Which turned out to be a Maven bug which was fixed in 3.5.0:
>> >> >> > https://issues.apache.org/jira/browse/MNG-5889
>> >> >> >
>> >> >> > As far as MNG-5830 is concerned, I don't know what (special) setup
>> >> the
>> >> >> > affected people are using.
>> >> >> >
>> >> >> > I can only say/repeat that you need a .mvn directory to have the
>> >> >> > property point to your root directory.
>> >> >> > But even without .mvn, there should not be such an error message,
>> so
>> >> IDK
>> >> >> > what's going on in those cases.
>> >> >> >
>> >> >> > Am 05.02.2021 um 22:13 schrieb Delany:
>> >> >> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3,
>> or
>> >> >> these
>> >> >> >> other users
>> >> >> >>
>> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>> >> >> >> Delany
>> >> >> >>
>> >> >> >>
>> >> >> >> On Fri, 5 Feb 2021, 22:25 Falko Modler, > >> <mailto:f.mod...@gmx.net> > wrote:
>> >> >> >>
>> >> >> >>> I've been using maven.multiModuleProjectDirectory in various
>> >> projects
>> >> >> >>> (and have also seen it in others).
>> >> >> >>> You'll need a .mvn directory in your root directory to make it
>> >> work.
>> >> >> >>>
>> >> >> >>> PS: I know that there has been some controvery about this
>> property
>> >> but
>> >> >> >>> well, it works! ;-)
>> >> >> >>>
>> >> >> >>> Cheers,
>> >> >> >>> Falko
>> >> >> >>>
>> >> >> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
>> >> >> >>>> Hello everyone,
>> >> >> >>>>
>> >> >> >>>> Is there a way to reliably resolve the value of the root
>> >> directory
>> >> >> for a
>> >> >> >>>> given multi-project build?
>> >> >> >>>> Unfortunately ${session.executionRootDirectory} does not seem to
>> >> work
>> >> >> for
>> >> >> >>>> all cases, it might work when used inside a plugin's
>> >> 
>> >> >> >>>> section but does not when used outside of plugins
>> >> >> >>>>
>> >> >> >>>> TIA
>> >> >> >>>>
>> >> >> >>>> Cheers,
>> >> >> >>>> Andres
>> >> >> >>>>
>> >> >> >>>> ---
>> >> >> >>>> Java Champion; Groovy Enthusiast
>> >> >> >>>> http://andresalmiray.com
>> >> >> >>>> http://www.linkedin.com/in/aalmiray
>> >> >> >>>> --
>> >> >> >>>> What goes up, must come down. Ask any system administrator.
>> >> >> >>>> There are 10 types of people in the world: Those who understand
>> >> >> binary,
>> >> >> >>> and
>> >> >> >>>> those who don't.
>> >> >> >>>> To understand recursion, we must first understand recursion.
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> -
>> >> >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> <mailto:users-unsubscr...@maven.apache.org>
>> >> >> >>> For additional commands, e-mail: users-h...@maven.apache.org
>> >> <mailto:users-h...@maven.apache.org>
>> >> >> >>>
>> >> >> >>>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> -
>> >> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> <mailto:users-unsubscr...@maven.apache.org>
>> >> >> > For additional commands, e-mail: users-h...@maven.apache.org
>> >> <mailto:users-h...@maven.apache.org>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> <mailto:users-unsubscr...@maven.apache.org>
>> >> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >> <mailto:users-h...@maven.apache.org>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >> <mailto:users-unsubscr...@maven.apache.org>
>> >> For additional commands, e-mail: users-h...@maven.apache.org
>> >> <mailto:users-h...@maven.apache.org>
>> >>
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Delany]

t; >> >> > affected people are using.
> >> >> >
> >> >> > I can only say/repeat that you need a .mvn directory to have the
> >> >> > property point to your root directory.
> >> >> > But even without .mvn, there should not be such an error message,
> so
> >> IDK
> >> >> > what's going on in those cases.
> >> >> >
> >> >> > Am 05.02.2021 um 22:13 schrieb Delany:
> >> >> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3,
> or
> >> >> these
> >> >> >> other users
> >> >> >>
> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
> >> >> >> Delany
> >> >> >>
> >> >> >>
> >> >> >> On Fri, 5 Feb 2021, 22:25 Falko Modler,  >> <mailto:f.mod...@gmx.net> > wrote:
> >> >> >>
> >> >> >>> I've been using maven.multiModuleProjectDirectory in various
> >> projects
> >> >> >>> (and have also seen it in others).
> >> >> >>> You'll need a .mvn directory in your root directory to make it
> >> work.
> >> >> >>>
> >> >> >>> PS: I know that there has been some controvery about this
> property
> >> but
> >> >> >>> well, it works! ;-)
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>> Falko
> >> >> >>>
> >> >> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> >> >> >>>> Hello everyone,
> >> >> >>>>
> >> >> >>>> Is there a way to reliably resolve the value of the root
> >> directory
> >> >> for a
> >> >> >>>> given multi-project build?
> >> >> >>>> Unfortunately ${session.executionRootDirectory} does not seem to
> >> work
> >> >> for
> >> >> >>>> all cases, it might work when used inside a plugin's
> >> 
> >> >> >>>> section but does not when used outside of plugins
> >> >> >>>>
> >> >> >>>> TIA
> >> >> >>>>
> >> >> >>>> Cheers,
> >> >> >>>> Andres
> >> >> >>>>
> >> >> >>>> ---
> >> >> >>>> Java Champion; Groovy Enthusiast
> >> >> >>>> http://andresalmiray.com
> >> >> >>>> http://www.linkedin.com/in/aalmiray
> >> >> >>>> --
> >> >> >>>> What goes up, must come down. Ask any system administrator.
> >> >> >>>> There are 10 types of people in the world: Those who understand
> >> >> binary,
> >> >> >>> and
> >> >> >>>> those who don't.
> >> >> >>>> To understand recursion, we must first understand recursion.
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> -
> >> >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >> <mailto:users-h...@maven.apache.org>
> >> >> >>>
> >> >> >>>
> >> >> >
> >> >> >
> >> >> >
> >> -
> >> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> > For additional commands, e-mail: users-h...@maven.apache.org
> >> <mailto:users-h...@maven.apache.org>
> >> >> >
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> <mailto:users-unsubscr...@maven.apache.org>
> >> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> <mailto:users-h...@maven.apache.org>
> >> >>
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> <mailto:users-unsubscr...@maven.apache.org>
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >> <mailto:users-h...@maven.apache.org>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Resolve root directory in a multi-project build

[Alexander Kriegisch]

> It seems the goal assumes that child modules sit in nested
> directories.

Well, that might be the case. I have never tested any other scenario
because this is how I organise my Maven projects. Neither am I a Maven
expert nor did I claim that my solution works for everybody in every
case. I just read a message on the list, remembered that I used to
struggle with a similar problem in the past and offered my solution
because it *works for me*. If it does not work for you because your
child modules are not in nested directories, I am sorry. I am more the
"convention over configuration" type, trying to keep it simple.

Regards
-- 
Alexander Kriegisch
https://scrum-master.de


Delany schrieb am 06.02.2021 21:07 (GMT +07:00):
> 
> 
> It seems the goal assumes that child modules sit in nested directories.
> 
> Unzip and run mvn validate in the root directory, and you'll see the root
> location for project sarek is incorrect.
> 
> Delany
> 
> 
> On Sat, 6 Feb 2021 at 14:28, Alexander Kriegisch  <mailto:alexan...@kriegisch.name> > wrote:
> 
>> Maybe I misunderstand you, but for me this works nicely in a module which
>> has a parent of type POM which has the root (also of type POM) as parent.
>> I.e. the root POM is the grandparent. I have no issues, as long as the
>> property is declared in the root as shown in the project I linked to.
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>> 
>> 
>> Delany schrieb am 06.02.2021 17:24 (GMT +07:00):
>> 
>> > This only works if the parent is the root. If you extend to a third
>> level
>> > of pom, it will report the rootlocation as the project directory.
>> >
>> > On Sat, 6 Feb 2021 at 04:22, Alexander Kriegisch
>> > <mailto:alexan...@kriegisch.name> >
>> > wrote:
>> >
>> >> I had some discussion with Karl Heinz Marbaise about
>> >> maven.multiModuleProjectDirectory a while ago (cannot remember where
>> >> exactly) and he strongly advised me not to use it as it is for
>> internal
>> >> use only. Even so, other tools such as IntelliJ IDEA use it
>> internally,
>> >> but not consequently, the situationis a bit messy.
>> >>
>> >> What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
>> >> (because of
>> >>
>> https://github.com/mojohaus/build-helper-maven-plugin/issues/48)
>> and
>> >> there to use the "rootlocation" goal. I am not sure if that is working
>> >> for you here because you said you need it somewhere in a plugin and I
>> >> just use it in my project's root POM. For IDEA I still need need
>> >> "-DprojectRootDir=..." in /.mvn/jvm.config, but from
>> the
>> >> command line it works, even when building from a module subdirectory.
>> >> Here is my POM (just search for the string "rootlocation" there, you
>> >> should find 4 places):
>> >>
>> >> https://github.com/SarekTest/Sarek/blob/master/pom.xml
>> >> --
>> >> Alexander Kriegisch
>> >> https://scrum-master.de
>> >>
>> >>
>> >> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
>> >>
>> >> > For me, no problem on Jenkins either (using "withMaven" pipeline
>> step).
>> >> > There used to be this issue:
>> >> https://issues.jenkins.io/browse/JENKINS-35335
>> >> > Which turned out to be a Maven bug which was fixed in 3.5.0:
>> >> > https://issues.apache.org/jira/browse/MNG-5889
>> >> >
>> >> > As far as MNG-5830 is concerned, I don't know what (special) setup
>> the
>> >> > affected people are using.
>> >> >
>> >> > I can only say/repeat that you need a .mvn directory to have the
>> >> > property point to your root directory.
>> >> > But even without .mvn, there should not be such an error message, so
>> IDK
>> >> > what's going on in those cases.
>> >> >
>> >> > Am 05.02.2021 um 22:13 schrieb Delany:
>> >> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or
>> >> these
>> >> >> other users
>> >> >>
>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>> >> >> Delany
>> >> >>
>> >> >>
>> >> >> On Fri, 5 Feb 2021, 22:25 Falko Modler, > <mailto:f.mod...@gmx.net> > wrote:
>> >> >>

Re: Resolve root directory in a multi-project build

[Michael Osipov]

Am 2021-02-05 um 18:52 schrieb Andres Almiray:

@Tamás: Right, should had explained the use case. I want to deploy all
artifacts to a local directory so that I can inspect everything which will
be deployed given certain conditions.
I managed to do that by forcing a stable, absolute directory as shown at

https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa579929211aac20bef3f5e00


This will not work in the future anymore: 
https://issues.apache.org/jira/browse/MNG-7047



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Delany]

It seems the goal assumes that child modules sit in nested directories.
Unzip and run mvn validate in the root directory, and you'll see the root
location for project sarek is incorrect.
Delany

On Sat, 6 Feb 2021 at 14:28, Alexander Kriegisch 
wrote:

> Maybe I misunderstand you, but for me this works nicely in a module which
> has a parent of type POM which has the root (also of type POM) as parent.
> I.e. the root POM is the grandparent. I have no issues, as long as the
> property is declared in the root as shown in the project I linked to.
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Delany schrieb am 06.02.2021 17:24 (GMT +07:00):
>
> > This only works if the parent is the root. If you extend to a third level
> > of pom, it will report the rootlocation as the project directory.
> >
> > On Sat, 6 Feb 2021 at 04:22, Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> I had some discussion with Karl Heinz Marbaise about
> >> maven.multiModuleProjectDirectory a while ago (cannot remember where
> >> exactly) and he strongly advised me not to use it as it is for internal
> >> use only. Even so, other tools such as IntelliJ IDEA use it internally,
> >> but not consequently, the situationis a bit messy.
> >>
> >> What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
> >> (because of
> >> https://github.com/mojohaus/build-helper-maven-plugin/issues/48) and
> >> there to use the "rootlocation" goal. I am not sure if that is working
> >> for you here because you said you need it somewhere in a plugin and I
> >> just use it in my project's root POM. For IDEA I still need need
> >> "-DprojectRootDir=..." in /.mvn/jvm.config, but from the
> >> command line it works, even when building from a module subdirectory.
> >> Here is my POM (just search for the string "rootlocation" there, you
> >> should find 4 places):
> >>
> >> https://github.com/SarekTest/Sarek/blob/master/pom.xml
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >>
> >> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
> >>
> >> > For me, no problem on Jenkins either (using "withMaven" pipeline
> step).
> >> > There used to be this issue:
> >> https://issues.jenkins.io/browse/JENKINS-35335
> >> > Which turned out to be a Maven bug which was fixed in 3.5.0:
> >> > https://issues.apache.org/jira/browse/MNG-5889
> >> >
> >> > As far as MNG-5830 is concerned, I don't know what (special) setup the
> >> > affected people are using.
> >> >
> >> > I can only say/repeat that you need a .mvn directory to have the
> >> > property point to your root directory.
> >> > But even without .mvn, there should not be such an error message, so
> IDK
> >> > what's going on in those cases.
> >> >
> >> > Am 05.02.2021 um 22:13 schrieb Delany:
> >> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or
> >> these
> >> >> other users
> >> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
> >> >> Delany
> >> >>
> >> >>
> >> >> On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:
> >> >>
> >> >>> I've been using maven.multiModuleProjectDirectory in various
> projects
> >> >>> (and have also seen it in others).
> >> >>> You'll need a .mvn directory in your root directory to make it work.
> >> >>>
> >> >>> PS: I know that there has been some controvery about this property
> but
> >> >>> well, it works! ;-)
> >> >>>
> >> >>> Cheers,
> >> >>> Falko
> >> >>>
> >> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> >> >>>> Hello everyone,
> >> >>>>
> >> >>>> Is there a way to reliably resolve the value of the root directory
> >> for a
> >> >>>> given multi-project build?
> >> >>>> Unfortunately ${session.executionRootDirectory} does not seem to
> work
> >> for
> >> >>>> all cases, it might work when used inside a plugin's
> 
> >> >>>> section but does not when used outs

Re: Resolve root directory in a multi-project build

[Alexander Kriegisch]

Maybe I misunderstand you, but for me this works nicely in a module which has a 
parent of type POM which has the root (also of type POM) as parent. I.e. the 
root POM is the grandparent. I have no issues, as long as the property is 
declared in the root as shown in the project I linked to.
-- 
Alexander Kriegisch
https://scrum-master.de


Delany schrieb am 06.02.2021 17:24 (GMT +07:00):

> This only works if the parent is the root. If you extend to a third level
> of pom, it will report the rootlocation as the project directory.
> 
> On Sat, 6 Feb 2021 at 04:22, Alexander Kriegisch 
> wrote:
> 
>> I had some discussion with Karl Heinz Marbaise about
>> maven.multiModuleProjectDirectory a while ago (cannot remember where
>> exactly) and he strongly advised me not to use it as it is for internal
>> use only. Even so, other tools such as IntelliJ IDEA use it internally,
>> but not consequently, the situationis a bit messy.
>>
>> What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
>> (because of
>> https://github.com/mojohaus/build-helper-maven-plugin/issues/48) and
>> there to use the "rootlocation" goal. I am not sure if that is working
>> for you here because you said you need it somewhere in a plugin and I
>> just use it in my project's root POM. For IDEA I still need need
>> "-DprojectRootDir=..." in /.mvn/jvm.config, but from the
>> command line it works, even when building from a module subdirectory.
>> Here is my POM (just search for the string "rootlocation" there, you
>> should find 4 places):
>>
>> https://github.com/SarekTest/Sarek/blob/master/pom.xml
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
>>
>> > For me, no problem on Jenkins either (using "withMaven" pipeline step).
>> > There used to be this issue:
>> https://issues.jenkins.io/browse/JENKINS-35335
>> > Which turned out to be a Maven bug which was fixed in 3.5.0:
>> > https://issues.apache.org/jira/browse/MNG-5889
>> >
>> > As far as MNG-5830 is concerned, I don't know what (special) setup the
>> > affected people are using.
>> >
>> > I can only say/repeat that you need a .mvn directory to have the
>> > property point to your root directory.
>> > But even without .mvn, there should not be such an error message, so IDK
>> > what's going on in those cases.
>> >
>> > Am 05.02.2021 um 22:13 schrieb Delany:
>> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or
>> these
>> >> other users
>> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>> >> Delany
>> >>
>> >>
>> >> On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:
>> >>
>> >>> I've been using maven.multiModuleProjectDirectory in various projects
>> >>> (and have also seen it in others).
>> >>> You'll need a .mvn directory in your root directory to make it work.
>> >>>
>> >>> PS: I know that there has been some controvery about this property but
>> >>> well, it works! ;-)
>> >>>
>> >>> Cheers,
>> >>> Falko
>> >>>
>> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
>> >>>> Hello everyone,
>> >>>>
>> >>>> Is there a way to reliably resolve the value of the root directory
>> for a
>> >>>> given multi-project build?
>> >>>> Unfortunately ${session.executionRootDirectory} does not seem to work
>> for
>> >>>> all cases, it might work when used inside a plugin's 
>> >>>> section but does not when used outside of plugins
>> >>>>
>> >>>> TIA
>> >>>>
>> >>>> Cheers,
>> >>>> Andres
>> >>>>
>> >>>> ---
>> >>>> Java Champion; Groovy Enthusiast
>> >>>> http://andresalmiray.com
>> >>>> http://www.linkedin.com/in/aalmiray
>> >>>> --
>> >>>> What goes up, must come down. Ask any system administrator.
>> >>>> There are 10 types of people in the world: Those who understand
>> binary,
>> >>> and
>> >>>> those who don't.
>> >>>> To understand recursion, we must first understand recursion.
>> >>>>
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> >>> For additional commands, e-mail: users-h...@maven.apache.org
>> >>>
>> >>>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Delany]

This only works if the parent is the root. If you extend to a third level
of pom, it will report the rootlocation as the project directory.
Delany

On Sat, 6 Feb 2021 at 04:22, Alexander Kriegisch 
wrote:

> I had some discussion with Karl Heinz Marbaise about
> maven.multiModuleProjectDirectory a while ago (cannot remember where
> exactly) and he strongly advised me not to use it as it is for internal
> use only. Even so, other tools such as IntelliJ IDEA use it internally,
> but not consequently, the situationis a bit messy.
>
> What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
> (because of
> https://github.com/mojohaus/build-helper-maven-plugin/issues/48) and
> there to use the "rootlocation" goal. I am not sure if that is working
> for you here because you said you need it somewhere in a plugin and I
> just use it in my project's root POM. For IDEA I still need need
> "-DprojectRootDir=..." in /.mvn/jvm.config, but from the
> command line it works, even when building from a module subdirectory.
> Here is my POM (just search for the string "rootlocation" there, you
> should find 4 places):
>
> https://github.com/SarekTest/Sarek/blob/master/pom.xml
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):
>
> > For me, no problem on Jenkins either (using "withMaven" pipeline step).
> > There used to be this issue:
> https://issues.jenkins.io/browse/JENKINS-35335
> > Which turned out to be a Maven bug which was fixed in 3.5.0:
> > https://issues.apache.org/jira/browse/MNG-5889
> >
> > As far as MNG-5830 is concerned, I don't know what (special) setup the
> > affected people are using.
> >
> > I can only say/repeat that you need a .mvn directory to have the
> > property point to your root directory.
> > But even without .mvn, there should not be such an error message, so IDK
> > what's going on in those cases.
> >
> > Am 05.02.2021 um 22:13 schrieb Delany:
> >> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or
> these
> >> other users
> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
> >> Delany
> >>
> >>
> >> On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:
> >>
> >>> I've been using maven.multiModuleProjectDirectory in various projects
> >>> (and have also seen it in others).
> >>> You'll need a .mvn directory in your root directory to make it work.
> >>>
> >>> PS: I know that there has been some controvery about this property but
> >>> well, it works! ;-)
> >>>
> >>> Cheers,
> >>> Falko
> >>>
> >>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> >>>> Hello everyone,
> >>>>
> >>>> Is there a way to reliably resolve the value of the root directory
> for a
> >>>> given multi-project build?
> >>>> Unfortunately ${session.executionRootDirectory} does not seem to work
> for
> >>>> all cases, it might work when used inside a plugin's 
> >>>> section but does not when used outside of plugins
> >>>>
> >>>> TIA
> >>>>
> >>>> Cheers,
> >>>> Andres
> >>>>
> >>>> ---
> >>>> Java Champion; Groovy Enthusiast
> >>>> http://andresalmiray.com
> >>>> http://www.linkedin.com/in/aalmiray
> >>>> --
> >>>> What goes up, must come down. Ask any system administrator.
> >>>> There are 10 types of people in the world: Those who understand
> binary,
> >>> and
> >>>> those who don't.
> >>>> To understand recursion, we must first understand recursion.
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Resolve root directory in a multi-project build

[Alexander Kriegisch]

I had some discussion with Karl Heinz Marbaise about
maven.multiModuleProjectDirectory a while ago (cannot remember where
exactly) and he strongly advised me not to use it as it is for internal
use only. Even so, other tools such as IntelliJ IDEA use it internally,
but not consequently, the situationis a bit messy.

What I ended up doing was to use Build Helper Maven Plugin >= 3.2.0
(because of
https://github.com/mojohaus/build-helper-maven-plugin/issues/48) and
there to use the "rootlocation" goal. I am not sure if that is working
for you here because you said you need it somewhere in a plugin and I
just use it in my project's root POM. For IDEA I still need need
"-DprojectRootDir=..." in /.mvn/jvm.config, but from the
command line it works, even when building from a module subdirectory.
Here is my POM (just search for the string "rootlocation" there, you
should find 4 places):

https://github.com/SarekTest/Sarek/blob/master/pom.xml
-- 
Alexander Kriegisch
https://scrum-master.de


Falko Modler schrieb am 06.02.2021 04:35 (GMT +07:00):

> For me, no problem on Jenkins either (using "withMaven" pipeline step).
> There used to be this issue: https://issues.jenkins.io/browse/JENKINS-35335
> Which turned out to be a Maven bug which was fixed in 3.5.0:
> https://issues.apache.org/jira/browse/MNG-5889
> 
> As far as MNG-5830 is concerned, I don't know what (special) setup the
> affected people are using.
> 
> I can only say/repeat that you need a .mvn directory to have the
> property point to your root directory.
> But even without .mvn, there should not be such an error message, so IDK
> what's going on in those cases.
> 
> Am 05.02.2021 um 22:13 schrieb Delany:
>> Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
>> other users
>> https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
>> Delany
>>
>>
>> On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:
>>
>>> I've been using maven.multiModuleProjectDirectory in various projects
>>> (and have also seen it in others).
>>> You'll need a .mvn directory in your root directory to make it work.
>>>
>>> PS: I know that there has been some controvery about this property but
>>> well, it works! ;-)
>>>
>>> Cheers,
>>> Falko
>>>
>>> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
>>>> Hello everyone,
>>>>
>>>> Is there a way to reliably resolve the value of the root directory for a
>>>> given multi-project build?
>>>> Unfortunately ${session.executionRootDirectory} does not seem to work for
>>>> all cases, it might work when used inside a plugin's 
>>>> section but does not when used outside of plugins
>>>>
>>>> TIA
>>>>
>>>> Cheers,
>>>> Andres
>>>>
>>>> ---
>>>> Java Champion; Groovy Enthusiast
>>>> http://andresalmiray.com
>>>> http://www.linkedin.com/in/aalmiray
>>>> --
>>>> What goes up, must come down. Ask any system administrator.
>>>> There are 10 types of people in the world: Those who understand binary,
>>> and
>>>> those who don't.
>>>> To understand recursion, we must first understand recursion.
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Falko Modler]

For me, no problem on Jenkins either (using "withMaven" pipeline step).
There used to be this issue: https://issues.jenkins.io/browse/JENKINS-35335
Which turned out to be a Maven bug which was fixed in 3.5.0:
https://issues.apache.org/jira/browse/MNG-5889

As far as MNG-5830 is concerned, I don't know what (special) setup the
affected people are using.

I can only say/repeat that you need a .mvn directory to have the
property point to your root directory.
But even without .mvn, there should not be such an error message, so IDK
what's going on in those cases.

Am 05.02.2021 um 22:13 schrieb Delany:

Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
other users
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
Delany


On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:


I've been using maven.multiModuleProjectDirectory in various projects
(and have also seen it in others).
You'll need a .mvn directory in your root directory to make it work.

PS: I know that there has been some controvery about this property but
well, it works! ;-)

Cheers,
Falko

Am 05.02.2021 um 17:03 schrieb Andres Almiray:

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary,

and

those who don't.
To understand recursion, we must first understand recursion.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Delany]

Maybe for you Falko, but not my Jenkins server with Maven 3.6.3, or these
other users
https://issues.apache.org/jira/plugins/servlet/mobile#issue/MNG-5830
Delany


On Fri, 5 Feb 2021, 22:25 Falko Modler,  wrote:

> I've been using maven.multiModuleProjectDirectory in various projects
> (and have also seen it in others).
> You'll need a .mvn directory in your root directory to make it work.
>
> PS: I know that there has been some controvery about this property but
> well, it works! ;-)
>
> Cheers,
> Falko
>
> Am 05.02.2021 um 17:03 schrieb Andres Almiray:
> > Hello everyone,
> >
> > Is there a way to reliably resolve the value of the root directory for a
> > given multi-project build?
> > Unfortunately ${session.executionRootDirectory} does not seem to work for
> > all cases, it might work when used inside a plugin's 
> > section but does not when used outside of plugins
> >
> > TIA
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Resolve root directory in a multi-project build

[Falko Modler]

I've been using maven.multiModuleProjectDirectory in various projects
(and have also seen it in others).
You'll need a .mvn directory in your root directory to make it work.

PS: I know that there has been some controvery about this property but
well, it works! ;-)

Cheers,
Falko

Am 05.02.2021 um 17:03 schrieb Andres Almiray:

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Resolve root directory in a multi-project build

[Tamás Cservenák]

Unsure will it help, but your description reminded me of nexus-staging
plugin, there we similarly "deploy locally" (defer actual deploy) to fire
the deployables at the project end:
https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/deploy/strategy/DeferredDeployStrategy.java

Is quite messy plugin :)

For example as "location" for the files we use "first module that has THIS
plugin defined" as it is "stable" enough (and we do not quite care where
the files are accumulated):
https://github.com/sonatype/nexus-maven-plugins/blob/master/staging/maven-plugin/src/main/java/org/sonatype/nexus/maven/staging/AbstractStagingMojo.java#L423

Hope this helps
T

On Fri, Feb 5, 2021 at 6:52 PM Andres Almiray  wrote:

> @Tamás: Right, should had explained the use case. I want to deploy all
> artifacts to a local directory so that I can inspect everything which will
> be deployed given certain conditions.
> I managed to do that by forcing a stable, absolute directory as shown at
>
>
> https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa579929211aac20bef3f5e00
>
> I'd prefer if the target directory be ${rootProject.build.directory} if
> there were such things as {$rootProject}, which is why I'm asking for a way
> to find out that value.
> As you may appreciate in that commit the value is used as part of
>  in a profile.
>
> @Lasse: I thought using that plugin would work but not in my case as the
> computed property is not available during model interpolation which is my
> case for setting the correct value in 
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist <
> lasse.k.lindqv...@gmail.com>
> wrote:
>
> > Using directory-maven-plugin and highest-basedir goal from it has worked
> > just fine for me.
> > https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
> >
> > pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> > kirjoitti:
> >
> > > Howdy,
> > > Grab somehow (you did not state from where if "outside of plugins")
> > > MavenSession, it has getExecutionRootDirectory method, BUT it may not
> be
> > > what you want, as one may use -f param for example...
> > >
> > > So, I'd shoot back: WHY do you need the root of a multi module build
> and
> > > FROM WHAT you need it? Extension?
> > > Are you sure you can expect maven is invoked from root? Could it be
> > simpler
> > > just to pass in as some parameter maybe, instead of doing all sorts of
> > > hoops and loops?
> > >
> > > T
> > >
> > > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> > wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > Is there a way to reliably resolve the value of the root directory
> for
> > a
> > > > given multi-project build?
> > > > Unfortunately ${session.executionRootDirectory} does not seem to work
> > for
> > > > all cases, it might work when used inside a plugin's 
> > > > section but does not when used outside of plugins
> > > >
> > > > TIA
> > > >
> > > > Cheers,
> > > > Andres
> > > >
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > http://andresalmiray.com
> > > > http://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> binary,
> > > and
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.
> > > >
> > >
> >
>

Re: Resolve root directory in a multi-project build

[Andres Almiray]

@Tamás: Right, should had explained the use case. I want to deploy all
artifacts to a local directory so that I can inspect everything which will
be deployed given certain conditions.
I managed to do that by forcing a stable, absolute directory as shown at

https://github.com/moditect/layrry/pull/90/commits/93472049fee1b5ffa579929211aac20bef3f5e00

I'd prefer if the target directory be ${rootProject.build.directory} if
there were such things as {$rootProject}, which is why I'm asking for a way
to find out that value.
As you may appreciate in that commit the value is used as part of
 in a profile.

@Lasse: I thought using that plugin would work but not in my case as the
computed property is not available during model interpolation which is my
case for setting the correct value in 

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.


On Fri, Feb 5, 2021 at 6:32 PM Lasse Lindqvist 
wrote:

> Using directory-maven-plugin and highest-basedir goal from it has worked
> just fine for me.
> https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal
>
> pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
> kirjoitti:
>
> > Howdy,
> > Grab somehow (you did not state from where if "outside of plugins")
> > MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> > what you want, as one may use -f param for example...
> >
> > So, I'd shoot back: WHY do you need the root of a multi module build and
> > FROM WHAT you need it? Extension?
> > Are you sure you can expect maven is invoked from root? Could it be
> simpler
> > just to pass in as some parameter maybe, instead of doing all sorts of
> > hoops and loops?
> >
> > T
> >
> > On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray 
> wrote:
> >
> > > Hello everyone,
> > >
> > > Is there a way to reliably resolve the value of the root directory for
> a
> > > given multi-project build?
> > > Unfortunately ${session.executionRootDirectory} does not seem to work
> for
> > > all cases, it might work when used inside a plugin's 
> > > section but does not when used outside of plugins
> > >
> > > TIA
> > >
> > > Cheers,
> > > Andres
> > >
> > > ---
> > > Java Champion; Groovy Enthusiast
> > > http://andresalmiray.com
> > > http://www.linkedin.com/in/aalmiray
> > > --
> > > What goes up, must come down. Ask any system administrator.
> > > There are 10 types of people in the world: Those who understand binary,
> > and
> > > those who don't.
> > > To understand recursion, we must first understand recursion.
> > >
> >
>

Re: Resolve root directory in a multi-project build

[Lasse Lindqvist]

Using directory-maven-plugin and highest-basedir goal from it has worked
just fine for me.
https://github.com/jdcasey/directory-maven-plugin#highest-basedir-goal

pe 5. helmik. 2021 klo 18.53 Tamás Cservenák (ta...@cservenak.net)
kirjoitti:

> Howdy,
> Grab somehow (you did not state from where if "outside of plugins")
> MavenSession, it has getExecutionRootDirectory method, BUT it may not be
> what you want, as one may use -f param for example...
>
> So, I'd shoot back: WHY do you need the root of a multi module build and
> FROM WHAT you need it? Extension?
> Are you sure you can expect maven is invoked from root? Could it be simpler
> just to pass in as some parameter maybe, instead of doing all sorts of
> hoops and loops?
>
> T
>
> On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray  wrote:
>
> > Hello everyone,
> >
> > Is there a way to reliably resolve the value of the root directory for a
> > given multi-project build?
> > Unfortunately ${session.executionRootDirectory} does not seem to work for
> > all cases, it might work when used inside a plugin's 
> > section but does not when used outside of plugins
> >
> > TIA
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
>

Re: Resolve root directory in a multi-project build

[Tamás Cservenák]

Howdy,
Grab somehow (you did not state from where if "outside of plugins")
MavenSession, it has getExecutionRootDirectory method, BUT it may not be
what you want, as one may use -f param for example...

So, I'd shoot back: WHY do you need the root of a multi module build and
FROM WHAT you need it? Extension?
Are you sure you can expect maven is invoked from root? Could it be simpler
just to pass in as some parameter maybe, instead of doing all sorts of
hoops and loops?

T

On Fri, Feb 5, 2021 at 5:04 PM Andres Almiray  wrote:

> Hello everyone,
>
> Is there a way to reliably resolve the value of the root directory for a
> given multi-project build?
> Unfortunately ${session.executionRootDirectory} does not seem to work for
> all cases, it might work when used inside a plugin's 
> section but does not when used outside of plugins
>
> TIA
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>

Resolve root directory in a multi-project build

[Andres Almiray]

Hello everyone,

Is there a way to reliably resolve the value of the root directory for a
given multi-project build?
Unfortunately ${session.executionRootDirectory} does not seem to work for
all cases, it might work when used inside a plugin's 
section but does not when used outside of plugins

TIA

Cheers,
Andres

---
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.

Site plugin, breadcrumbs, and inheritance in multi-project sites

[Russell Gold]

Hi,

I really like the ability to use this plugin to generate and deploy project 
sites, but I am having some problems making some things work:

1) I had ONCE gotten the breadcrumbs to show up. Now they don't. I am using the 
default version (3.0). 

2) Most of the project info pages (developers, scm, mailing lists, and so on), 
only really make sense for the project as a whole. Is there any way to avoid 
creating them for all of the sub-projects without a separate site.xml for each 
project? I tried disabling inheritance, but all that did was cause all of the 
subproject sites to revert to the default of displaying everything.

3) The docs speak of some reports as supporting aggregation. Is there a way to 
know (other than just experimenting) which reports do?

Thanks,
Russ
-
Come read my webnovel, Take a Lemon http://www.takealemon.com, 
and listen to the Misfile radio play 
http://www.gold-family.us/audio/misfile.html!

Re: One question about Multi Project Structure in MAVEN

[Wayne Fay]

 Thanks a lot !! That is all i wanted to confirm with you guys.

 So basically i have to use deploy plugin to deploy the stuffs at repository
 and over there i can define what components i want to publish or deployed.

 And locally i will have all those copy available by executing mvn install.

Do be aware that if you just use the same POM files in the deployment
that you use to build, you may end up with Maven complaining about
missing artifacts since you are not uploading all of the files, and
you may have configured them as dependencies for some of your
projects.

So you might need to make another set of POM files just for the
deployment and remove these 2 modules and all references to them as
dependencies from the POMs.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: One question about Multi Project Structure in MAVEN

[Thiessen, Todd (Todd)]

Ya. Installing to local and overriding how the artifacts get deployed is asking 
for trouble.

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Wednesday, February 22, 2012 5:06 AM
 To: Maven Users List
 Subject: Re: One question about Multi Project Structure in MAVEN
 
  Thanks a lot !! That is all i wanted to confirm with you guys.
 
  So basically i have to use deploy plugin to deploy the stuffs at
 repository
  and over there i can define what components i want to publish or
 deployed.
 
  And locally i will have all those copy available by executing mvn
 install.
 
 Do be aware that if you just use the same POM files in the deployment
 that you use to build, you may end up with Maven complaining about
 missing artifacts since you are not uploading all of the files, and
 you may have configured them as dependencies for some of your
 projects.
 
 So you might need to make another set of POM files just for the
 deployment and remove these 2 modules and all references to them as
 dependencies from the POMs.
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

RE: One question about Multi Project Structure in MAVEN

[Chad.Davis]

 So basically i have to use deploy plugin to deploy the stuffs at repository 
 and
 over there i can define what components i want to publish or deployed.

Sometimes the definitions are kind of vague in the maven literature.  A 
repository is simply the thing that holds your maven artifacts.  There's your 
local one, .m2, and  zero to many remote ones.  Deploy means put the 
artifact in a remote repository.  Install means put it in your local one.  
The remote ones can be public, or private.  You most assuredly want a private 
one.  At some point, you might also deploy a publicly distributable artifact to 
a public repository, like maven central, so the public can get to it.  

 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: One question about Multi Project Structure in MAVEN

[Matt Walsh]

Put this in your pojo and java poms:

plugin
 
artifactIdmaven-deploy-plugin/artifactId
configuration
skiptrue/skip
/configuration
/plugin

It will still install to local, but won't deploy to remote.

 -Original Message-
 From: Daivish Shah [mailto:daivish.s...@gmail.com]
 Sent: Tuesday, February 21, 2012 1:09 PM
 To: Maven Users List
 Subject: One question about Multi Project Structure in MAVEN
 
 Hi,
 
 I have a project with following structure.
 
 maven-main-project
maven-ear
maven-ejb
maven-schema
maven-pojo
maven-java
 
 This is my project structure for multi-module project. And now if i
 don't
 want to publish any artifacts outside of this project. I mean to say i
 don't want to publish any artifactory/nexus/archiva repository copy
for
 other people to use it.
 
 *Use Case :*
 
 Here my maven-ear is part of the maven-main-project and that's the
only
 module which use the maven-pojo and maven-java generated artifacts and
 which i don't want to publish it on repository but just want to use it
 for
 building the EAR.
 
 How can i disable those 2 (maven-pojo and maven-java) projects not to
 publish artifacts at repository level.
 
 Looking for some solution on this, As don't want to create unncessary
 artifacts on repository as nobody is going to use it other then my own
 Main
 project EAR project.
 
 Thanks.

__
This message, including any attachments, is confidential and contains 
information intended only for the person(s) named above. Any other 
distribution, copying or disclosure is strictly prohibited. If you are not the 
intended recipient or have received this message in error, please notify us 
immediately by reply email and permanently delete the original transmission 
from all of your systems and hard drives, including any attachments, without 
making a copy.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

One question about Multi Project Structure in MAVEN

[Daivish Shah]

Hi,

I have a project with following structure.

maven-main-project
   maven-ear
   maven-ejb
   maven-schema
   maven-pojo
   maven-java

This is my project structure for multi-module project. And now if i don't
want to publish any artifacts outside of this project. I mean to say i
don't want to publish any artifactory/nexus/archiva repository copy for
other people to use it.

*Use Case :*

Here my maven-ear is part of the maven-main-project and that's the only
module which use the maven-pojo and maven-java generated artifacts and
which i don't want to publish it on repository but just want to use it for
building the EAR.

How can i disable those 2 (maven-pojo and maven-java) projects not to
publish artifacts at repository level.

Looking for some solution on this, As don't want to create unncessary
artifacts on repository as nobody is going to use it other then my own Main
project EAR project.

Thanks.

RE: One question about Multi Project Structure in MAVEN

[Bobbepalli, Purnachandrarao]

Please have a look on the following


build
plugins
  plugin
artifactIdmaven-war-plugin/artifactId
version2.2/version
configuration
  
  packagingExcludesWEB-INF/lib/*.jar/packagingExcludes
  
/configuration
  /plugin
/plugins
  /build

-Original Message-
From: Daivish Shah [mailto:daivish.s...@gmail.com] 
Sent: Tuesday, February 21, 2012 3:09 PM
To: Maven Users List
Subject: One question about Multi Project Structure in MAVEN

Hi,

I have a project with following structure.

maven-main-project
   maven-ear
   maven-ejb
   maven-schema
   maven-pojo
   maven-java

This is my project structure for multi-module project. And now if i don't want 
to publish any artifacts outside of this project. I mean to say i don't want to 
publish any artifactory/nexus/archiva repository copy for other people to use 
it.

*Use Case :*

Here my maven-ear is part of the maven-main-project and that's the only module 
which use the maven-pojo and maven-java generated artifacts and which i don't 
want to publish it on repository but just want to use it for building the EAR.

How can i disable those 2 (maven-pojo and maven-java) projects not to publish 
artifacts at repository level.

Looking for some solution on this, As don't want to create unncessary artifacts 
on repository as nobody is going to use it other then my own Main project EAR 
project.

Thanks.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase  Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Wayne Fay]

 How can i disable those 2 (maven-pojo and maven-java) projects not to
 publish artifacts at repository level.

You can perhaps try to do this using deploy:deploy-file to only deploy
the specific files/artifacts you want deployed but not the entire
project.

 Looking for some solution on this, As don't want to create unncessary
 artifacts on repository as nobody is going to use it other then my own Main
 project EAR project.

This isn't sufficient justification for these efforts, IMO.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Daivish Shah]

HI wayne,

I think deploy approach is the correct one looks like in this case.

But when we execute MVN INSTALL it will generate all artifacts locally or
on our local cache correct ?

Thanks.


On Tue, Feb 21, 2012 at 12:50 PM, Wayne Fay wayne...@gmail.com wrote:

  How can i disable those 2 (maven-pojo and maven-java) projects not to
  publish artifacts at repository level.

 You can perhaps try to do this using deploy:deploy-file to only deploy
 the specific files/artifacts you want deployed but not the entire
 project.

  Looking for some solution on this, As don't want to create unncessary
  artifacts on repository as nobody is going to use it other then my own
 Main
  project EAR project.

 This isn't sufficient justification for these efforts, IMO.

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Ron Wheeler]

On 21/02/2012 3:50 PM, Wayne Fay wrote:

How can i disable those 2 (maven-pojo and maven-java) projects not to
publish artifacts at repository level.

You can perhaps try to do this using deploy:deploy-file to only deploy
the specific files/artifacts you want deployed but not the entire
project.


Looking for some solution on this, As don't want to create unncessary
artifacts on repository as nobody is going to use it other then my own Main
project EAR project.

This isn't sufficient justification for these efforts, IMO.
+1 Unless you are building a personal toy that will never go into 
production use and will never require maintenance.
If it is a serious project, it should be properly structured and 
everything required to build and maintain it should be in a repo of some 
kind - sources in SCM, jars in Maven Repo.
If you do not put the jars in a repo, then you may have to check out a 
bunch of sources to rebuild something that is not changing in order to 
update a configuration file.



Ron



Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Wayne Fay]

 But when we execute MVN INSTALL it will generate all artifacts locally or
 on our local cache correct ?

Yes it will generate all artifacts locally in your local
~/.m2/repository directory or where ever you have configured the
localRepository in settings.xml.

It is not possible to turn off generation of the files into this directory.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Ron Wheeler]

On 21/02/2012 3:09 PM, Daivish Shah wrote:

Hi,

I have a project with following structure.

maven-main-project
maven-ear
maven-ejb
maven-schema
maven-pojo
maven-java

This is my project structure for multi-module project. And now if i don't
want to publish any artifacts outside of this project. I mean to say i
don't want to publish any artifactory/nexus/archiva repository copy for
other people to use it.

Other people being your coworkers and co-developers?
A Maven repo is a private place.
You control who has access.
It is normally only for your team (even if you are the whole team).

If you are using Maven you need a repo. We went for 2 years without one 
and it was a really stupid oversight on our part.
It greatly simplifies your life and makes Maven much easier to 
understand and makes it much easier to do the right things.

Publish does not mean to the whole world.

Ron


*Use Case :*

Here my maven-ear is part of the maven-main-project and that's the only
module which use the maven-pojo and maven-java generated artifacts and
which i don't want to publish it on repository but just want to use it for
building the EAR.

How can i disable those 2 (maven-pojo and maven-java) projects not to
publish artifacts at repository level.

Looking for some solution on this, As don't want to create unncessary
artifacts on repository as nobody is going to use it other then my own Main
project EAR project.

Thanks.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Curtis Rueden]

 Publish does not mean to the whole world.


Well, it *can*, if that's what you want... ;-)

-Curtis


On Tue, Feb 21, 2012 at 4:25 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 On 21/02/2012 3:09 PM, Daivish Shah wrote:

 Hi,

 I have a project with following structure.

 maven-main-project
maven-ear
maven-ejb
maven-schema
maven-pojo
maven-java

 This is my project structure for multi-module project. And now if i don't
 want to publish any artifacts outside of this project. I mean to say i
 don't want to publish any artifactory/nexus/archiva repository copy for
 other people to use it.

 Other people being your coworkers and co-developers?
 A Maven repo is a private place.
 You control who has access.
 It is normally only for your team (even if you are the whole team).

 If you are using Maven you need a repo. We went for 2 years without one
 and it was a really stupid oversight on our part.
 It greatly simplifies your life and makes Maven much easier to understand
 and makes it much easier to do the right things.
 Publish does not mean to the whole world.

 Ron


  *Use Case :*

 Here my maven-ear is part of the maven-main-project and that's the only
 module which use the maven-pojo and maven-java generated artifacts and
 which i don't want to publish it on repository but just want to use it for
 building the EAR.

 How can i disable those 2 (maven-pojo and maven-java) projects not to
 publish artifacts at repository level.

 Looking for some solution on this, As don't want to create unncessary
 artifacts on repository as nobody is going to use it other then my own
 Main
 project EAR project.

 Thanks.



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102




 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: One question about Multi Project Structure in MAVEN

[Daivish Shah]

Hi Wayne,

Thanks a lot !! That is all i wanted to confirm with you guys.

So basically i have to use deploy plugin to deploy the stuffs at repository
and over there i can define what components i want to publish or deployed.

And locally i will have all those copy available by executing mvn install.

This is what i wanted.

Thanks.


On Tue, Feb 21, 2012 at 2:20 PM, Wayne Fay wayne...@gmail.com wrote:

  But when we execute MVN INSTALL it will generate all artifacts locally or
  on our local cache correct ?

 Yes it will generate all artifacts locally in your local
 ~/.m2/repository directory or where ever you have configured the
 localRepository in settings.xml.

 It is not possible to turn off generation of the files into this directory.

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi project release without SCM

[tbee]

Nevermind: versions:update-child-modules
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p512572.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi project release without SCM

[tbee]

The concept is what I am looking for, but it doesn't do exactly what I need. 

For example: the parent pom has version 1.11-SNAPSHOT, all child poms refer
to this version. If I want to release 1.11, I remove -SNAPSHOT in the
parent pom and do an versions:update-parent. But the 1.11 pom is not
released yet, so this action will replace all child 1.11-SNAPSHOT references
with 1.10 instead of 1.11. 
What I would need to do is:
- replace 1.11-SNAPSHOT with 1.11 in parent pom
- run release on the parent (childeren will still refer to 1.11-SNAPSHOT)
- run versions:update-parent
- run release again

But that does not work, because then I will release the 1.11 parent twice,
which will fail.

I'll see if I can find another way to get this working with this plugin.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p512571.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi project release without SCM

[Stephen Connolly]

or try

mvn versions:set -DnewVersion=1.11

On 2 July 2010 08:56, tbee t...@tbee.org wrote:


 Nevermind: versions:update-child-modules
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p512572.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi project release without SCM

[Anders Hammar]

Yes. The Versions Maven Plugin (
http://mojo.codehaus.org/versions-maven-plugin/) could help you.

/Anders

On Tue, Jun 29, 2010 at 20:13, tbee t...@tbee.org wrote:


 I have a good working multiproject release but no SCM setup yet (I'm
 waiting
 for BRZ to be installed to replace CVS).

 Currently the parent pom has version 1.10-SNAPSHOT configured. The
 component's pom refer to this pom. If I want to release 1.10, do I need to
 modify all the pom's and remove -SNAPSHOT?

 release:prepare does not work because of the missing SCM.
 --
 View this message in context:
 http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p511922.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Multi project release without SCM

[tbee]

I have a good working multiproject release but no SCM setup yet (I'm waiting
for BRZ to be installed to replace CVS).

Currently the parent pom has version 1.10-SNAPSHOT configured. The
component's pom refer to this pom. If I want to release 1.10, do I need to
modify all the pom's and remove -SNAPSHOT?

release:prepare does not work because of the missing SCM.
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p511922.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Controlling javadoc packages in large multi project reactor build

[kelvin goodson]

I want to produce selective javadoc in a project where we are in the
process of defining what is SPI.  The packages containing SPI are
currently distributed amongst the projects in a non-ideal way.

I have tried using the excludePackageNames config element, but it
seems to be failing to handle the large number of packages I want to
exclude.  I have over 100 packages to exclude, and wildcards in the
excludePackageNames value will not reduce the the string length of
this value considerably.

I looked for documentation to clarify excludePackageNames, but did not
find what I need, so I experimented [1] and found that
a) if multiple excludePackageNames elements are included in the config
then only the last value takes effect
b) the value of the excludePackageNames element can not be split over
multiple lines

Is this what you would expect?
Are there other ways of configuring this plugin for selective javadoccing?

[1] https://svn.apache.org/repos/asf/tuscany/sandbox/kgoodson/testroot/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Controlling javadoc packages in large multi project reactor build

[Wendy Smoak]

On Sat, May 29, 2010 at 7:01 PM, kelvin goodson
kelvingood...@apache.org wrote:

 I looked for documentation to clarify excludePackageNames, but did not
 find what I need,

Does this help?
http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#excludePackageNames

 so I experimented [1] and found that
 a) if multiple excludePackageNames elements are included in the config
 then only the last value takes effect

Expected, or perhaps it should throw an error.  It's a single element.
 Somewhat unintuitive, since in other places when there's a plural
tag, you are meant to put multiple singular ones inside:
excludePackageNamesexcludePackageName.../excludePackageName and
so on.

 b) the value of the excludePackageNames element can not be split over
 multiple lines

Doc says separate with commas, colons or semicolons, so I'd just keep
typing... (no hard return, iow.)

No idea if there's a limit though, I haven't tried it.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Controlling javadoc packages in large multi project reactor build

[Martin Gainty]

try colon
 javadoc -d /home/html -sourcepath /home/src -subpackages java -exclude 
java.net:java.lang

 

http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#runningjavadoc

 

hth
Martin
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.



 

 From: wsm...@gmail.com
 Date: Sat, 29 May 2010 19:18:09 -0400
 Subject: Re: Controlling javadoc packages in large multi project reactor build
 To: users@maven.apache.org
 
 On Sat, May 29, 2010 at 7:01 PM, kelvin goodson
 kelvingood...@apache.org wrote:
 
  I looked for documentation to clarify excludePackageNames, but did not
  find what I need,
 
 Does this help?
 http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#excludePackageNames
 
  so I experimented [1] and found that
  a) if multiple excludePackageNames elements are included in the config
  then only the last value takes effect
 
 Expected, or perhaps it should throw an error. It's a single element.
 Somewhat unintuitive, since in other places when there's a plural
 tag, you are meant to put multiple singular ones inside:
 excludePackageNamesexcludePackageName.../excludePackageName and
 so on.
 
  b) the value of the excludePackageNames element can not be split over
  multiple lines
 
 Doc says separate with commas, colons or semicolons, so I'd just keep
 typing... (no hard return, iow.)
 
 No idea if there's a limit though, I haven't tried it.
 
 -- 
 Wendy
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
  
_
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

Can't get multi-project javadocs generated based on documentation

[Bernstein, Brian J.]

Hi,
We have a project that generates several smaller projects that are
individually versioned, released, etc. as they're common components.

We have one project that is a client library for a larger system and it
depends on a few of these smaller projects. I'm having a hard time
trying to figure out how to get a complete javadoc generated where it
doesn't have dead references to other projects.

For example, let's say the project is clientAPI. This project depends
on dataObjectsLib (a shared component with other projects, e.g. a
server component).

I can generate clientAPI's javadocs, but I see dead links like:

com.foo.dataobjectslib.DataTable getDataTable()

.. In that the return object is not a hyperlink to the DataTable object.

From what I understood from reading the documentation, if I had
dataObjectsLib's pom configured so that it generates source bundles and
javadoc-resources.jar, the clientAPI should be able to pick up on these
files and use those sources to generate a javadoc that not only has
clientAPI's docs, but also dataObjectsLib's docs and no dead links
like the DataTable result above.

The dataObjectsLib target contains:
dataObjectsLib-1.2.3-SNAPSHOT-javadoc-resources.jar
dataObjectsLib-1.2.3-SNAPSHOT-javadoc.jar
dataObjectsLib-1.2.3-SNAPSHOT-sources.jar
dataObjectsLib-1.2.3-SNAPSHOT.jar

(though javadoc-resources only contains two files; not sure what that is
all about).

The clientAPI seems to pick up the javadoc-resources, but doesn't appear
to generate the @options and @packages for javadoc.bat to also include
the com.foo.dataobjectslib.* package to ultimately not create dead
links.

I am not excluding any package dependencies at the moment and I do have
includeDependencySources set to true. I've tried numerous aggregate
forms but nothing seems to work.

Unfortunately, the documentation isn't 100% clear if my expected
behavior is how its supposed to work and further the documentation and
examples don't really point out much about my kind of situation. I
really don't want to resort to specifying long lists of source
directories relatlively pointing to other project's source directories
since that breaks the whole idea of maven's dependency controls!

Any ideas?

-bjb

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

Re: Multi-project organization

[Josh Stone]

Thanks for the responses Ron and everyone. I'm going to take back all of
your input and try to apply it.

Josh

On Sun, Jan 24, 2010 at 5:44 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 I am still new to Maven after using it for 3 years with 20+ projects.
 I recently installed the Nexus repository manager, community (free)
 version.
 It is a great help and  I would heartily recommend installing it if you are
 moving to Maven.
 It makes the whole process much more visible.

 We use the Springsource version of Eclipse which supports Maven very well -
 great POM editor.

 You can take my advice with a grain of salt. There are others with more
 experience and understanding.
 1) I would set up projects for each of the jars that you need to make.

 2) I would set up individual projects that create the POM files to describe
 the overall dependencies.
 These POMS can be used as dependencies in your applications to pick up the
 right version of your jars.
 I would also build POM projects for dependencies from third parties
 We have POM files that have compile scope dependencies on all of the
 shared jars that we get from third parties (Apache, javax, etc). These are
 referenced by the POMs that produce war files, as provided so that the
 jars are available for compiling but are not in the war files since we
 install the jars in the container's (Tomcat) shared library folder.
 We have several POMs describing families of 3rd party jars. One for
 spring-hibernate-mysql-tomcat for our basic technology stack, one for
 utilities, mostly Apache stuff and one for the Apace CXF Web Service
 libraries for our projects that are Web Services.

 3) Put the version numbers of the jars in the POM file of the dependent
 POMs so that when you have a dependency on a pom-shared-utility pom you get
 a full set of consistent jars for the version of your application. This
 reduces the potential for errors by developers. Once you start on a new
 version of your application and decide on a set of libraries that will be
 used, you define the version in the appropriate POM and the developer only
 have to set the dependency on the version of the group POM to get all the
 right versions.

 4) Use SNAPSOTS properly with your development process. Nexus helps with
 this by enforcing disciplines.

 5) Do not get discouraged by the terrible documentation. There is lots of
 it but it is very much inside the beltway. Accurate but too hard to
 understand. The software works very well and there are a lot of tools to
 make maven do whatever you need.

 6) Ask here. The community is really helpful if occasionally too cryptic.

 Good luck, you have made a good decision to get properly structured using
 maven

 Ron


 Josh Stone wrote:

 I'm in the process of moving our company over to Maven, and am not sure of
 the best way to organize our existing projects. Currently our application
 stack consists of two dozen projects with various dependencies on each
 other. For projects that a developer is actively working on, these should
 be
 built locally from source whereas dependencies on all other projects
 should
 be resolved from jars in the maven repository. I've setup 1 pom for each
 project, but there are a few things I'm not sure about:

 Since any given project could be built locally from source or from jars,
 do
 I need two poms for each project, one to serve as a build pom and one to
 reference jars?
 Should I store the pom(s) in SCM along with having them in the maven
 repository?

 Any tips are appreciated,
 Josh





 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Multi-project organization

[Josh Stone]

I'm in the process of moving our company over to Maven, and am not sure of
the best way to organize our existing projects. Currently our application
stack consists of two dozen projects with various dependencies on each
other. For projects that a developer is actively working on, these should be
built locally from source whereas dependencies on all other projects should
be resolved from jars in the maven repository. I've setup 1 pom for each
project, but there are a few things I'm not sure about:

Since any given project could be built locally from source or from jars, do
I need two poms for each project, one to serve as a build pom and one to
reference jars?
Should I store the pom(s) in SCM along with having them in the maven
repository?

Any tips are appreciated,
Josh

Re: Multi-project organization

[Wendy Smoak]

On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com wrote:

 Since any given project could be built locally from source or from jars, do
 I need two poms for each project, one to serve as a build pom and one to
 reference jars?

No, you don't need two poms.  What do you mean by building from source
or from jars?  The source jars in the Maven repo are generally for
IDEs to use when debugging.  The pom that builds the project will
usually have dependencies on other jars.

 Should I store the pom(s) in SCM along with having them in the maven
 repository?

Yes, the pom belongs in scm along with the project source code.  This
is the same pom that gets deployed to the Maven repo when you do a
release.

Ideally the conversion will go bottom up, so that you convert your
lower level utility jars, release them, then move up to the projects
that depend on them.  To bootstrap you may want to deploy some
existing jars to the your internal Maven repo for projects to use.
For those you'll need to construct a pom or let Maven generate a
minimal one.

I'm not sure I understood the question, so ask again if that's not
what you were looking for.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-project organization

[Manuel Grau]

Let me introduce what I'm doing in my company. We have some
maven-java-simple projects used in other projects. These projects are
considered common code. Then, our projects are all maven-j2ee-simple
projects. These projects have a root pom. Then, we have inside a folder
called servlets, with at least a webapp inside. Then, a projects folder,
with some jar modules inside. Finally, we have the ear folder, with only a
project that generates an ear. We have another folder, called ejbs, to
create ejbs inside, but, as we are using Spring framework, we don't have any
ejb yet. This is the structure of a project:

/-root-project/
-/ear/
-/projects/
-/servlets/
-/ejbs/

2010/1/24 Josh Stone pacesysj...@gmail.com

 I'm in the process of moving our company over to Maven, and am not sure of
 the best way to organize our existing projects. Currently our application
 stack consists of two dozen projects with various dependencies on each
 other. For projects that a developer is actively working on, these should
 be
 built locally from source whereas dependencies on all other projects should
 be resolved from jars in the maven repository. I've setup 1 pom for each
 project, but there are a few things I'm not sure about:

 Since any given project could be built locally from source or from jars, do
 I need two poms for each project, one to serve as a build pom and one to
 reference jars?
 Should I store the pom(s) in SCM along with having them in the maven
 repository?

 Any tips are appreciated,
 Josh




-- 
Everything should be made as simple as possible, but not simpler Albert
Einstein

Re: Multi-project organization

[Josh Stone]

Thanks for the response. Allow me to try and explain again:

Since our stack is so large and consists of many projects, developers don't
build the entire stack from source, they only build the specific projects
that they work on. Dependencies on other projects in our stack should be
resolved from jars that are built by our continuous integration box and
deployed to the maven repository. So if I'm actively developing only two
projects I'd only want to build those two projects from source. All the
other project dependencies I'd want to be pulled in from the maven
repository as jars. I'm not sure how to manage this...

Josh

On Sun, Jan 24, 2010 at 2:03 PM, Wendy Smoak wsm...@gmail.com wrote:

 On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com wrote:

  Since any given project could be built locally from source or from jars,
 do
  I need two poms for each project, one to serve as a build pom and one
 to
  reference jars?

 No, you don't need two poms.  What do you mean by building from source
 or from jars?  The source jars in the Maven repo are generally for
 IDEs to use when debugging.  The pom that builds the project will
 usually have dependencies on other jars.

  Should I store the pom(s) in SCM along with having them in the maven
  repository?

 Yes, the pom belongs in scm along with the project source code.  This
 is the same pom that gets deployed to the Maven repo when you do a
 release.

 Ideally the conversion will go bottom up, so that you convert your
 lower level utility jars, release them, then move up to the projects
 that depend on them.  To bootstrap you may want to deploy some
 existing jars to the your internal Maven repo for projects to use.
 For those you'll need to construct a pom or let Maven generate a
 minimal one.

 I'm not sure I understood the question, so ask again if that's not
 what you were looking for.

 --
 Wendy

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-project organization

[Manuel Grau]

Is exactly what I'm doing. I only build the project I'm working on. The
dependencies are pulled from my local repository. Run mvn clean package
install from your jars. Only if you change any of them, you execute mvn
package install. I'm not sure if you understand me.

2010/1/24 Josh Stone pacesysj...@gmail.com

 Thanks for the response. Allow me to try and explain again:

 Since our stack is so large and consists of many projects, developers don't
 build the entire stack from source, they only build the specific projects
 that they work on. Dependencies on other projects in our stack should be
 resolved from jars that are built by our continuous integration box and
 deployed to the maven repository. So if I'm actively developing only two
 projects I'd only want to build those two projects from source. All the
 other project dependencies I'd want to be pulled in from the maven
 repository as jars. I'm not sure how to manage this...

 Josh

 On Sun, Jan 24, 2010 at 2:03 PM, Wendy Smoak wsm...@gmail.com wrote:

  On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com
 wrote:
 
   Since any given project could be built locally from source or from
 jars,
  do
   I need two poms for each project, one to serve as a build pom and one
  to
   reference jars?
 
  No, you don't need two poms.  What do you mean by building from source
  or from jars?  The source jars in the Maven repo are generally for
  IDEs to use when debugging.  The pom that builds the project will
  usually have dependencies on other jars.
 
   Should I store the pom(s) in SCM along with having them in the maven
   repository?
 
  Yes, the pom belongs in scm along with the project source code.  This
  is the same pom that gets deployed to the Maven repo when you do a
  release.
 
  Ideally the conversion will go bottom up, so that you convert your
  lower level utility jars, release them, then move up to the projects
  that depend on them.  To bootstrap you may want to deploy some
  existing jars to the your internal Maven repo for projects to use.
  For those you'll need to construct a pom or let Maven generate a
  minimal one.
 
  I'm not sure I understood the question, so ask again if that's not
  what you were looking for.
 
  --
  Wendy
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 




-- 
Everything should be made as simple as possible, but not simpler Albert
Einstein

RE: Multi-project organization

[Jeff Jensen]

Just configure Maven settings.xml file to pull from the organization repo
(the one populated by CI builds).
The deps in the projects you are working on will get pulled from the repo.


-Original Message-
From: Josh Stone [mailto:pacesysj...@gmail.com] 
Sent: Sunday, January 24, 2010 4:18 PM
To: Maven Users List
Subject: Re: Multi-project organization

Thanks for the response. Allow me to try and explain again:

Since our stack is so large and consists of many projects, developers don't
build the entire stack from source, they only build the specific projects
that they work on. Dependencies on other projects in our stack should be
resolved from jars that are built by our continuous integration box and
deployed to the maven repository. So if I'm actively developing only two
projects I'd only want to build those two projects from source. All the
other project dependencies I'd want to be pulled in from the maven
repository as jars. I'm not sure how to manage this...

Josh

On Sun, Jan 24, 2010 at 2:03 PM, Wendy Smoak wsm...@gmail.com wrote:

 On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com wrote:

  Since any given project could be built locally from source or from jars,
 do
  I need two poms for each project, one to serve as a build pom and one
 to
  reference jars?

 No, you don't need two poms.  What do you mean by building from source
 or from jars?  The source jars in the Maven repo are generally for
 IDEs to use when debugging.  The pom that builds the project will
 usually have dependencies on other jars.

  Should I store the pom(s) in SCM along with having them in the maven
  repository?

 Yes, the pom belongs in scm along with the project source code.  This
 is the same pom that gets deployed to the Maven repo when you do a
 release.

 Ideally the conversion will go bottom up, so that you convert your
 lower level utility jars, release them, then move up to the projects
 that depend on them.  To bootstrap you may want to deploy some
 existing jars to the your internal Maven repo for projects to use.
 For those you'll need to construct a pom or let Maven generate a
 minimal one.

 I'm not sure I understood the question, so ask again if that's not
 what you were looking for.

 --
 Wendy

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-project organization

[Josh Stone]

I think I get what you are saying. So each project should have dependencies
on its jars, and I just choose to build each project if I want, otherwise
the dependencies will be resolved from the jars.

josh

On Sun, Jan 24, 2010 at 2:28 PM, Manuel Grau mang...@gmail.com wrote:

 Is exactly what I'm doing. I only build the project I'm working on. The
 dependencies are pulled from my local repository. Run mvn clean package
 install from your jars. Only if you change any of them, you execute mvn
 package install. I'm not sure if you understand me.

 2010/1/24 Josh Stone pacesysj...@gmail.com

  Thanks for the response. Allow me to try and explain again:
 
  Since our stack is so large and consists of many projects, developers
 don't
  build the entire stack from source, they only build the specific projects
  that they work on. Dependencies on other projects in our stack should be
  resolved from jars that are built by our continuous integration box and
  deployed to the maven repository. So if I'm actively developing only two
  projects I'd only want to build those two projects from source. All the
  other project dependencies I'd want to be pulled in from the maven
  repository as jars. I'm not sure how to manage this...
 
  Josh
 
  On Sun, Jan 24, 2010 at 2:03 PM, Wendy Smoak wsm...@gmail.com wrote:
 
   On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com
  wrote:
  
Since any given project could be built locally from source or from
  jars,
   do
I need two poms for each project, one to serve as a build pom and
 one
   to
reference jars?
  
   No, you don't need two poms.  What do you mean by building from source
   or from jars?  The source jars in the Maven repo are generally for
   IDEs to use when debugging.  The pom that builds the project will
   usually have dependencies on other jars.
  
Should I store the pom(s) in SCM along with having them in the maven
repository?
  
   Yes, the pom belongs in scm along with the project source code.  This
   is the same pom that gets deployed to the Maven repo when you do a
   release.
  
   Ideally the conversion will go bottom up, so that you convert your
   lower level utility jars, release them, then move up to the projects
   that depend on them.  To bootstrap you may want to deploy some
   existing jars to the your internal Maven repo for projects to use.
   For those you'll need to construct a pom or let Maven generate a
   minimal one.
  
   I'm not sure I understood the question, so ask again if that's not
   what you were looking for.
  
   --
   Wendy
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 



 --
 Everything should be made as simple as possible, but not simpler Albert
 Einstein

Re: Multi-project organization

[Stephen Connolly]

2010/1/24 Manuel Grau mang...@gmail.com

 Is exactly what I'm doing. I only build the project I'm working on. The
 dependencies are pulled from my local repository. Run mvn clean package
 install from your jars.


FYI, since install includes all the phases up to install, and package is 
install, mvn package install will build everything twice

if you want to install in the local repository, just mvn install will
suffice

-Stephen


 Only if you change any of them, you execute mvn
 package install. I'm not sure if you understand me.

 2010/1/24 Josh Stone pacesysj...@gmail.com

  Thanks for the response. Allow me to try and explain again:
 
  Since our stack is so large and consists of many projects, developers
 don't
  build the entire stack from source, they only build the specific projects
  that they work on. Dependencies on other projects in our stack should be
  resolved from jars that are built by our continuous integration box and
  deployed to the maven repository. So if I'm actively developing only two
  projects I'd only want to build those two projects from source. All the
  other project dependencies I'd want to be pulled in from the maven
  repository as jars. I'm not sure how to manage this...
 
  Josh
 
  On Sun, Jan 24, 2010 at 2:03 PM, Wendy Smoak wsm...@gmail.com wrote:
 
   On Sun, Jan 24, 2010 at 2:55 PM, Josh Stone pacesysj...@gmail.com
  wrote:
  
Since any given project could be built locally from source or from
  jars,
   do
I need two poms for each project, one to serve as a build pom and
 one
   to
reference jars?
  
   No, you don't need two poms.  What do you mean by building from source
   or from jars?  The source jars in the Maven repo are generally for
   IDEs to use when debugging.  The pom that builds the project will
   usually have dependencies on other jars.
  
Should I store the pom(s) in SCM along with having them in the maven
repository?
  
   Yes, the pom belongs in scm along with the project source code.  This
   is the same pom that gets deployed to the Maven repo when you do a
   release.
  
   Ideally the conversion will go bottom up, so that you convert your
   lower level utility jars, release them, then move up to the projects
   that depend on them.  To bootstrap you may want to deploy some
   existing jars to the your internal Maven repo for projects to use.
   For those you'll need to construct a pom or let Maven generate a
   minimal one.
  
   I'm not sure I understood the question, so ask again if that's not
   what you were looking for.
  
   --
   Wendy
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 



 --
 Everything should be made as simple as possible, but not simpler Albert
 Einstein

Re: Multi-project organization

[Ron Wheeler]

I am still new to Maven after using it for 3 years with 20+ projects.
I recently installed the Nexus repository manager, community (free) version.
It is a great help and  I would heartily recommend installing it if you 
are moving to Maven.

It makes the whole process much more visible.

We use the Springsource version of Eclipse which supports Maven very 
well - great POM editor.


You can take my advice with a grain of salt. There are others with more 
experience and understanding.

1) I would set up projects for each of the jars that you need to make.

2) I would set up individual projects that create the POM files to 
describe the overall dependencies.
These POMS can be used as dependencies in your applications to pick up 
the right version of your jars.

I would also build POM projects for dependencies from third parties
We have POM files that have compile scope dependencies on all of the 
shared jars that we get from third parties (Apache, javax, etc). These 
are referenced by the POMs that produce war files, as provided so that 
the jars are available for compiling but are not in the war files since 
we install the jars in the container's (Tomcat) shared library folder.
We have several POMs describing families of 3rd party jars. One for 
spring-hibernate-mysql-tomcat for our basic technology stack, one for 
utilities, mostly Apache stuff and one for the Apace CXF Web Service 
libraries for our projects that are Web Services.


3) Put the version numbers of the jars in the POM file of the dependent 
POMs so that when you have a dependency on a pom-shared-utility pom you 
get a full set of consistent jars for the version of your application. 
This reduces the potential for errors by developers. Once you start on a 
new version of your application and decide on a set of libraries that 
will be used, you define the version in the appropriate POM and the 
developer only have to set the dependency on the version of the group 
POM to get all the right versions.


4) Use SNAPSOTS properly with your development process. Nexus helps with 
this by enforcing disciplines.


5) Do not get discouraged by the terrible documentation. There is lots 
of it but it is very much inside the beltway. Accurate but too hard to 
understand. The software works very well and there are a lot of tools to 
make maven do whatever you need.


6) Ask here. The community is really helpful if occasionally too cryptic.

Good luck, you have made a good decision to get properly structured 
using maven


Ron

Josh Stone wrote:

I'm in the process of moving our company over to Maven, and am not sure of
the best way to organize our existing projects. Currently our application
stack consists of two dozen projects with various dependencies on each
other. For projects that a developer is actively working on, these should be
built locally from source whereas dependencies on all other projects should
be resolved from jars in the maven repository. I've setup 1 pom for each
project, but there are a few things I'm not sure about:

Since any given project could be built locally from source or from jars, do
I need two poms for each project, one to serve as a build pom and one to
reference jars?
Should I store the pom(s) in SCM along with having them in the maven
repository?

Any tips are appreciated,
Josh

  



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: multi-project templates

[kristoffer]

Hi Anders,

Yes i have looked at archtypes. But it seems that this is only a one-shoot
generation of the projects? Can it maintain/enforce changes in archetype
when it is updated centrally in a dynamic way?

Cheers,
-Kristoffer


Anders Hammar wrote:
 
 That's called archetypes in the Maven world:
 http://www.sonatype.com/books/maven-book/reference/archetypes.html
 
 /Anders
 
 On Fri, Nov 6, 2009 at 13:59, kristoffer
 kristoffer.sjog...@ericsson.comwrote:
 

 Hi

 I have looked for a feature where i can define some kind of template or
 profile centrally and inherit that for each component. A component for
 us,
 has a special meaning in maven. For example, a general definition of a
 component is a maven pom type project and may contain the following
 projects:

 * EAR (depends on all other projects within this component)
 * IF (no dependencies)
 * EJB (ejb type project that depend on interface project)
 * WAR (war type project that depend on interface AND ejb project)
 * RAR (rar type project that depend on the interface project)

 There are other type of projects that are part of this definition but i
 have
 left them out here for brevity. We also have a couple of profiles and
 plugins that we need for each and every component. Together, this make
 our
 pom file very verbose.

 Our system consist of quite many components (~35-45, each with maybe 5-6
 projects) and so we repeat ourselves alot and it's hard to maintain
 consistency throughout the system.

 We did construct such a building system in Ant previously, and I havent
 found any similar feature in Maven or if it is even possible to do with a
 plugin?

 Cheers,
 -Kristoffer
 --
 View this message in context:
 http://old.nabble.com/multi-project-templates-tp26230506p26230506.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 
 

-- 
View this message in context: 
http://old.nabble.com/multi-project-templates-tp26230506p26282890.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: multi-project templates

[Anders Hammar]

No, not that I know of.

/Anders

On Tue, Nov 10, 2009 at 13:54, kristoffer
kristoffer.sjog...@ericsson.comwrote:


 Hi Anders,

 Yes i have looked at archtypes. But it seems that this is only a one-shoot
 generation of the projects? Can it maintain/enforce changes in archetype
 when it is updated centrally in a dynamic way?

 Cheers,
 -Kristoffer


 Anders Hammar wrote:
 
  That's called archetypes in the Maven world:
  http://www.sonatype.com/books/maven-book/reference/archetypes.html
 
  /Anders
 
  On Fri, Nov 6, 2009 at 13:59, kristoffer
  kristoffer.sjog...@ericsson.comwrote:
 
 
  Hi
 
  I have looked for a feature where i can define some kind of template or
  profile centrally and inherit that for each component. A component for
  us,
  has a special meaning in maven. For example, a general definition of a
  component is a maven pom type project and may contain the following
  projects:
 
  * EAR (depends on all other projects within this component)
  * IF (no dependencies)
  * EJB (ejb type project that depend on interface project)
  * WAR (war type project that depend on interface AND ejb project)
  * RAR (rar type project that depend on the interface project)
 
  There are other type of projects that are part of this definition but i
  have
  left them out here for brevity. We also have a couple of profiles and
  plugins that we need for each and every component. Together, this make
  our
  pom file very verbose.
 
  Our system consist of quite many components (~35-45, each with maybe 5-6
  projects) and so we repeat ourselves alot and it's hard to maintain
  consistency throughout the system.
 
  We did construct such a building system in Ant previously, and I havent
  found any similar feature in Maven or if it is even possible to do with
 a
  plugin?
 
  Cheers,
  -Kristoffer
  --
  View this message in context:
  http://old.nabble.com/multi-project-templates-tp26230506p26230506.html
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 

 --
 View this message in context:
 http://old.nabble.com/multi-project-templates-tp26230506p26282890.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

[m2] multi-project with plugin dependencies fails to build

[Adrian Herscu]

Hi all,

I am trying to set up a multi-project build in which one module depends 
on the Maven plugin created by other module.


So far, the only way I could build the project is by building the Maven 
plugin module and then activate the multi-project build.


Is there any possibility to define the plugin dependency?

Adrian.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [m2] multi-project with plugin dependencies fails to build

[Stephen Connolly]

afaik, no

you can use a previous version of the plugin, but not the same version  
as is built in your reactor.


the reason is that maven needs do determine the build plan before it  
starts, and your (as yet uncompiled) plugin in the reactor therefore  
has an unknown effect on the build, resulting in a circular reference  
at which point maven bombs out


Sent from my [rhymes with tryPod] ;-)

On 10 Oct 2009, at 07:50, Adrian Herscu adrian.her...@gmail.com wrote:


Hi all,

I am trying to set up a multi-project build in which one module  
depends on the Maven plugin created by other module.


So far, the only way I could build the project is by building the  
Maven plugin module and then activate the multi-project build.


Is there any possibility to define the plugin dependency?

Adrian.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Multi-Project Question

[ChipSchoch]

I am new to Maven and am converting a fairly large group of related projects
to Maven2 build.  There are about 15 projects that share the same parent
pom.  In each project pom there is a parent.version tag.  Is there a way to
use a property in this so when I move to another version I only have to
change the project version in one place?

Thanks
-- 
View this message in context: 
http://www.nabble.com/Multi-Project-Question-tp24497550p24497550.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-Project Question

[Gabriel Euzet]

Hello,

It does not work like this. You should better use the release plugin
http://maven.apache.org/plugins/maven-release-plugin/ , It changes the
version in all projects tree and much ... ^^

Regards,
Gabriel Euzet

2009/7/15 ChipSchoch csch...@elynx.com


 I am new to Maven and am converting a fairly large group of related
 projects
 to Maven2 build.  There are about 15 projects that share the same parent
 pom.  In each project pom there is a parent.version tag.  Is there a way to
 use a property in this so when I move to another version I only have to
 change the project version in one place?

 Thanks
 --
 View this message in context:
 http://www.nabble.com/Multi-Project-Question-tp24497550p24497550.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

AW: Best practice - multi project

[christian domsch (innoWake gmbh)]

Hi Milo,

From what I understood, the best solution would be to further break up the 
app1 und app2 wars in a app1-jar and a app1-war. I know that this increases 
the project complexity but from my point of view, it is the clearer approach 
for achieving your goal. I would also think, that having a war only contain 
webapp resources and no java files is a good thing. But that is only my point 
of view and has arguably some drawbacks, because some java code is only needed 
for the webapp alone.
So what I would do, is create the following setup:

/myapp + /common
   |
   + /app1-jar : depends on common
   |
   + /app1-war : depends on app1-jar
   |
   + /app2-jar : depends on common
   |
   + /app2-war : depends on app2-jar
   |
   + /admin-war: depends on app1-jar and app2-jar

Whereas I would break up the app1 and app2 java code in code, that is needed by 
admin and app1 and thus goes to app1-jar and code that is only needed by 
app1-war and stays inside this project. Same for app2. By this layout you get a 
clear approach to reasonsibility and dependencies of your projects.

Greetings,

Christian.

--
christian domsch
[software developer]

innoWake gmbh
innovative.software.development();

ACHTUNG! WIR SIND UMGEZOGEN:

IT-Tower
Robert-Bosch-Str. 1 | 89250 Senden
Fon: +49.7307.92190.0
Fax: +49.7307.92190.20
[EMAIL PROTECTED]
www.innowake.de

innoWake gmbh HRB Ulm 4584
Geschäftsführer: Thorsten Bernecker
 

This e-mail may contain confidential information. If you are not the intended 
recipient please notify the sender immediately and destroy this e-mail.


-Ursprüngliche Nachricht-
Von: Milo Mo [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 7. November 2008 01:10
An: users@maven.apache.org
Betreff: Best practice - multi project

Hi!

I have come up with a solution to a dependency problem I have had in my 
multi-maven-project, but I wonder if maybe there's a better solution. I have 
the following multi project scenario, which is probably not that uncommon:

- MyApp - parent pom
- MyApp/Common - common code
- MyApp/App1 - Web app
- MyApp/App2 - Web app
- MyApp/Admin - Webapp admin interface for App1/App2

Dependencies:

- Common: none
- App1: Common
- App2: Common
- Admin: App1 + App2 + Common

All sub projects include the parent pom. Projects App1, App2 and Admin have 
Common declared as a dependency in the maven configuration.
I run the following commands:

cd MyApp
mvn clean install

The parent pom and the Common jar will be installed in my local maven 
repository (along with the App1 and App2 war files).

The problem is the Admin project, which has dependencies to App1 and App2. I 
want the java classes from App1/App2 bundled in jar files and the jars 
installed in my local maven repository, but the App1 and App2 projects produce 
war packages...

I have three environments: local, stage, production

My solution is this:

I have configured App1 and App2 as maven projects with packaging jar, so the 
command mvn package will produce a jar, and mvn install will install the 
jar files in the local maven repository. I use an Eclipse-embedded Jetty to run 
the applications on my local machine, so no war file is needed for local use 
(if I really need a local war i can use the command mvn package war:war). So 
no profile specified means a local build.

To build war files for stage and production I have created two maven profiles, 
stage and production. To make sure war files are built for stage and 
production, I have specified that the goal war:war (from the plugin 
maven-war-plugin) will be executed in the package phase in the profiles' 
builds.

This means that for App1:

- mvn clean install will install App1.jar in the maven repository
- mvn -Pstage clean package cargo:deploy builds a war file and deploys it in 
my stage environment
- mvn -Pproduction clean package builds a war file for my production 
environment

Now I can install the App1 and App2 jar files in my local maven repository 
(mvn install) and add App1 and App2 as dependencies in Admin. The Admin 
project now builds fine.

I can't help thinking that declaring  jar packaging in App1 and App2 is a bit 
of a hack. Is there a better way of doing this?  Web apps depending on java 
classes in other web apps must be a standard issue when building multi 
projects. Another solution is breaking out the classes from App1 and App2 that 
Admin needs, but that means two more projects (e.g. App1-common and 
App2-common), and I think 6 maven projects for two web applications + admin 
is a bit much.

Any help is appreciated!

Kind regards,
Milo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Best practice - multi project

[Hayward Lam]

Would it make sense to move the common code into the Common module? If not, 
maybe a new MyApp/Web-Common module is needed to produce a jar for web shared 
code.

-Original Message-
From: Milo Mo [mailto:[EMAIL PROTECTED] 
Sent: November 6, 2008 7:11 PM
To: users@maven.apache.org
Subject: Best practice - multi project

Hi!

I have come up with a solution to a dependency problem I have had in my 
multi-maven-project, but I wonder if maybe there's a better solution. I have 
the following multi project scenario, which is probably not that uncommon:

- MyApp - parent pom
- MyApp/Common - common code
- MyApp/App1 - Web app
- MyApp/App2 - Web app
- MyApp/Admin - Webapp admin interface for App1/App2

Dependencies:

- Common: none
- App1: Common
- App2: Common
- Admin: App1 + App2 + Common

All sub projects include the parent pom. Projects App1, App2 and Admin have 
Common declared as a dependency in the maven configuration.
I run the following commands:

cd MyApp
mvn clean install

The parent pom and the Common jar will be installed in my local maven 
repository (along with the App1 and App2 war files).

The problem is the Admin project, which has dependencies to App1 and App2. I 
want the java classes from App1/App2 bundled in jar files and the jars 
installed in my local maven repository, but the App1 and App2 projects produce 
war packages...

I have three environments: local, stage, production

My solution is this:

I have configured App1 and App2 as maven projects with packaging jar, so the 
command mvn package will produce a jar, and mvn install will install the 
jar files in the local maven repository. I use an Eclipse-embedded Jetty to run 
the applications on my local machine, so no war file is needed for local use 
(if I really need a local war i can use the command mvn package war:war). So 
no profile specified means a local build.

To build war files for stage and production I have created two maven profiles, 
stage and production. To make sure war files are built for stage and 
production, I have specified that the goal war:war (from the plugin 
maven-war-plugin) will be executed in the package phase in the profiles' 
builds.

This means that for App1:

- mvn clean install will install App1.jar in the maven repository
- mvn -Pstage clean package cargo:deploy builds a war file and deploys it in 
my stage environment
- mvn -Pproduction clean package builds a war file for my production 
environment

Now I can install the App1 and App2 jar files in my local maven repository 
(mvn install) and add App1 and App2 as dependencies in Admin. The Admin 
project now builds fine.

I can't help thinking that declaring  jar packaging in App1 and App2 is a bit 
of a hack. Is there a better way of doing this?  Web apps depending on java 
classes in other web apps must be a standard issue when building multi 
projects. Another solution is breaking out the classes from App1 and App2 that 
Admin needs, but that means two more projects (e.g. App1-common and 
App2-common), and I think 6 maven projects for two web applications + admin 
is a bit much.

Any help is appreciated!

Kind regards,
Milo

 

__ Information from ESET Smart Security, version of virus signature 
database 3594 (20081107) __

The message was checked by ESET Smart Security.

http://www.eset.com
 
 

__ Information from ESET Smart Security, version of virus signature 
database 3594 (20081107) __

The message was checked by ESET Smart Security.

http://www.eset.com
 

Best practice - multi project

[Milo Mo]

Hi!

I have come up with a solution to a dependency problem I have had in my 
multi-maven-project, but I wonder if maybe there's a better solution. I have 
the following multi project scenario, which is probably not that uncommon:

- MyApp - parent pom
- MyApp/Common - common code
- MyApp/App1 - Web app
- MyApp/App2 - Web app
- MyApp/Admin - Webapp admin interface for App1/App2

Dependencies:

- Common: none
- App1: Common
- App2: Common
- Admin: App1 + App2 + Common

All sub projects include the parent pom. Projects App1, App2 and Admin have 
Common declared as a dependency in the maven configuration.
I run the following commands:

cd MyApp
mvn clean install

The parent pom and the Common jar will be installed in my local maven 
repository (along with the App1 and App2 war files).

The problem is the Admin project, which has dependencies to App1 and App2. I 
want the java classes from App1/App2 bundled in jar files and the jars 
installed in my local maven repository, but the App1 and App2 projects produce 
war packages...

I have three environments: local, stage, production

My solution is this:

I have configured App1 and App2 as maven projects with packaging jar, so the 
command mvn package will produce a jar, and mvn install will install the 
jar files in the local maven repository. I use an Eclipse-embedded Jetty to run 
the applications on my local machine, so no war file is needed for local use 
(if I really need a local war i can use the command mvn package war:war). So 
no profile specified means a local build.

To build war files for stage and production I have created two maven profiles, 
stage and production. To make sure war files are built for stage and 
production, I have specified that the goal war:war (from the plugin 
maven-war-plugin) will be executed in the package phase in the profiles' 
builds.

This means that for App1:

- mvn clean install will install App1.jar in the maven repository
- mvn -Pstage clean package cargo:deploy builds a war file and deploys it in 
my stage environment
- mvn -Pproduction clean package builds a war file for my production 
environment

Now I can install the App1 and App2 jar files in my local maven repository 
(mvn install) and add App1 and App2 as dependencies in Admin. The Admin 
project now builds fine.

I can't help thinking that declaring  jar packaging in App1 and App2 is a bit 
of a hack. Is there a better way of doing this?  Web apps depending on java 
classes in other web apps must be a standard issue when building multi 
projects. Another solution is breaking out the classes from App1 and App2 that 
Admin needs, but that means two more projects (e.g. App1-common and 
App2-common), and I think 6 maven projects for two web applications + admin 
is a bit much.

Any help is appreciated!

Kind regards,
Milo

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Best practice - multi project

[Geoffrey Wiseman]

On Thu, Nov 6, 2008 at 7:09 PM, Milo Mo [EMAIL PROTECTED] wrote:

 I can't help thinking that declaring  jar packaging in App1 and App2 is a
 bit of a hack. Is there a better way of doing this?  Web apps depending on
 java classes in other web apps must be a standard issue when building multi
 projects. Another solution is breaking out the classes from App1 and App2
 that Admin needs, but that means two more projects (e.g. App1-common and
 App2-common), and I think 6 maven projects for two web applications +
 admin is a bit much.


You could put all the classes for App1 and App2 in a single module -- so now
you have one jar and three war modules.  Or all the common classes in one
module - one jar and three wars again.
The simplest thing to do what you're already doing probably is to use the
WAR overlay technique:
http://maven.apache.org/plugins/maven-war-plugin/overlays.html

  - Geoffrey
-- 
Geoffrey Wiseman

How to Link Multi Project Site

[mac-systems]

Hello,

i have a Multi Project with a Layout like this:

pom.xml (master)
-- Sub Project Pom (type jar)
-- Sub Project Pom (type pom)
- Sub Sub Project Pom (type jar) 
- Sub Sub Project Pom (type jar)
- Sub Sub Project Pom (type jar)
-- Sub Project Pom (type jar)

I try to generate a Site which allows the use to navigate to
each sub project. After running site-deploy all links from
the master pom link to sub project ../subproject/index.html
which is completly wrong as it directs one directory.

Anyone can tell my how the pom must contain url tag to get this working ?

Thanks,
Jens

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Sharing assembly descriptors in a multi-project setting

[Keith Bonawitz]

Is there an easy way for a project to share an assembly descriptors
with all projects that have it as a parent or as a dependency?  I've
tried various combinations of
build-helper-maven-plugin:attach-artifact,
maven-dependency-plugin:copy and
maven-dependency-plugin:copy-dependencies, but I'm having trouble
getting a working configuration.  In particular,
dependency:copy-dependencies does not seem to consider parent projects
as dependencies, while dependency:copy fails if it attempts to copy
the assembly descriptor from the same project that is being built.

At a higher level, my goal is to have each of my maven projects
produce an artifact that is an archive of the build setup for that
project; e.g. it should contain everything in src/ as well as pom.xml
and (to support eclipse) .project, .classpath, and .settings/ , such
that someone could download and unzip this artifact and immediately do
a mvn compile.  In the long run, I hope to be able to use the
maven-dependency-plugin:copy-dependencies to aggregate such artifacts
for all of a given project's dependencies (or rather, all dependencies
that came from my organization) so that I can produce a single
artifact that has everything needed to completely recreate the portion
of my organization's build environment that is implicated by a
particular project.

As far as I can tell, the assembly plugin is the correct way to
produce such artifacts, but it will require a non-standard assembly
descriptor, and it seems foolish to replicate this assembly descriptor
in every project.  Is there a better way?

Thanks for your help!
Keith

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sharing assembly descriptors in a multi-project setting

[Wouter Hermeling]

Yes, you can.

Take a look at:

maven-assembly-plugin (version 2.2-beta-2 i believe)

Define an assembly descriptor project as

project
  modelVersion4.0.0/modelVersion
  artifactIdyour-artifact-id/artifactId
  groupIdyour-group_id/groupId
  versionyour-version/version
  packagingassembly-descriptor/packaging
  build
extensions
  extension
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-artifact-types/artifactId
version2.2-beta-2/version
  /extension
/extensions
plugins
  plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
  /plugin
/plugins
  /build
/project

And use it in other project like:

plugin
  artifactIdmaven-assembly-plugin/artifactId
  executions
execution
  iddo-assembly/id
  goals
goalattached/goal
  /goals
/execution
  /executions
  configuration
descriptors
 
descriptoryour-group-id:your-artifact-id:your-version/descriptor
/descriptors
  /configuration
/plugin

Kind regards,
Wouter


Keith Bonawitz-2 wrote:
 
 Is there an easy way for a project to share an assembly descriptors
 with all projects that have it as a parent or as a dependency?  I've
 tried various combinations of
 build-helper-maven-plugin:attach-artifact,
 maven-dependency-plugin:copy and
 maven-dependency-plugin:copy-dependencies, but I'm having trouble
 getting a working configuration.  In particular,
 dependency:copy-dependencies does not seem to consider parent projects
 as dependencies, while dependency:copy fails if it attempts to copy
 the assembly descriptor from the same project that is being built.
 
 At a higher level, my goal is to have each of my maven projects
 produce an artifact that is an archive of the build setup for that
 project; e.g. it should contain everything in src/ as well as pom.xml
 and (to support eclipse) .project, .classpath, and .settings/ , such
 that someone could download and unzip this artifact and immediately do
 a mvn compile.  In the long run, I hope to be able to use the
 maven-dependency-plugin:copy-dependencies to aggregate such artifacts
 for all of a given project's dependencies (or rather, all dependencies
 that came from my organization) so that I can produce a single
 artifact that has everything needed to completely recreate the portion
 of my organization's build environment that is implicated by a
 particular project.
 
 As far as I can tell, the assembly plugin is the correct way to
 produce such artifacts, but it will require a non-standard assembly
 descriptor, and it seems foolish to replicate this assembly descriptor
 in every project.  Is there a better way?
 
 Thanks for your help!
 Keith
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Sharing-assembly-descriptors-in-a-multi-project-setting-tp17121023p17124841.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sharing assembly descriptors in a multi-project setting

[Keith Bonawitz]

This sounds like what I'm looking for, thanks! Unfortunately, I'm
having trouble locating
org.apache.maven.plugins:maven-assembly-artifact-types:2.2-beta-2 .
Does anyone know if this made it out of snapshot?

Thanks,
Keith

On Thu, May 8, 2008 at 7:37 AM, Wouter Hermeling [EMAIL PROTECTED] wrote:

  Yes, you can.

  Take a look at:

  maven-assembly-plugin (version 2.2-beta-2 i believe)

  Define an assembly descriptor project as

  project
   modelVersion4.0.0/modelVersion
   artifactIdyour-artifact-id/artifactId
   groupIdyour-group_id/groupId
   versionyour-version/version
   packagingassembly-descriptor/packaging
   build
 extensions
   extension
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-artifact-types/artifactId
 version2.2-beta-2/version
   /extension
 /extensions
 plugins
   plugin
 artifactIdmaven-assembly-plugin/artifactId
 version2.2-beta-2/version
   /plugin
 /plugins
   /build
  /project

  And use it in other project like:

 plugin
   artifactIdmaven-assembly-plugin/artifactId
   executions
 execution
   iddo-assembly/id
   goals
 goalattached/goal
   /goals
 /execution
   /executions
   configuration
 descriptors

  descriptoryour-group-id:your-artifact-id:your-version/descriptor
 /descriptors
   /configuration
 /plugin

  Kind regards,
  Wouter




  Keith Bonawitz-2 wrote:
  
   Is there an easy way for a project to share an assembly descriptors
   with all projects that have it as a parent or as a dependency?  I've
   tried various combinations of
   build-helper-maven-plugin:attach-artifact,
   maven-dependency-plugin:copy and
   maven-dependency-plugin:copy-dependencies, but I'm having trouble
   getting a working configuration.  In particular,
   dependency:copy-dependencies does not seem to consider parent projects
   as dependencies, while dependency:copy fails if it attempts to copy
   the assembly descriptor from the same project that is being built.
  
   At a higher level, my goal is to have each of my maven projects
   produce an artifact that is an archive of the build setup for that
   project; e.g. it should contain everything in src/ as well as pom.xml
   and (to support eclipse) .project, .classpath, and .settings/ , such
   that someone could download and unzip this artifact and immediately do
   a mvn compile.  In the long run, I hope to be able to use the
   maven-dependency-plugin:copy-dependencies to aggregate such artifacts
   for all of a given project's dependencies (or rather, all dependencies
   that came from my organization) so that I can produce a single
   artifact that has everything needed to completely recreate the portion
   of my organization's build environment that is implicated by a
   particular project.
  
   As far as I can tell, the assembly plugin is the correct way to
   produce such artifacts, but it will require a non-standard assembly
   descriptor, and it seems foolish to replicate this assembly descriptor
   in every project.  Is there a better way?
  
   Thanks for your help!
   Keith
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  

  --
  View this message in context: 
 http://www.nabble.com/Sharing-assembly-descriptors-in-a-multi-project-setting-tp17121023p17124841.html
  Sent from the Maven - Users mailing list archive at Nabble.com.


  -
  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]

how to execute a plugin only once in multi-project parent pom

[Ittay Dror]

Hi,

I have a pom that acts both as parent and as multi-module. In it, I have 
a plugin execution. What I want is for the plugin to execute once when 
invoking maven on the parent pom (so it does not run for every module), 
and also have it executed when invoking maven on some child module 
(where only that module is executed)


Thank you,
Ittay

--
Ittay Dror [EMAIL PROTECTED]
Tikal http://www.tikalk.com
Tikal Project http://tikal.sourceforge.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: how to execute a plugin only once in multi-project parent pom

[Brian E. Fox]

You can set inherited=false in the parent so it won't go down to all the
children. There is no way to currently tell a plugin to execute only
once in a given build no matter where the build is executed. I tried to
do this with the enforcer and ended up having to put caching logic into
the plugin itself to deal with this.

-Original Message-
From: Ittay Dror [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 08, 2008 2:31 PM
To: Maven Users List
Subject: how to execute a plugin only once in multi-project parent pom

Hi,

I have a pom that acts both as parent and as multi-module. In it, I have

a plugin execution. What I want is for the plugin to execute once when 
invoking maven on the parent pom (so it does not run for every module), 
and also have it executed when invoking maven on some child module 
(where only that module is executed)

Thank you,
Ittay

-- 
Ittay Dror [EMAIL PROTECTED]
Tikal http://www.tikalk.com
Tikal Project http://tikal.sourceforge.net


-
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]

Re: how to execute a plugin only once in multi-project parent pom

[Ittay Dror]

ok, created case http://jira.codehaus.org/browse/MNG-3508

Brian E. Fox wrote:

You can set inherited=false in the parent so it won't go down to all the
children. There is no way to currently tell a plugin to execute only
once in a given build no matter where the build is executed. I tried to
do this with the enforcer and ended up having to put caching logic into
the plugin itself to deal with this.

-Original Message-
From: Ittay Dror [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 08, 2008 2:31 PM

To: Maven Users List
Subject: how to execute a plugin only once in multi-project parent pom

Hi,

I have a pom that acts both as parent and as multi-module. In it, I have

a plugin execution. What I want is for the plugin to execute once when 
invoking maven on the parent pom (so it does not run for every module), 
and also have it executed when invoking maven on some child module 
(where only that module is executed)


Thank you,
Ittay

  


--
Ittay Dror [EMAIL PROTECTED]
Tikal http://www.tikalk.com
Tikal Project http://tikal.sourceforge.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

exec:java in multi project environments

[Joshua ChaitinPollak]

Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got a  
project setup with two sub-modules, and when I run the exec plugin on  
a main class that is in one module that depends on another, I get an  
error that the dependancy module is not in the repository. I don't  
want to have to install the project just to exec it, and unit testing  
works with dependancies without installing, so I'm a bit puzzled.


Any help would be greatly appreciated.

Here is a more concrete example:

MyProj
   +---ModuleA
   +---ModuleB

ModuleB depends on ModuleA and has a class with a main function.

If I run mvn compile exec:java - 
Dexec.mainClass=MyProj.ModuleB.MyClass


INFO]  


[ERROR] BUILD ERROR
[INFO]  


[INFO] Failed to resolve artifact.

Missing:
--
1) MyProj:ModuleA.jar:1.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file


  Alternatively, if you host your own repository you can deploy the  
file there:
  mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] - 
DrepositoryId=[id]


  Path to dependency:
1) MyProj:ModuleA.jar:1.0-SNAPSHOT
2) MyProj:ModuleB.jar:1.0-SNAPSHOT


--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970

Re: exec:java in multi project environments

[Joshua ChaitinPollak]

Correction to my previous post: I realize now that the problem  
described below is actually caused by my helper script changing into  
the ModuleB directory before running the command below, which would  
understandably cause the problem described.


HOWEVER, I am still having a problem, which is actually best described  
in this post:


http://www.nabble.com/Maven-exec:java-ClassNotFoundException-td15613520s177.html

Is there a solution to this? It sounds like if the class is not found,  
we'd like the plugin to not fail, but keep running, to allow the  
plugin to try again on the sub-modules. Is that possible?


-Josh


On Apr 8, 2008, at 11:01 PM, Joshua ChaitinPollak wrote:

Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got  
a project setup with two sub-modules, and when I run the exec plugin  
on a main class that is in one module that depends on another, I get  
an error that the dependancy module is not in the repository. I  
don't want to have to install the project just to exec it, and unit  
testing works with dependancies without installing, so I'm a bit  
puzzled.


Any help would be greatly appreciated.

Here is a more concrete example:

MyProj
  +---ModuleA
  +---ModuleB

ModuleB depends on ModuleA and has a class with a main function.

If I run mvn compile exec:java - 
Dexec.mainClass=MyProj.ModuleB.MyClass


INFO]  


[ERROR] BUILD ERROR
[INFO]  


[INFO] Failed to resolve artifact.

Missing:
--
1) MyProj:ModuleA.jar:1.0-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file


 Alternatively, if you host your own repository you can deploy the  
file there:
 mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url]  
-DrepositoryId=[id]


 Path to dependency:
1) MyProj:ModuleA.jar:1.0-SNAPSHOT
2) MyProj:ModuleB.jar:1.0-SNAPSHOT


--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970








--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970

Re: exec:java in multi project environments

[Joshua ChaitinPollak]

I've discovered my problem and submitted a patch for the exec-maven- 
plugin:


http://jira.codehaus.org/browse/MEXEC-43

On Apr 8, 2008, at 11:01 PM, Joshua ChaitinPollak wrote:

Hi, I'm having a bit of trouble with the exec-maven-plugin. I've got  
a project setup with two sub-modules, and when I run the exec plugin  
on a main class that is in one module that depends on another, I get  
an error that the dependancy module is not in the repository. I  
don't want to have to install the project just to exec it, and unit  
testing works with dependancies without installing, so I'm a bit  
puzzled.


Any help would be greatly appreciated.

Here is a more concrete example:

MyProj
  +---ModuleA
  +---ModuleB

ModuleB depends on ModuleA and has a class with a main function.

If I run mvn compile exec:java - 
Dexec.mainClass=MyProj.ModuleB.MyClass


INFO]  


[ERROR] BUILD ERROR
[INFO]  


[INFO] Failed to resolve artifact.

Missing:
--
1) MyProj:ModuleA.jar:1.0-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file


 Alternatively, if you host your own repository you can deploy the  
file there:
 mvn deploy:deploy-file -DgroupId=MyProj -DartifactId=ModuleA - 
Dversion=1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url]  
-DrepositoryId=[id]


 Path to dependency:
1) MyProj:ModuleA.jar:1.0-SNAPSHOT
2) MyProj:ModuleB.jar:1.0-SNAPSHOT


--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970








--
Joshua ChaitinPollak | Software Engineer
Kiva Systems, Inc., 225 Wildwood Ave, Woburn, MA 01970

filtering files at archetype-metadata.xml multi-project

[Marcelo Rÿfffff4mulo Fernandes]

I´m creating a multi-project archetype.
When I run the command above, the readme.txt file is not copied to generated 
project root, but only main pom.xml. I tried to copy others files to root dir, 
but they are not copied. What´s is wrong with the fileSet?

mvn archetype:generate 
-DarchetypeGroupId=org.persapiens.basegen-DarchetypeArtifactId=maven-basegenapp-plugin-DarchetypeVersion=1.0-SNAPSHOT

The archetype-metadata.xml file:

archetype-descriptor name=maven-basegenapp-plugin
fileSets
fileSet filtered=true packaged=false
directory./directory
includes
includereadme.txt/include
/includes
/fileSet 
fileSet filtered=true packaged=false
directorysrc/directory
includes
include**/*/include
/includes
excludes
exclude**/*.xml.zip/exclude
/excludes
/fileSet
fileSet filtered=false packaged=false
directorysrc/directory
includes
include**/*.xml.zip/include
/includes
/fileSet
/fileSets
modules
module name=Business Bean dir=business-bean
fileSets
fileSet filtered=true packaged=false
directorysrc/directory
includes
include**/*/include
/includes
/fileSet
/fileSets
/module
/modules
requiredProperties
requiredProperty key=copyright/
/requiredProperties
/archetype-descriptor





  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: filtering files at archetype-metadata.xml multi-project

[Raphaël Piéroni]

Hi Marcelo,

Your first file set is set to directory./directory
but it should be set to directory/directory
yes the value for root directory is empty

Regards,

Raphaël

2008/3/10, Marcelo Rÿf4mulo Fernandes [EMAIL PROTECTED]:
 I´m creating a multi-project archetype.
  When I run the command above, the readme.txt file is not copied to generated 
 project root, but only main pom.xml. I tried to copy others files to root 
 dir, but they are not copied. What´s is wrong with the fileSet?

  mvn archetype:generate 
 -DarchetypeGroupId=org.persapiens.basegen-DarchetypeArtifactId=maven-basegenapp-plugin-DarchetypeVersion=1.0-SNAPSHOT

  The archetype-metadata.xml file:

  archetype-descriptor name=maven-basegenapp-plugin
 fileSets
 fileSet filtered=true packaged=false
 directory./directory
 includes
 includereadme.txt/include
 /includes
 /fileSet
 fileSet filtered=true packaged=false
 directorysrc/directory
 includes
 include**/*/include
 /includes
 excludes
 exclude**/*.xml.zip/exclude
 /excludes
 /fileSet
 fileSet filtered=false packaged=false
 directorysrc/directory
 includes
 include**/*.xml.zip/include
 /includes
 /fileSet
 /fileSets
 modules
 module name=Business Bean dir=business-bean
 fileSets
 fileSet filtered=true packaged=false
 directorysrc/directory
 includes
 include**/*/include
 /includes
 /fileSet
 /fileSets
 /module
 /modules
 requiredProperties
 requiredProperty key=copyright/
 /requiredProperties
  /archetype-descriptor





   
 
  Be a better friend, newshound, and
  know-it-all with Yahoo! Mobile.  Try it now.  
 http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Re: filtering files at archetype-metadata.xml multi-project

[Marcelo Romulo Fernandes]

Hi Raphael,

It works! Thanks very much!

´s
marcelo

- Original Message 
From: Raphaël Piéroni [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Sent: Monday, March 10, 2008 4:22:56 PM
Subject: Re: filtering files at archetype-metadata.xml multi-project

Hi Marcelo,

Your first file set is set to directory./directory
but it should be set to directory/directory
yes the value for root directory is empty

Regards,

Raphaël

2008/3/10, Marcelo Rÿf4mulo Fernandes [EMAIL PROTECTED]:
 I´m creating a multi-project archetype.
  When I run the command above, the readme.txt file is not copied to generated 
 project root, but only main pom.xml. I tried to copy others files to root 
 dir, but they are not copied. What´s is wrong with the fileSet?

  mvn archetype:generate 
 -DarchetypeGroupId=org.persapiens.basegen-DarchetypeArtifactId=maven-basegenapp-plugin-DarchetypeVersion=1.0-SNAPSHOT

  The archetype-metadata.xml file:

  archetype-descriptor name=maven-basegenapp-plugin
 fileSets
 fileSet filtered=true packaged=false
 directory./directory
 includes
 includereadme.txt/include
 /includes
 /fileSet
 fileSet filtered=true packaged=false
 directorysrc/directory
 includes
 include**/*/include
 /includes
 excludes
 exclude**/*.xml.zip/exclude
 /excludes
 /fileSet
 fileSet filtered=false packaged=false
 directorysrc/directory
 includes
 include**/*.xml.zip/include
 /includes
 /fileSet
 /fileSets
 modules
 module name=Business Bean dir=business-bean
 fileSets
 fileSet filtered=true packaged=false
 directorysrc/directory
 includes
 include**/*/include
 /includes
 /fileSet
 /fileSets
 /module
 /modules
 requiredProperties
 requiredProperty key=copyright/
 /requiredProperties
  /archetype-descriptor





   
 
  Be a better friend, newshound, and
  know-it-all with Yahoo! Mobile.  Try it now.  
 http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]







  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: M2 multi-project site build is broken

[VUB Stefan Seidel]

Ok, but what about the Surefire tests being run way too often? Is this 
not a more general error?


Stefan

Dennis Lundberg wrote:

This sounds like something to report in JIRA for the xmlbeans plugin.

http://jira.codehaus.org/browse/MXMLBEANS

VUB Stefan Seidel wrote:

Hi,

I don't know if anyone else noticed this, but the mvn site keeps on
getting worse. It first started out with the following phenomenon:
during site build, for each project _all_ the projects were iterated,
usually saying
[INFO] No goals needed for project - skipping
Then, we started using xmlbeans and it started doing xmlbeans:xmlbeans
for each project. And now, it executes _all_ the tests of _all_ project
for _each_ project. Well, you can imagine that this is pretty much
undoable for a project like ours with 150+ modules.

Here some sample outputs from the attached project (1 parent, 2 modules,
1 test per module)
   mvn clean site | grep Running | wc -l
6
--- this means the two tests are executed 3 times each!!

   mvn clean site | grep xmlbeans | wc -l
29
--- this means, xmlbeans is being executed 26 times, 9 times per 
project!!!


Hello? Is anyone _using_ maven 2  site generation? This situation is
that it is becoming totally unusable. The problem is, I don't even know
where to report the bug, because it seems to be a combination of bugs.


regards,

Stefan Seidel

P.S.: I have removed the attached project, to see whether this is 
causing the apache mail server to reject my mail. You can find it at

http://stefanseidel.info/mvnexec.zip






--
best regards, Stefan Seidel software developer  
VUB Printmedia GmbH Chopinstraße 4 D-04103 Leipzig Germany tel. +49 
(341) 9 60 50 07 fax. +49 (341) 9 60 50 92 mail. [EMAIL PROTECTED] web. 
www.vub.de HRB Köln 24015 UStID DE 122 649 251 GF Dr. Achim Preuss 
Neudorf, Dr. Christian Preuss Neudorf


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: M2 multi-project site build is broken

[Mick Knutson]

We use XML beans but we use plugin management in the main pom.xml, the:

  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxmlbeans-maven-plugin/artifactId
  /plugin

for the few modules that actually need the create our xml bean.
Are you doing that?

Also, we group our xmlbean modules together and do not run them everytime we
build unless there is a change to the code.
Takes way too long otherwise.


On Jan 29, 2008 1:08 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:

 It might be so, but the title of your mail M2 multi-project site build
 is broken is not going to attract people who knows about running tests...

 VUB Stefan Seidel wrote:
  Ok, but what about the Surefire tests being run way too often? Is this
  not a more general error?
 
  Stefan
 
  Dennis Lundberg wrote:
  This sounds like something to report in JIRA for the xmlbeans plugin.
 
  http://jira.codehaus.org/browse/MXMLBEANS
 
  VUB Stefan Seidel wrote:
  Hi,
 
  I don't know if anyone else noticed this, but the mvn site keeps on
  getting worse. It first started out with the following phenomenon:
  during site build, for each project _all_ the projects were iterated,
  usually saying
  [INFO] No goals needed for project - skipping
  Then, we started using xmlbeans and it started doing xmlbeans:xmlbeans
  for each project. And now, it executes _all_ the tests of _all_
 project
  for _each_ project. Well, you can imagine that this is pretty much
  undoable for a project like ours with 150+ modules.
 
  Here some sample outputs from the attached project (1 parent, 2
 modules,
  1 test per module)
 mvn clean site | grep Running | wc -l
  6
  --- this means the two tests are executed 3 times each!!
 
 mvn clean site | grep xmlbeans | wc -l
  29
  --- this means, xmlbeans is being executed 26 times, 9 times per
  project!!!
 
  Hello? Is anyone _using_ maven 2  site generation? This situation is
  that it is becoming totally unusable. The problem is, I don't even
 know
  where to report the bug, because it seems to be a combination of bugs.
 
 
  regards,
 
  Stefan Seidel
 
  P.S.: I have removed the attached project, to see whether this is
  causing the apache mail server to reject my mail. You can find it at
  http://stefanseidel.info/mvnexec.zip
 
 
 
 


 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-- 
Thanks,
Mick Knutson

http://www.baselogic.com
http://www.blincmagazine.com
http://www.djmick.com
http://www.myspace.com/mickknutson
http://www.myspace.com/BLiNCMagazine
http://tahoe.baselogic.com
---

Re: M2 multi-project site build is broken

[Dennis Lundberg]

It might be so, but the title of your mail M2 multi-project site build 
is broken is not going to attract people who knows about running tests...


VUB Stefan Seidel wrote:
Ok, but what about the Surefire tests being run way too often? Is this 
not a more general error?


Stefan

Dennis Lundberg wrote:

This sounds like something to report in JIRA for the xmlbeans plugin.

http://jira.codehaus.org/browse/MXMLBEANS

VUB Stefan Seidel wrote:

Hi,

I don't know if anyone else noticed this, but the mvn site keeps on
getting worse. It first started out with the following phenomenon:
during site build, for each project _all_ the projects were iterated,
usually saying
[INFO] No goals needed for project - skipping
Then, we started using xmlbeans and it started doing xmlbeans:xmlbeans
for each project. And now, it executes _all_ the tests of _all_ project
for _each_ project. Well, you can imagine that this is pretty much
undoable for a project like ours with 150+ modules.

Here some sample outputs from the attached project (1 parent, 2 modules,
1 test per module)
   mvn clean site | grep Running | wc -l
6
--- this means the two tests are executed 3 times each!!

   mvn clean site | grep xmlbeans | wc -l
29
--- this means, xmlbeans is being executed 26 times, 9 times per 
project!!!


Hello? Is anyone _using_ maven 2  site generation? This situation is
that it is becoming totally unusable. The problem is, I don't even know
where to report the bug, because it seems to be a combination of bugs.


regards,

Stefan Seidel

P.S.: I have removed the attached project, to see whether this is 
causing the apache mail server to reject my mail. You can find it at

http://stefanseidel.info/mvnexec.zip









--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

M2 multi-project site build is broken

[VUB Stefan Seidel]

Hi,

I don't know if anyone else noticed this, but the mvn site keeps on
getting worse. It first started out with the following phenomenon:
during site build, for each project _all_ the projects were iterated,
usually saying
[INFO] No goals needed for project - skipping
Then, we started using xmlbeans and it started doing xmlbeans:xmlbeans
for each project. And now, it executes _all_ the tests of _all_ project
for _each_ project. Well, you can imagine that this is pretty much
undoable for a project like ours with 150+ modules.

Here some sample outputs from the attached project (1 parent, 2 modules,
1 test per module)
   mvn clean site | grep Running | wc -l
6
--- this means the two tests are executed 3 times each!!

   mvn clean site | grep xmlbeans | wc -l
29
--- this means, xmlbeans is being executed 26 times, 9 times per project!!!

Hello? Is anyone _using_ maven 2  site generation? This situation is
that it is becoming totally unusable. The problem is, I don't even know
where to report the bug, because it seems to be a combination of bugs.


regards,

Stefan Seidel

P.S.: I have removed the attached project, to see whether this is 
causing the apache mail server to reject my mail. You can find it at

http://stefanseidel.info/mvnexec.zip

--
best regards,

Stefan Seidel
software developer

VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail.   [EMAIL PROTECTED]
web.www.vub.de

HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: M2 multi-project site build is broken

[Dennis Lundberg]

This sounds like something to report in JIRA for the xmlbeans plugin.

http://jira.codehaus.org/browse/MXMLBEANS

VUB Stefan Seidel wrote:

Hi,

I don't know if anyone else noticed this, but the mvn site keeps on
getting worse. It first started out with the following phenomenon:
during site build, for each project _all_ the projects were iterated,
usually saying
[INFO] No goals needed for project - skipping
Then, we started using xmlbeans and it started doing xmlbeans:xmlbeans
for each project. And now, it executes _all_ the tests of _all_ project
for _each_ project. Well, you can imagine that this is pretty much
undoable for a project like ours with 150+ modules.

Here some sample outputs from the attached project (1 parent, 2 modules,
1 test per module)
   mvn clean site | grep Running | wc -l
6
--- this means the two tests are executed 3 times each!!

   mvn clean site | grep xmlbeans | wc -l
29
--- this means, xmlbeans is being executed 26 times, 9 times per 
project!!!


Hello? Is anyone _using_ maven 2  site generation? This situation is
that it is becoming totally unusable. The problem is, I don't even know
where to report the bug, because it seems to be a combination of bugs.


regards,

Stefan Seidel

P.S.: I have removed the attached project, to see whether this is 
causing the apache mail server to reject my mail. You can find it at

http://stefanseidel.info/mvnexec.zip




--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Deploying multi project as single war

[dddzzz]

Is it possible to deploy multi project as single war. Projects structure
looks similar to this:

rootProject (packaging POM)
-commonRootProject (packaging POM)
--commonCoreProject (packaging JAR - for now)
--...
-serverRootProject (packaging POM)
--serverCoreProject (packaging JAR - for now)
--...
-clientRootProject (packaging POM)
--clientCoreProject (packaging JAR - for now)
--...

How can I make a single WAR from this projects with maven2. web.xml is in
one of projects for now.
-- 
View this message in context: 
http://www.nabble.com/Deploying-multi-project-as-single-war-tp14619903s177p14619903.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Deploying multi project as single war

[nicklist]

If you want to make a war of one of the projects, make a packaging war of it. 
It will copy all dependencies as jars inside the WEB-INF/lib directory, 
effectively creating one WAR deployment for deployment to remote repositories 
or application servers (Which deploy do you mean?).

Also, copy your web.xml to the war project into src/main/webapp/WEB-INF to get 
it in the right place in the war file.

Is this what you are intending to do, or did I get the question wrong?

Hth,

Nick Stolwijk


-Original Message-
From: dddzzz [mailto:[EMAIL PROTECTED]
Sent: Fri 1/4/2008 5:32 PM
To: users@maven.apache.org
Subject: Deploying multi project as single war
 

Is it possible to deploy multi project as single war. Projects structure
looks similar to this:

rootProject (packaging POM)
-commonRootProject (packaging POM)
--commonCoreProject (packaging JAR - for now)
--...
-serverRootProject (packaging POM)
--serverCoreProject (packaging JAR - for now)
--...
-clientRootProject (packaging POM)
--clientCoreProject (packaging JAR - for now)
--...

How can I make a single WAR from this projects with maven2. web.xml is in
one of projects for now.
-- 
View this message in context: 
http://www.nabble.com/Deploying-multi-project-as-single-war-tp14619903s177p14619903.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deploying multi project as single war

[dddzzz]

dddzzz wrote:
 
 Is it possible to deploy multi project as single war. Projects structure
 looks similar to this:
 
 rootProject (packaging POM)
 -commonRootProject (packaging POM)
 --commonCoreProject (packaging JAR - for now)
 --...
 -serverRootProject (packaging POM)
 --serverCoreProject (packaging JAR - for now)
 --...
 -clientRootProject (packaging POM)
 --clientCoreProject (packaging JAR - for now)
 --...
 
 How can I make a single WAR from this projects with maven2. web.xml is in
 one of projects for now.
 

I was thinking to use cargo-maven2-plugin but I dont want to merge multple
web.xml files since everthing I nead is in one I have.

-- 
View this message in context: 
http://www.nabble.com/Deploying-multi-project-as-single-war-tp14619903s177p14621256.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deploying multi project as single war

[dddzzz]

I want classes and resources from all projects to end up in single WAR. Is
that possible with described project structure.

-- 
View this message in context: 
http://www.nabble.com/Deploying-multi-project-as-single-war-tp14619903s177p14620408.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Deploying multi project as single war

[Nick Stolwijk]

First thing, why do you want it to be in a single war, instead of a 
single war, with libraries inside? (Often, it is an eye opener to why 
you want something, instead of focusing on what you are trying to do)


Secondly, yes, it is possible, but not at all pretty or easy.  You have 
to work with the dependency:unpack-dependencies goal [1].


Hth,

Nick Stolwijk

[1] 
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html


dddzzz wrote:

I want classes and resources from all projects to end up in single WAR. Is
that possible with described project structure.

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-release-plugin with multi-project

[geirgp]

Does anyone know how to use release plugin together with multiper
project/modules? I have the following 5 projects:
* common   (packaging=jar, parent project=main)
* core   (packaging=jar, parent roject=main)
* framework   (packaging=, parent parent project=main)
* web   (packaging=war, parent project=main)
* main  (packaging=pom, modules=common,core,framework,web)

When I do a normal build on this project i run mvn clean install from the
main -project, and all other projects are built as well. Assuming the same
approach would work for release plugin I ran the following command from the
project main:

mvn release:prepare

..which ran smoothly. Then I ran..:

mvn release:perform

..which gave the following error:



[INFO] Scanning for projects...
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] Error building POM (may not be this project's POM).


Project ID: unknown

Reason: Could not find the model file
'/home/gg/projects/main/target/checkout/main/../common/pom.xml'. for project
unknown


-


I had a look in the target/checkout folder created by release:prepare and
noticed that it did only contain the main -project, not any of the modules
refferd to by the main-project's pom.xml. I also checked the other projects'
target folder, and there was no checkout folder there.

Why are all the modules left out? Does anyone know how to get around this?



thanks,

Geir



-- 
View this message in context: 
http://www.nabble.com/maven-release-plugin-with-multi-project-tp14533200s177p14533200.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-release-plugin with multi-project

[Dan Tran]

maven release works best if you have this structure:

   root
  pom.xml -- parent
  common
  core
  framework
  web

Note: you should eliminate your main and move its pom to root.
Ofcourse you need to change all your module's pom accordingly.

-D

On Dec 28, 2007 3:59 PM, geirgp [EMAIL PROTECTED] wrote:

 I have 5 projects:
 * common   (packaging=jar, parent project=main)
 * core   (packaging=jar, parent project=main)
 * framework   (packaging=jar, parent project=main)
 * web   (packaging=war, parent project=main)
 * main  (packaging=pom, modules=common,core,framework,web)

 When I do a normal build on this project i run mvn clean install from the
 main -project, and all other projects are built as well. Assuming the same
 approach would work for

 --
 View this message in context: 
 http://www.nabble.com/maven-release-plugin-with-multi-project-tp14533200s177p14533200.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 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]

@requiresDependencyResolution, multi-project and reactor dependencies - a bug?

[Alfie Kirkpatrick]

Hi, we're using Maven 2.0.7 (same problem also seems to exist on 2.0.4).
This seems like something so basic I'm hoping there is a simple
explanation/workaround.

 

What we're seeing is that some multi-project configurations succeed on
'mvn package' but fail on 'mvn generate-sources'. They are failing when
one project in the reactor references another project in the reactor
which is not installed in the local repo. It seems that the referenced
project has not quite made it into the reactor this early in the phase
lifecycle. But it does work correctly if you target a later phase at the
outset which I find really confusing (my understanding was that Maven
executes the phases in order, so the final phase chosen should not
affect the execution of earlier phases??).

 

The problem only occurs when a plugin binds itself to the
generate-sources phase and has @requiresDependencyResolution, presumably
because this is what triggers resolution of the referenced dependency
too early in the lifecycle, and hence the error.

 

We are seeing this problem when trying to run 'mvn eclipse:eclipse'
because this only executes the generate-sources phase by default and we
have other mojos which genuinely do generate source, such as java2wsdl.

 

A workaround is to always run 'mvn install' before 'mvn eclipse:eclipse'
to get all projects into the local repo.

 

Another workaround is to run 'mvn package eclipse:eclipse' (voodoo!!).

 

I have a sample multi-project and mojo to demonstrate this behaviour but
you can see it easily with the antrun mojo and many others.

 

Is this a bug - should I raise a JIRA on it?

 

Many thanks,

Alfie.



Communications on or through ioko's computer systems may be monitored or 
recorded to secure effective system operation and for other lawful purposes.

Unless otherwise agreed expressly in writing, this communication is to be 
treated as confidential and the information in it may not be used or disclosed 
except for the purpose for which it has been sent. If you have reason to 
believe that you are not the intended recipient of this communication, please 
contact the sender immediately. No employee is authorised to conclude any 
binding agreement on behalf of ioko with another party by e-mail without prior 
express written confirmation.

ioko365 Ltd.  VAT reg 656 2443 31. Reg no 3048367. All rights reserved.

Re: What happens when someone commits while a multi-project is building ?

[Emmanuel Venisse]

Damien Lecan a écrit :

Hello,

I'm working with Continuum 1.1-beta-3.

I have a multi-project configured as a project group in Continuum, ie
I can see 1 continuum project per Maven project.

I setup a build scheduled each day at 11am. The complete build lasts 25min.

Today, someone commited severals files in several projects during the
build (at 11:15).

Of course, projects already built were OK, but projects built after
commit were updated by Continuum and built with errors ! They needed
new files in projects already built by Continuum and so not updated.

Is it a bug/feature ? Continuum should not update a project from SCM
if a commit appears during a build.


It isn't a bug, when Continuum build a module, it can't know files updated in 
the current module require some modified files in other modules.
When other modules will be rebuilt (due to changes in their scm) the current 
module will be rebuilt too.

If you don't want one project in continuum by module, but only the parent 
project, remove all modules and remove the --non-recursive parameter on the 
build definition.

Emmanuel

What happens when someone commits while a multi-project is building ?

[Damien Lecan]

Hello,

I'm working with Continuum 1.1-beta-3.

I have a multi-project configured as a project group in Continuum, ie
I can see 1 continuum project per Maven project.

I setup a build scheduled each day at 11am. The complete build lasts 25min.

Today, someone commited severals files in several projects during the
build (at 11:15).

Of course, projects already built were OK, but projects built after
commit were updated by Continuum and built with errors ! They needed
new files in projects already built by Continuum and so not updated.

Is it a bug/feature ? Continuum should not update a project from SCM
if a commit appears during a build.

Thanks

Damien

Re: What happens when someone commits while a multi-project is building ?

[Stuart James Penrose]

Emmanuel Venisse wrote:



Damien Lecan a écrit :

Hello,

I'm working with Continuum 1.1-beta-3.

I have a multi-project configured as a project group in Continuum, ie
I can see 1 continuum project per Maven project.

I setup a build scheduled each day at 11am. The complete build lasts 
25min.


Today, someone commited severals files in several projects during the
build (at 11:15).

Of course, projects already built were OK, but projects built after
commit were updated by Continuum and built with errors ! They needed
new files in projects already built by Continuum and so not updated.

Is it a bug/feature ? Continuum should not update a project from SCM
if a commit appears during a build.


It isn't a bug, when Continuum build a module, it can't know files 
updated in the current module require some modified files in other 
modules.
When other modules will be rebuilt (due to changes in their scm) the 
current module will be rebuilt too.


If you don't want one project in continuum by module, but only the 
parent project, remove all modules and remove the --non-recursive 
parameter on the build definition.


Since we're on the subject, it might be worth noting the following: I 
tried doing that on our main multimodule project when I first switched 
to 1.1 (b3), since that's how we had it setup under 1.0.3 and it worked 
great.  However, I noticed that when I did that in 1.1, the 
'dependencies' listed for the resulting single consolidated continuum 
project were only those of the parent project itself.  In other words, 
where parent project A has essentially no dependencies, and module A1 
has many dependencies (many of which are also being build in continuum), 
the downside to this seems to be that continuum looses some dependency 
awareness (it doesn't re-build project A when A1's dependencies change). 


Emannuel, does this sound right, or am I missing something?

Stu

Re: Maven Multi-Project - Modules are Numbers when checked out --repl y

[Emmanuel Venisse]

 
The problem I have now is when the build fails, say due to a unit test, the

status of the build is SUCCESS.  Although the log states FAILED.
 
Is there some configuration I am missing here or is the problem related to

me setup?


It is a known issue in 2.0.7. http://jira.codehaus.org/browse/MNG-3084

You can update the bat file in your local install as described in the bug and 
it will start working.

Emmanuel

FW: Maven Multi-Project - Modules are Numbers when checked out

[James Clinton]

( apoligies if you received this twice ) 

Hello,
 
Setting up Continuum for the first time using Maven2 for our builds. (which
is a Multi-Project).
 
Pointed Continuum to the parent POM and this loaded in the projects.  When
running the parent the build fails because it cannot find the child POM in
the working directory.
 
Looking in the directory, the reason is because the checked out folder isnt
the name of the module, but a number:
 
-1   (parent)
-2   (child)
-n
 
If this number was the project name the child POM would of been found.  Is
there some configuration I am missing or is this to do with my setup.  My
Parent module is at the same level as it children if that matters. Parent
POM extract:
 
modules
 module../ProjectAPI/module
 module../ProjectCore/module
/modules
 
Any help appreciated.
 
Regards,
James.
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful.  Please inform the sender and delete the message
immediately from your system.  This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.

Multi project reports ...

[Giovanni Azua]

Hi all,

I have a pom (packaging type) project that has many subprojects
(inheritance) it is nice because each subproject can separately manage their
dependencies etc. In the parent project I include the major reporting plugin
settings etc. 

The problem is that since the parent project does not have any sources, I
only get fewer reports. On the other hand each subproject gets generated its
own reporting page independently, I expected somehow they would be combined
into the parent project ...

I wanted to get something like what displaytag does see:
http://displaytag.sourceforge.net/11/

Where all subprojects are shown at the same level as the parent project. I
tried copying what they do but seems not to work in the latest version of
maven? I don't get the site output of my subprojects copied into my parent
project's target site subdirectory besides the subprojects keep generating
the site with the default settings rather than using the theme defined in
the site.css of the parent project.

TIA,
Regards,
Giovanni

build
plugins
  plugin
artifactIdmaven-antrun-plugin/artifactId
executions
  execution
phasesite/phase
goals
  goalrun/goal
/goals
configuration
  tasks
copy overwrite=true todir=../${pom.artifactId}/src/site
flatten=true
  fileset dir=..
include
name=displaytag-doc/src/site/site.xml/include
exclude
name=${pom.artifactId}/src/site/site.xml/exclude
  /fileset
/copy
replace value=href=quot;../ token=href=quot;/
dir=..
  include
name=${pom.artifactId}/src/site/site.xml/include
  exclude
name=displaytag-doc/src/site/site.xml/exclude
/replace
replace value=href=quot;
token=href=quot;../${pom.artifactId}/ dir=..
  include
name=${pom.artifactId}/src/site/site.xml/include
  exclude
name=displaytag-doc/src/site/site.xml/exclude
/replace
  /tasks
/configuration
  /execution
/executions
  /plugin
  ...
/plugins
/build



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What is the best way to consolidate the site from a multi-project project

[dvicente]

yes you add this section in your root pom :



loganalyzer.site
Maven Project Website
file:///C:\temp\site



Maven nw knows where to deploy the site.

after that, mvn site site:deploy and your site is fully operational

see the doc :  http://maven.apache.org/plugins/maven-site-plugin/usage.html
http://maven.apache.org/plugins/maven-site-plugin/usage.html 




ChuckC wrote:
 
 I have my site generating for a multi-project project, but the top level
 pom report does not properly link into the sub-level pom reports. Ideally,
 I would like the site to be in a single destination. Is there a way to get
 the sites to link together as a single site. This is very similar to the
 earlier post about getting it to generate sites for a multi-projects
 project. 
 

-- 
View this message in context: 
http://www.nabble.com/What-is-the-best-way-to-consolidate-the-site-from-a-multi-project-project-tf4239560s177.html#a12088208
Sent from the Maven - Users mailing list archive at Nabble.com.

Re: What is the best way to consolidate the site from a multi-project project

[ChuckC]

Thanks. This works.


dvicente wrote:
 
 yes you add this section in your root pom :
 
 distributionManagement
   site
   idloganalyzer.site/id
   nameMaven Project Website/name
   urlfile:///C:\temp\site/url
   /site
   /distributionManagement
 
 Maven nw knows where to deploy the site.
 
 after that, mvn site site:deploy and your site is fully operational
 
 see the doc : 
 http://maven.apache.org/plugins/maven-site-plugin/usage.html
 http://maven.apache.org/plugins/maven-site-plugin/usage.html 
 
 
 
 
 ChuckC wrote:
 
 I have my site generating for a multi-project project, but the top level
 pom report does not properly link into the sub-level pom reports.
 Ideally, I would like the site to be in a single destination. Is there a
 way to get the sites to link together as a single site. This is very
 similar to the earlier post about getting it to generate sites for a
 multi-projects project. 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/What-is-the-best-way-to-consolidate-the-site-from-a-multi-project-project-tf4239560s177.html#a12098843
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

What is the best way to consolidate the site from a multi-project project

[ChuckC]

I have my site generating for a multi-project project, but the top level pom
report does not properly link into the sub-level pom reports. Ideally, I
would like the site to be in a single destination. Is there a way to get the
sites to link together as a single site. This is very similar to the
earlier post about getting it to generate sites for a multi-projects
project. 
-- 
View this message in context: 
http://www.nabble.com/What-is-the-best-way-to-consolidate-the-site-from-a-multi-project-project-tf4239560s177.html#a12063506
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to do a release in a multi project environment?

[vadimos]

We have two projects. For the sake of this post lets call them Foo and Bar.
Foo depends on Bar and declares it in its pom file. Since both Foo and Bar
are actively worked on and generate snapshot versions using continuous
integration server, this is a snapshot dependency. All is well until we
decide to perform a release of both projects by using maven release plugin.
We release Bar first, update Foo's pom to include Bar's released version
(can't release Bar with snapshot dependency on Foo) and release Foo. So far
so good and we continue development on Foo and Bar and almost immediately
after releasing them need to change pom of Foo to include snapshot version
of Bar in order to pickup any new changes. During QA phase this becomes a
pain - changing pom back and forth. 

I decided to parameterize the version specification and have profiles define
either a snapshot or release version. It works for maven but cause problems
in eclipse because the later does not know how to substitute the version
parameter with the value specified in the profile.

I have two questions:
1. Is my approach to handling Foo and Bar development and release life cycle
correct? 
2. If yes, how to force eclipse to use profile before it attempts to
download Bar's version from local maven repository.

thanks for comments,

vadim
-- 
View this message in context: 
http://www.nabble.com/How-to-do-a-release-in-a-multi-project-environment--tf3985418s177.html#a11315728
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to do a release in a multi project environment?

[Brett Porter]

If Foo and Bar have their development so closely linked that they
always use a snapshot version of each other, why not align their
versions and release them together as one multi-module project?

- Brett

On 27/06/07, vadimos [EMAIL PROTECTED] wrote:


We have two projects. For the sake of this post lets call them Foo and Bar.
Foo depends on Bar and declares it in its pom file. Since both Foo and Bar
are actively worked on and generate snapshot versions using continuous
integration server, this is a snapshot dependency. All is well until we
decide to perform a release of both projects by using maven release plugin.
We release Bar first, update Foo's pom to include Bar's released version
(can't release Bar with snapshot dependency on Foo) and release Foo. So far
so good and we continue development on Foo and Bar and almost immediately
after releasing them need to change pom of Foo to include snapshot version
of Bar in order to pickup any new changes. During QA phase this becomes a
pain - changing pom back and forth.

I decided to parameterize the version specification and have profiles define
either a snapshot or release version. It works for maven but cause problems
in eclipse because the later does not know how to substitute the version
parameter with the value specified in the profile.

I have two questions:
1. Is my approach to handling Foo and Bar development and release life cycle
correct?
2. If yes, how to force eclipse to use profile before it attempts to
download Bar's version from local maven repository.

thanks for comments,

vadim
--
View this message in context: 
http://www.nabble.com/How-to-do-a-release-in-a-multi-project-environment--tf3985418s177.html#a11315728
Sent from the Maven - Users mailing list archive at Nabble.com.


-
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]

Re: How to do a release in a multi project environment?

[vadimos]

But eclipse does not support multi module projects. How would you set one up
in Eclipse?

vadim


Brett Porter wrote:
 
 If Foo and Bar have their development so closely linked that they
 always use a snapshot version of each other, why not align their
 versions and release them together as one multi-module project?
 
 - Brett
 
 On 27/06/07, vadimos [EMAIL PROTECTED] wrote:

 We have two projects. For the sake of this post lets call them Foo and
 Bar.
 Foo depends on Bar and declares it in its pom file. Since both Foo and
 Bar
 are actively worked on and generate snapshot versions using continuous
 integration server, this is a snapshot dependency. All is well until we
 decide to perform a release of both projects by using maven release
 plugin.
 We release Bar first, update Foo's pom to include Bar's released version
 (can't release Bar with snapshot dependency on Foo) and release Foo. So
 far
 so good and we continue development on Foo and Bar and almost immediately
 after releasing them need to change pom of Foo to include snapshot
 version
 of Bar in order to pickup any new changes. During QA phase this becomes a
 pain - changing pom back and forth.

 I decided to parameterize the version specification and have profiles
 define
 either a snapshot or release version. It works for maven but cause
 problems
 in eclipse because the later does not know how to substitute the version
 parameter with the value specified in the profile.

 I have two questions:
 1. Is my approach to handling Foo and Bar development and release life
 cycle
 correct?
 2. If yes, how to force eclipse to use profile before it attempts to
 download Bar's version from local maven repository.

 thanks for comments,

 vadim
 --
 View this message in context:
 http://www.nabble.com/How-to-do-a-release-in-a-multi-project-environment--tf3985418s177.html#a11315728
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 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]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/How-to-do-a-release-in-a-multi-project-environment--tf3985418s177.html#a11316509
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]