Clarify that <dependency> is needed if tiles are defined in same project

[udalrich]

I have the following source directory structure

pom.xml
tiles
  pom.xml
  a-tile
    pom.xml
    tile.xml
components
   foo
      pom.xml
      src/...
   bar
      pom.xml
      src/...

The pom for foo uses a-tile. However, maven does not realize this dependency exists, so if I do

mvn install --pl components/foo --am 

from the root directory (i.e., build foo and its dependencies, maven will only build foo, components and the root directory, not the tiles. Adding

<dependency>
  <groupId>me.tiles</groupId>
  <artifactId>a-tile</artifactId>
  <version>1.1</version>
  <optional>true</optional>
</dependency>

to foo/pom.xml fixes this.

I am not familiar enough with maven to know if a plugin can add a dependency like this, but I would not be surprised if it could not. If this cannot be added, then the documentation should clarify that this dependency needs to be added.

By adding <optional> to the dependency, it prevents other modules from gaining an implicit dependency on the tile.

[rvowles]

You are correct in assuming this, lifecycle plugins come too late for two things - variable resolution for dependencies and... dependencies.

As such, one of my current projects has this issue as well, and the optional concept is an interesting workaround. This would also work around the issue where SNAPSHOT dependencies are not allowed in tiles (because there is some bug in the resolver).

[talios]

Caveat: this is a thought stream of a solution. Here be dragons.

If the tile was listed as a <module>xxx-tile</module> as part of the multi module build, I wonder if we could, at the start of our extension ( prior to tile resolution ), look at the list of reactor-modules, and simply fork a maven process for that tile running install on any <packaging>tile</packaging> module prior to running the tile resolution.

This would essentially be automating the process one would normally have to do manually. One would probably limit this call path by a config parameter as well.

Thoughts or alternatives?

[rvowles]

Is the module list mutable? I know it has been read by then, so that is also possible. I suppose we also have to make sure we would be able to get all of the parameters that were passed.

[talios]

With #65 being merged/released, is this ticket obsolete?

[udalrich]

looks like it,although I haven't tried the new release

On Tue, Mar 27, 2018, 4:42 AM Mark Derricutt notifications@github.com wrote:

With #65 https://github.com/repaint-io/maven-tiles/issues/65 being merged/released, is this ticket obsolete?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/repaint-io/maven-tiles/issues/72#issuecomment-376444216, or mute the thread https://github.com/notifications/unsubscribe-auth/ALnaj2G83YvSS6WCwIeB0-FUjuYe-r9hks5tiftfgaJpZM4QNRmn .

[bvella]

I think the only way to solve this is the somehow inject a dependency on the tile in the project. I am no maven expert and as such I don't know if this is possible.

What #65 does is let you build the tiles and the modules that use the tiles in one go, but will not pick the tile up as a dependency when using mvn install --pl components/foo --am. However, it does solve the title of the issue, i.e. one does not need to specify a dependency on the tile if the tile is in the same project.

[talios]

On 31 Dec 2018, at 2:34, Brian Vella wrote:

but will not pick the tile up as a dependency when using mvn install --pl components/foo --am. 

Just what I just said in my reply, I guess I should have read all the emails before replying :)

---

"The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold.

Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt

[bvella]

I did some experiments on injecting dependencies. More detail in issue #63