Re: Dependency plugin unpack plugin dependencies

[Benjamin Marwell]

Hi Alexander,

this is an old thread, but no one has replied yet.
While I think this is possible – what are you trying to achieve?
Or in other words: WHY do you need the dependencies unpacked? What do
you do with them?


Regards,
Ben

On 2020/08/19 18:23:06, Alexander Broekhuis  wrote:
> Hi all,
>
> I currently have a setup in which I have some custom artifacts that I use
> as dependencies and unpack using unpack-dependencies.
> This all works great, but now I also have a custom plugin which needs one
> of the custom artifacts as dependency. I don't see those dependencies being
> unpacked.  Is this correct, or am I doing something wrong?
>
> I know I can add the dependency as "regular" dependency as workaround, but
> I'd like to be able to define the plugin in a parent's pluginManagement
> with it's dependencies so that dependant project can enable the plugin when
> needed without having to define the dependency, or always have it being
> unpacked even if not needed.
>
> Basically my pom looks like this (meta):
>
> // Those are unpacked as expected
> 
> 
> 
>
> // Those dependencies are not unpacked
> 
> 
> 
> 
> 
> 
> 
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

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

Re: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Thomas,

I investigated a bit further. It seems from the debug output, that the
remote sources were fetched.  Thus, the error seems misleading:

[DEBUG] Expanding:
$USER/.m2/repository/de/uni-stuttgart/informatik/fius/ICGE-Simulation/2.3.6/ICGE-Simulation-2.3.6-sources.jar
into 
$USER/git/apache/jvk/project/target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources
[DEBUG] Trying to add links for modules...
[ERROR] no reactor project: de.uni-stuttgart.informatik.fius:ICGE-Simulation


So I tried to add this path manually like this:


org.apache.maven.plugins
maven-javadoc-plugin
-   3.1.1
+   3.2.0


--show-packages=all

de.unistuttgart.informatik.fius.jvk.tasks:de.unistuttgart.informatik.fius.jvk.verifier
+
true

true


https://fius.github.io/ICGE2/${icge.version}

+
${sourcepath}:target/distro-javadoc-sources/ICGE-Simulation-2.3.6-sources




And:
BUILD SUCCESS

So I think you found a bug where module sources are not being added to
the javadoc source path AND there is a misleading error message.
Would you kindly open two issues?

