Re: Resolve root directory in a multi-project build
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
Interesting. Given that Maven 4 will include the wrapper; wrapper files are
kept at $ROOT/.mvn; running a wrapper from a child project requires that
$ROOt/.mvn be known (from the outside even). Thus the value of the top most
basedir can be guaranteed.
Of course this works only if there is a .mvn dir at the top. Hoping that will
be the common case in the future, could we have a way to expose that dir by
default as soon as Maven boots up? Fall back to a warning when the directory is
not found.
Thoughts?
Sent from my primitive tricorder
> On 18 Feb 2021, at 14:15, Delany wrote:
>
> Following on a bit, I logged this ticket
> https://github.com/pascalgn/properties-maven-extension/issues/58
> so the property *git.dir.worktree* is available before the reactor starts.
> But now I've found a situation that even an extension can't help with:
>
> Suppose I want to utilise an alternative settings.xml file. I can place it
> in .mvn/settings.xml and add --settings=.mvn/settings.xml to
> .mvn/maven.config
>
> But this only works when I build from the highest basedir. No property is
> yet available to say --settings=${highest-basedir}/.mvn/settings.xml
>
> And yet Maven was clearly able to find the .mvn directory. So if we can
> take that as the highest-basedir, it just remains to give that location a
> name and make it available.
>
> Anyone see any issues with this?
>
> Thanks,
>
> On Mon, 8 Feb 2021 at 07:35, Alexander Kriegisch
> wrote:
>
>>> I think the reason someone might want their projects all in the same
>>> directory is because Eclipse has issues with nested project
>>> structures.
>>
>> I see how that can be a pain in the ***. I was unaware of this problem,
>> being an IntelliJ IDEA user.
>>
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Delany schrieb am 07.02.2021 12:19 (GMT +07:00):
>>
>>> Hopefully our conversation will benefit others who've experienced the
>> same
>>> issue, so thank you for showing that it works in some cases. I think the
>>> reason someone might want their projects all in the same directory is
>>> because Eclipse has issues with nested project structures.
>>>
>>> @Lasse, the directory-of goal of directory-maven-plugin seems even more
>>> idiot-proof than highest-basedir, so im using that.
>>>
>>> Delany
>>>
>>> On Sun, 7 Feb 2021 at 03:29, Alexander Kriegisch <
>> alexan...@kriegisch.name>
>>> wrote:
>>>
> 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 <
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
>> > >
>>> 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
>>
Re: Resolve root directory in a multi-project build
Following on a bit, I logged this ticket
https://github.com/pascalgn/properties-maven-extension/issues/58
so the property *git.dir.worktree* is available before the reactor starts.
But now I've found a situation that even an extension can't help with:
Suppose I want to utilise an alternative settings.xml file. I can place it
in .mvn/settings.xml and add --settings=.mvn/settings.xml to
.mvn/maven.config
But this only works when I build from the highest basedir. No property is
yet available to say --settings=${highest-basedir}/.mvn/settings.xml
And yet Maven was clearly able to find the .mvn directory. So if we can
take that as the highest-basedir, it just remains to give that location a
name and make it available.
Anyone see any issues with this?
Thanks,
On Mon, 8 Feb 2021 at 07:35, Alexander Kriegisch
wrote:
> > I think the reason someone might want their projects all in the same
> > directory is because Eclipse has issues with nested project
> > structures.
>
> I see how that can be a pain in the ***. I was unaware of this problem,
> being an IntelliJ IDEA user.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Delany schrieb am 07.02.2021 12:19 (GMT +07:00):
>
> > Hopefully our conversation will benefit others who've experienced the
> same
> > issue, so thank you for showing that it works in some cases. I think the
> > reason someone might want their projects all in the same directory is
> > because Eclipse has issues with nested project structures.
> >
> > @Lasse, the directory-of goal of directory-maven-plugin seems even more
> > idiot-proof than highest-basedir, so im using that.
> >
> > Delany
> >
> > On Sun, 7 Feb 2021 at 03:29, Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> > 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 <
> >> 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
> >> >> >> >> >
> >> >> > 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
> >> >> >> --
RE: maven-assembly-plugin v3.3.0 - how to modify generated MANIFEST.MF
Thanks, exactly what I was looking for.
-Original Message-
From: Thomas Broyer
Sent: donderdag 18 februari 2021 11:44
To: jean-pierre.urk...@devoteam.com.invalid
Cc: Maven Users List
Subject: Re: maven-assembly-plugin v3.3.0 - how to modify generated
MANIFEST.MF
Use the 'archive' property of the assembly plugin itself (not in the
assembly descriptor):
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#archive
Le jeu. 18 févr. 2021 à 11:23, Jean-Pierre Urkens
a écrit :
> Hi all,
>
>
>
> I am trying to generate a ‘jar’ assembly that contains a ‘Main-Class’
> in the META-INF/MANIFEST.MF. Now it looks like the assembly plugin is
> generating its own (plexus archiver) MANIFEST file with contents:
>
>Manifest-Version: 1.0
>
> Created-By: Plexus Archiver 4.2.1
>
>
>
> My idea was to include via a my own MANIFEST.MF file
> specifying the Main-Class and ‘append’ this to the generated MANIFEST
> using the ‘file-aggregator’ containerDescriptorHandler in my descriptor
> file:
>
>
>
>
>
>
>
> file-aggregator
>
>
>
> .*/MANIFEST.MF
>
> META-INF/MANIFEST.MF
>
>
>
>
>
>
>
>
>
> This didn’t work so I was wondering whether it found my manifest file.
> So I adjusted the above configuration to write to ‘test/
> META-INF/MANIFEST.MF’.
>
> My own manifest file resides under ‘db/MANIFEST.MF’ and should be
> picked up
> by:
>
>
>
>
>
>
>
>
> ${project.build.directory}/classes
>
>
>
> false
>
>
>
> db/**
>
>
>
>
>
>
>
>
>
> Now it does generate an ‘test/META-INF/MANIFEST.MF’ but with following
> contents:
>
># Aggregated on Thu Feb 18 11:18:39 CET 2021 from:
>
>
>
> So it looks that the content of my ‘db/MANIFEST.MF’ isn’t included.
> What am I missing? How can I add my own content to the generated
> manifest file of this plugin?
>
>
>
> Tanks for any hints,
>
>
>
> J.P.
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-assembly-plugin v3.3.0 - how to modify generated MANIFEST.MF
Use the 'archive' property of the assembly plugin itself (not in the
assembly descriptor):
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#archive
Le jeu. 18 févr. 2021 à 11:23, Jean-Pierre Urkens
a écrit :
> Hi all,
>
>
>
> I am trying to generate a ‘jar’ assembly that contains a ‘Main-Class’ in
> the META-INF/MANIFEST.MF. Now it looks like the assembly plugin is
> generating its own (plexus archiver) MANIFEST file with contents:
>
>Manifest-Version: 1.0
>
> Created-By: Plexus Archiver 4.2.1
>
>
>
> My idea was to include via a my own MANIFEST.MF file specifying
> the Main-Class and ‘append’ this to the generated MANIFEST using the
> ‘file-aggregator’ containerDescriptorHandler in my descriptor file:
>
>
>
>
>
>
>
> file-aggregator
>
>
>
> .*/MANIFEST.MF
>
> META-INF/MANIFEST.MF
>
>
>
>
>
>
>
>
>
> This didn’t work so I was wondering whether it found my manifest file. So I
> adjusted the above configuration to write to ‘test/
> META-INF/MANIFEST.MF’.
>
> My own manifest file resides under ‘db/MANIFEST.MF’ and should be picked up
> by:
>
>
>
>
>
>
>
> ${project.build.directory}/classes
>
>
>
> false
>
>
>
> db/**
>
>
>
>
>
>
>
>
>
> Now it does generate an ‘test/META-INF/MANIFEST.MF’ but with following
> contents:
>
># Aggregated on Thu Feb 18 11:18:39 CET 2021 from:
>
>
>
> So it looks that the content of my ‘db/MANIFEST.MF’ isn’t included. What am
> I missing? How can I add my own content to the generated manifest file of
> this plugin?
>
>
>
> Tanks for any hints,
>
>
>
> J.P.
>
maven-assembly-plugin v3.3.0 - how to modify generated MANIFEST.MF
Hi all,
I am trying to generate a ‘jar’ assembly that contains a ‘Main-Class’ in
the META-INF/MANIFEST.MF. Now it looks like the assembly plugin is
generating its own (plexus archiver) MANIFEST file with contents:
Manifest-Version: 1.0
Created-By: Plexus Archiver 4.2.1
My idea was to include via a my own MANIFEST.MF file specifying
the Main-Class and ‘append’ this to the generated MANIFEST using the
‘file-aggregator’ containerDescriptorHandler in my descriptor file:
file-aggregator
.*/MANIFEST.MF
META-INF/MANIFEST.MF
This didn’t work so I was wondering whether it found my manifest file. So I
adjusted the above configuration to write to ‘test/
META-INF/MANIFEST.MF’.
My own manifest file resides under ‘db/MANIFEST.MF’ and should be picked up
by:
${project.build.directory}/classes
false
db/**
Now it does generate an ‘test/META-INF/MANIFEST.MF’ but with following
contents:
# Aggregated on Thu Feb 18 11:18:39 CET 2021 from:
So it looks that the content of my ‘db/MANIFEST.MF’ isn’t included. What am
I missing? How can I add my own content to the generated manifest file of
this plugin?
Tanks for any hints,
J.P.
extensions vs plugins
Hi, Can someone explain the tag found in plugins? https://maven.apache.org/guides/mini/guide-using-extensions.html It seems like instead of being a plugin that provides lifecycle enhancements using this tag, a lot of plugins should rather be extensions, that can optionally accept configuration on a per project basis. Take the toolchains plugins. How many people actually build to more than one JDK in the same reactor run? If I ever need to do that, I'll switch a profile/property. I only need the toolchain.xml parsed and a JDK set for all reactor plugins once. Then I can use the https://maven.apache.org/enforcer/enforcer-rules/requireJavaVersion.html to evaluate that JDK, and that will be the end of it. Instead the toolchains plugin is not thread-safe, so I get a whopping 13 WARNING log lines for every one of my 528 projects. The requireJavaVersion rule is now useless. The toolchains.xml file cannot be optional https://issues.apache.org/jira/browse/MTOOLCHAINS-29 And to top it off, the toolchains plugin doesn't verify that the is actually a JDK and not a JRE. So the compiler will fail to find javac, issue a warning, and fallback to the system javac. There's no way for me to protect against this. Thanks,