Am Mi., 28. Okt. 2020 um 20:18 Uhr schrieb Benjamin Marwell
:
>
> Hi Tim,
>
> this lines makes me wonder:
>
> > [ERROR] no reactor project:  > of my project>
>
> I think this means that  will only work with
> dependencies from the same reactor project. Thus your
> "group_id:artifact_id of the single dependency of my project" seems to
> be a foreign project?
>
> But then from the goal description [1] it does not mention "must be on
> the same reactor project".
> Do you see a message that "group_id:artifact_id:source:jar could not
> be fetched" or similar?
>
>
> [1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html
>
> Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
> :
> >
> > Hello everybody,
> >
> > I'm struggling to get javadoc generation with includeDependencySource
> > working in my project.
> >
> > When setting includeDependencySource to true in the pom and running mvn
> > clean install javadoc:aggregate or mvn clean install javadoc:javadoc
> >
> > I get the following errors:
> >
> > First: [ERROR] no reactor project:  > dependency of my project>
> >
> > And a few lines later a BUILD FAILURE because the javadoc tool exited
> > with the following error:
> > Exit code: 1 -
> > /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> > error: module not found on module source path
> >
> > But the source of the dependency seems to be fetched and unpacked
> > correctly to
> > /path/to/my/project/target/distro-javadoc-sources/--sources/
> > The line (10) where the error is is the module definition of the single
> > in that project.
> >
> > The generated javdoc options file contains only one module-source-path:
> > /path/to/my/project/target/site/apidocs/src which contains a single
> > empty folder named like the module of my project (not the dependency).
> >
> > Did anyone have a similar problem before? Any ideas what to try?
> >
> > If anyone wants to look at the whole pom or try to reproduce it, the
> > project is on github: https://github.com/fius/jvk in the folder project.
> > The only dependency of that project is also on github:
> > https://github.com/FIUS/ICGE2
> > For trying to get this to work I made some changes to both, which are
> > not merged yet. See these pull-requests:
> > https://github.com/FIUS/ICGE2/pull/186 and
> > https://github.com/FIUS/jvk/pull/71
> > For this testing I'm using version 2.3.5-Snapshot of the dependency and
> > just locally running mvn clean install in it instead of uploading it to
> > a maven repository.
> >
> > Regards,
> > Tim
> >
> > --
> > Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> > stv. Referent für IT Betreung
> > Studierendenvertretung Uni Stuttgart
> > https://stuvus.uni-stuttgart.de
> >
> >
> >
> > -
> > 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: Need help: maven-javadoc-plugin: includeDependencySource: error: module not found on module source path

[Benjamin Marwell]

Hi Tim,

this lines makes me wonder:

> [ERROR] no reactor project:  my project>

I think this means that  will only work with
dependencies from the same reactor project. Thus your
"group_id:artifact_id of the single dependency of my project" seems to
be a foreign project?

But then from the goal description [1] it does not mention "must be on
the same reactor project".
Do you see a message that "group_id:artifact_id:source:jar could not
be fetched" or similar?


[1] https://maven.apache.org/plugins/maven-javadoc-plugin/aggregate-mojo.html

Am Sa., 17. Okt. 2020 um 18:08 Uhr schrieb Tim Neumann
:
>
> Hello everybody,
>
> I'm struggling to get javadoc generation with includeDependencySource
> working in my project.
>
> When setting includeDependencySource to true in the pom and running mvn
> clean install javadoc:aggregate or mvn clean install javadoc:javadoc
>
> I get the following errors:
>
> First: [ERROR] no reactor project:  dependency of my project>
>
> And a few lines later a BUILD FAILURE because the javadoc tool exited
> with the following error:
> Exit code: 1 -
> /path/to/my/project/target/distro-javadoc-sources/--sources/module-info.java:10:
> error: module not found on module source path
>
> But the source of the dependency seems to be fetched and unpacked
> correctly to
> /path/to/my/project/target/distro-javadoc-sources/--sources/
> The line (10) where the error is is the module definition of the single
> in that project.
>
> The generated javdoc options file contains only one module-source-path:
> /path/to/my/project/target/site/apidocs/src which contains a single
> empty folder named like the module of my project (not the dependency).
>
> Did anyone have a similar problem before? Any ideas what to try?
>
> If anyone wants to look at the whole pom or try to reproduce it, the
> project is on github: https://github.com/fius/jvk in the folder project.
> The only dependency of that project is also on github:
> https://github.com/FIUS/ICGE2
> For trying to get this to work I made some changes to both, which are
> not merged yet. See these pull-requests:
> https://github.com/FIUS/ICGE2/pull/186 and
> https://github.com/FIUS/jvk/pull/71
> For this testing I'm using version 2.3.5-Snapshot of the dependency and
> just locally running mvn clean install in it instead of uploading it to
> a maven repository.
>
> Regards,
> Tim
>
> --
> Tim Neumann (GPG-Key: B5BD 17C3 BD4A 7BA4)
> stv. Referent für IT Betreung
> Studierendenvertretung Uni Stuttgart
> https://stuvus.uni-stuttgart.de
>
>
>
> -
> 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: Java11 and javadoc plugin

[Benjamin Marwell]

Hi Thomas,

no worry, that is as easy to fix as the previous one.

Read carefully:
> Error generating maven-javadoc-plugin:3.2.0:test-aggregate-no-fork

The javadoc-plugin executes "test-aggregate-no-fork".

Which means: It creates javadoc for your TEST classes from src/test/java.
That again requires the "test" goal to be run first [1].
> Requires dependency resolution of artifacts in scope: test.

I rarely found it useful to generate, validate and publish javadoc for
test classes.

Long story short:
mvn test site # (test includes compile).

Although imho, you will always want to execute "mvn verify" (or "mvn
clean verify") anyway, wouldn’t you? ;-)
This is considered a good habit by Robert Scholte iirc.

If you need more information on the "why", don’t hesitate to ask! :)

[1] 
https://maven.apache.org/plugins/maven-javadoc-plugin/test-aggregate-no-fork-mojo.html

Am Mi., 28. Okt. 2020 um 14:45 Uhr schrieb Thomas Scheffler
:
>
> Hi,
>
> thanks for looking into it. I updated the project a bit so that you can 
> easily switch the version with „-Djavadoc.plugin.version=3.0.1“ to see it 
> working nice with „mvn site“ and „mvn javadoc:javadoc“. My problem is, that I 
> don’t know how to make „site“ run again. „mvn compile site“ will prevent the 
> errors for the main javadocs but will fail on test javadocs (Junit tests):
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on 
> project test: Error generating 
> maven-javadoc-plugin:3.2.0:test-aggregate-no-fork report:
> [ERROR] Exit code: 2 - javadoc: error - No source files for package 
> de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/Home/14/bin/javadoc @options 
> @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/Users/yagee/git/javadoc-test/target/site/testapidocs' dir.
> [ERROR] -> [Help 1]
>
> I can stick with 3.0.1 for a while, but of cause I want to move forward. I 
> set up the minimal project to get this figured out, but I lost.
>
> Looking at https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html, 
> there is even no hint on suddenly requiring „compile“ starting with version 
> 1.1.0. Still the site issue drives me nuts, too.
>
> Thanks again for helping me!
>
> kind regards,
>
> Thomas
>
> Am 27.10.2020 um 19:55 schrieb Benjamin Marwell :
>
> Hi Thomas,
>
> I tested your configuration and found the same issue – however, it may
> not be an issue after all.
>
> You configured your javadoc plugin as part of the reporting section.
> This usually requires the compile goal.
>
> Even if you add the jar goal to the default build->plugin section, it
> will still require compile to be executed. This is expected and
> documented in [2]:
> "Requires dependency resolution of artifacts in scope: compile. &&
> Binds by default to the lifecycle phase: package."
>
> Same description for the javadoc:javadoc goal.
>
> "mvn package site" will work because "package" includes the "compile"
> goal from the default lifecycle.
>
> site (on its own) however is it's own lifecycle and goal and does not
> contain the default's lifecycle compile goal. See [1].
>
> Everything you reported works as expected. From what I can tell it
> shouldn’t have worked with other java versions and/or other javadoc
> plugin versions either.
>
> Does this help you? If not, maybe you might want to explain your
> execution idea instead. This will help us getting an idea of what you
> are trying to achieve.
>
> Best regards,
> Ben
>
> [1] 
> https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> [2] https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html
>
> Am Mo., 26. Okt. 2020 um 12:49 Uhr schrieb Thomas Scheffler
> :
>
>
> Hi,
>
> I have serious problems getting any maven-javadoc-plugin >= 3.1.0 to work 
> with simply Java 11 test case:
>
> Neither will „mvn javadoc:javadoc“ nor „mvn javadoc:jar“ nor „mvn site“ work 
> out-of-the-box. I have to add „compile“ in the middle to get the 
> javadoc-plugin work but this will not fix the site generation.
>
> What’s wrong with the pom.xml or with maven (using version 3.6.3)?
>
> I created a small test project on github: 
> https://github.com/yagee-de/javadoc-test
>
> The output I get is like:
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default-cli) on 
> project test: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - error: module not found: de.yagee.test
> [ERROR]
> [ERROR] Command line was: /Users/yagee/Java/Home/11/bin/javadoc @options 
> @packages @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> '/Users/yagee/git/javadoc-test/target/apidocs' dir.
> [ERROR]
> [ERROR] -> [Help 1]
>
> Any help is highly appreciated!
>
> Kind regards,
>
> Thomas
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional 

Re: Java11 and javadoc plugin

[Thomas Scheffler]

Hi,

thanks for looking into it. I updated the project a bit so that you can easily 
switch the version with „-Djavadoc.plugin.version=3.0.1“ to see it working nice 
with „mvn site“ and „mvn javadoc:javadoc“. My problem is, that I don’t know how 
to make „site“ run again. „mvn compile site“ will prevent the errors for the 
main javadocs but will fail on test javadocs (Junit tests):

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on project 
test: Error generating maven-javadoc-plugin:3.2.0:test-aggregate-no-fork report:
[ERROR] Exit code: 2 - javadoc: error - No source files for package 
de.yagee.test
[ERROR]
[ERROR] Command line was: /Users/yagee/Java/Home/14/bin/javadoc @options 
@packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 
'/Users/yagee/git/javadoc-test/target/site/testapidocs' dir.
[ERROR] -> [Help 1]

I can stick with 3.0.1 for a while, but of cause I want to move forward. I set 
up the minimal project to get this figured out, but I lost.

Looking at https://maven.apache.org/plugins/maven-javadoc-plugin/usage.html 
, there is 
even no hint on suddenly requiring „compile“ starting with version 1.1.0. Still 
the site issue drives me nuts, too.

Thanks again for helping me!

kind regards,

Thomas

> Am 27.10.2020 um 19:55 schrieb Benjamin Marwell :
> 
> Hi Thomas,
> 
> I tested your configuration and found the same issue – however, it may
> not be an issue after all.
> 
> You configured your javadoc plugin as part of the reporting section.
> This usually requires the compile goal.
> 
> Even if you add the jar goal to the default build->plugin section, it
> will still require compile to be executed. This is expected and
> documented in [2]:
> "Requires dependency resolution of artifacts in scope: compile. &&
> Binds by default to the lifecycle phase: package."
> 
> Same description for the javadoc:javadoc goal.
> 
> "mvn package site" will work because "package" includes the "compile"
> goal from the default lifecycle.
> 
> site (on its own) however is it's own lifecycle and goal and does not
> contain the default's lifecycle compile goal. See [1].
> 
> Everything you reported works as expected. From what I can tell it
> shouldn’t have worked with other java versions and/or other javadoc
> plugin versions either.
> 
> Does this help you? If not, maybe you might want to explain your
> execution idea instead. This will help us getting an idea of what you
> are trying to achieve.
> 
> Best regards,
> Ben
> 
> [1] 
> https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
> [2] https://maven.apache.org/plugins/maven-javadoc-plugin/jar-mojo.html
> 
> Am Mo., 26. Okt. 2020 um 12:49 Uhr schrieb Thomas Scheffler
> :
>> 
>> Hi,
>> 
>> I have serious problems getting any maven-javadoc-plugin >= 3.1.0 to work 
>> with simply Java 11 test case:
>> 
>> Neither will „mvn javadoc:javadoc“ nor „mvn javadoc:jar“ nor „mvn site“ work 
>> out-of-the-box. I have to add „compile“ in the middle to get the 
>> javadoc-plugin work but this will not fix the site generation.
>> 
>> What’s wrong with the pom.xml or with maven (using version 3.6.3)?
>> 
>> I created a small test project on github: 
>> https://github.com/yagee-de/javadoc-test
>> 
>> The output I get is like:
>> 
>> [ERROR] Failed to execute goal 
>> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default-cli) on 
>> project test: MavenReportException: Error while generating Javadoc:
>> [ERROR] Exit code: 1 - error: module not found: de.yagee.test
>> [ERROR]
>> [ERROR] Command line was: /Users/yagee/Java/Home/11/bin/javadoc @options 
>> @packages @argfile
>> [ERROR]
>> [ERROR] Refer to the generated Javadoc files in 
>> '/Users/yagee/git/javadoc-test/target/apidocs' dir.
>> [ERROR]
>> [ERROR] -> [Help 1]
>> 
>> Any help is highly appreciated!
>> 
>> Kind regards,
>> 
>> Thomas
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 




smime.p7s
Description: S/MIME cryptographic signature

Re: Incorrect evaluated project.parent.version in child pom

[Alexander Kriegisch]

At least Maven Dependency Plugin seems to cause some problems, I noticed
after writing you when calling

  mvn dependency:tree
  mvn dependency:analyze

with or without previous clean or compile.

I got to admit that your project structure looks somewhat strange, but
still there seems to be something not okay with the version number
resolution, like you said. I am by no means an expert in the depths of
Maven. I wish one of the developers would take a look and make a more
authoritative statement.

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


Roy Lenferink schrieb am 28.10.2020 16:19 (GMT +07:00):

> Hi Alexander,
> 
> Thanks for thinking with me!
> 
> I forgot to mention that I _do_ make use of the maven-dependency-plugin with
> the 
> copy-dependencies goal to copy my dependencies to the target/dependencies/
> folder. This is being
> executed in the clean phase [1]. If I move it to e.g. the compile phase then
> the compile phase starts
> failing. Could it be the maven-dependency-plugin being the one throwing the
> error?
> 
> Regards,
> Roy
> 
> [1] https://s.apache.org/rlenferink-mvn-1
> 
> On 2020/10/28 01:22:39, "Alexander Kriegisch"  
> wrote:
> 
>> Thanks Roy,
>> 
>> I noticed that the actual build lifecycle (goals like validate, compile,
>> install) works as expected. The problem seems to be in the clean lifecycle,
>> i.e. possibly somewhere in the Maven Clean Plugin. No matter if I use the
>> default plugin version 3.5 or upgrade to 3.1.0, the problem occurs when
>> calling 'mvn clean' in directory 'productB'. Maybe you should raise an issue.
>> -- 
>> Alexander Kriegisch
>> https://scrum-master.de
>> 
>> 
>> Roy Lenferink schrieb am 28.10.2020 02:18 (GMT +07:00):
>> 
>> > Hi Alexander,
>> > 
>> > I just created a test project sketching the scenario I am having. See the
>> > following repo:
>> > https://github.com/rlenferink/maven-properties-project
>> > 
>> > I put the instructions for testing in the README. 
>> > 
>> > In my text example there where indeed some mismatches, I hope the repo with
>> > sample data
>> > resolves those unclarities.
>> > 
>> > Hope someone can clarify whether this is expected Maven behavior or not.
>> > 
>> > Best regards,
>> > Roy
>> > 
>> > On 2020/10/25 02:39:12, "Alexander Kriegisch" 
>> wrote:
>> > 
>> >> Hello Roy.
>> >> 
>> >> Your textual description is nice and contains a lot of information, but
>> >> why not attach or link to a simple but complete reproducer project? The
>> >> reason I am asking is that in order to reproduce this, every reader
>> >> needs to carefully try to recreate your situation manually. Errors in
>> >> doing so are likely, especially given the following facts:
>> >> 
>> >>   -- Your directory layout is rather unconventional.
>> >>   -- Your sample artifact naming is cryptic.
>> >>   -- You submodule artifact names differ from directory names.
>> >>   -- You seem to have an artifact named productA-sub1, but also one
>> >>  named productA-submodule1. Are they the same or different? If they
>> >>  are the same, why would you define a dependency on the parent
>> >>  module which probably has POM packaging?
>> >> 
>> >> Let the POMs speak for themselves, please. Thank you.
>> >> 
>> >> Cheers
>> >> -- 
>> >> Alexander Kriegisch
>> >> https://scrum-master.de
>> >> 
>> >> 
>> >> Roy Lenferink schrieb am 23.10.2020 17:11 (GMT +07:00):
>> >> 
>> >> > Hello fellow Maven users,
>> >> > 
>> >> > At $work a problem occurs with evaluation the ${project.parent.version}
>> from
>> >> a
>> >> > child pom.
>> >> > 
>> >> > The product structure in question:
>> >> > 
>> >> > Product A:
>> >> > /pom.xml <= productA-parent (version 10.2.4-SNAPSHOT)
>> >> > 
>> >> > /submodule1/pom.xml <= productA-sub1
>> >> > => submodule1 uses productA-parent as parent
>> >> > => submodule1 contains submodule2 in its modules section =>
>> >> > ../submodule2
>> >> > 
>> >> > /submodule2/pom.xml <= productA-sub2
>> >> > => submodule2 uses submodule1 as parent with relativePath ../submodule1/
>> >> > 
>> >> > Submodule2 has a dependency which is activated in a profile which refers
>> to
>> >> > submodule1:
>> >> > 
>> >> >   
>> >> > 
>> >> >   com.work.productA
>> >> >   productA-submodule1
>> >> >   ${project.parent.version} <= this property
>> is
>> >> >   incorrectly evaluated
>> >> >   pom
>> >> >   import
>> >> > 
>> >> >   
>> >> > 
>> >> > 
>> >> > 
>> >> >   com.example.productA
>> >> >   productA-submodule1
>> >> >   ${project.parent.version} <= this property is
>> >> >   incorrectly evaluated
>> >> >   pom
>> >> > 
>> >> > 
>> >> > Product B:
>> >> > /pom.xml <= productB-parent (version 0.0.6-SNAPSHOT)
>> >> > => this uses the productA-sub2 as its parent
>> >> > 
>> >> > /submodule1/pom.xml <= productB-sub1
>> >> > => this uses the productB-parent as its parent.
>> >> > 
>> >> > The problem I am facing is that I expect that productB-sub1 is able to
>> use
>> >> > productA-sub2 as
>> >> > parent. Because 

Re: Incorrect evaluated project.parent.version in child pom

[Roy Lenferink]

Hi Alexander,

Thanks for thinking with me!

I forgot to mention that I _do_ make use of the maven-dependency-plugin with 
the 
copy-dependencies goal to copy my dependencies to the target/dependencies/ 
folder. This is being
executed in the clean phase [1]. If I move it to e.g. the compile phase then 
the compile phase starts
failing. Could it be the maven-dependency-plugin being the one throwing the 
error?

Regards,
Roy

[1] https://s.apache.org/rlenferink-mvn-1

On 2020/10/28 01:22:39, "Alexander Kriegisch"  wrote: 
> Thanks Roy,
> 
> I noticed that the actual build lifecycle (goals like validate, compile, 
> install) works as expected. The problem seems to be in the clean lifecycle, 
> i.e. possibly somewhere in the Maven Clean Plugin. No matter if I use the 
> default plugin version 3.5 or upgrade to 3.1.0, the problem occurs when 
> calling 'mvn clean' in directory 'productB'. Maybe you should raise an issue.
> -- 
> Alexander Kriegisch
> https://scrum-master.de
> 
> 
> Roy Lenferink schrieb am 28.10.2020 02:18 (GMT +07:00):
> 
> > Hi Alexander,
> > 
> > I just created a test project sketching the scenario I am having. See the
> > following repo:
> > https://github.com/rlenferink/maven-properties-project
> > 
> > I put the instructions for testing in the README. 
> > 
> > In my text example there where indeed some mismatches, I hope the repo with
> > sample data
> > resolves those unclarities.
> > 
> > Hope someone can clarify whether this is expected Maven behavior or not.
> > 
> > Best regards,
> > Roy
> > 
> > On 2020/10/25 02:39:12, "Alexander Kriegisch"  
> > wrote:
> > 
> >> Hello Roy.
> >> 
> >> Your textual description is nice and contains a lot of information, but
> >> why not attach or link to a simple but complete reproducer project? The
> >> reason I am asking is that in order to reproduce this, every reader
> >> needs to carefully try to recreate your situation manually. Errors in
> >> doing so are likely, especially given the following facts:
> >> 
> >>   -- Your directory layout is rather unconventional.
> >>   -- Your sample artifact naming is cryptic.
> >>   -- You submodule artifact names differ from directory names.
> >>   -- You seem to have an artifact named productA-sub1, but also one
> >>  named productA-submodule1. Are they the same or different? If they
> >>  are the same, why would you define a dependency on the parent
> >>  module which probably has POM packaging?
> >> 
> >> Let the POMs speak for themselves, please. Thank you.
> >> 
> >> Cheers
> >> -- 
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >> 
> >> 
> >> Roy Lenferink schrieb am 23.10.2020 17:11 (GMT +07:00):
> >> 
> >> > Hello fellow Maven users,
> >> > 
> >> > At $work a problem occurs with evaluation the ${project.parent.version} 
> >> > from
> >> a
> >> > child pom.
> >> > 
> >> > The product structure in question:
> >> > 
> >> > Product A:
> >> > /pom.xml <= productA-parent (version 10.2.4-SNAPSHOT)
> >> > 
> >> > /submodule1/pom.xml <= productA-sub1
> >> > => submodule1 uses productA-parent as parent
> >> > => submodule1 contains submodule2 in its modules section =>
> >> > ../submodule2
> >> > 
> >> > /submodule2/pom.xml <= productA-sub2
> >> > => submodule2 uses submodule1 as parent with relativePath ../submodule1/
> >> > 
> >> > Submodule2 has a dependency which is activated in a profile which refers 
> >> > to
> >> > submodule1:
> >> > 
> >> >   
> >> > 
> >> >   com.work.productA
> >> >   productA-submodule1
> >> >   ${project.parent.version} <= this property 
> >> > is
> >> >   incorrectly evaluated
> >> >   pom
> >> >   import
> >> > 
> >> >   
> >> > 
> >> > 
> >> > 
> >> >   com.example.productA
> >> >   productA-submodule1
> >> >   ${project.parent.version} <= this property is
> >> >   incorrectly evaluated
> >> >   pom
> >> > 
> >> > 
> >> > Product B:
> >> > /pom.xml <= productB-parent (version 0.0.6-SNAPSHOT)
> >> > => this uses the productA-sub2 as its parent
> >> > 
> >> > /submodule1/pom.xml <= productB-sub1
> >> > => this uses the productB-parent as its parent.
> >> > 
> >> > The problem I am facing is that I expect that productB-sub1 is able to 
> >> > use
> >> > productA-sub2 as
> >> > parent. Because productA-sub2 contains a dependency to productA-sub1 I
> >> expect
> >> > that dependency
> >> > will be evaluated correctly. However, it is not and the
> >> > ${project.parent.version} in productA-sub2
> >> > is evaluated to the version of productB-parent.
> >> > 
> >> > The extensive error message:
> >> > 
> >> > [ERROR] Non-resolvable import POM: Failure to find
> >> > com.work.productA-sub1:pom:0.0.6-SNAPSHOT in  was cached in
> >> the
> >> > local repository, resolution will not be reattempted until the update
> >> interval
> >> > of  has elapsed or updates are forced @
> >> > productA-sub2:[unknown-version],
> >> >
> >>