[discussion] Support of maven project, modules, parent

[cmoulliard]

Discussion

This ticket list the different maven project combinations and the problems that currently we must resolve

1. Multiple independent components under a single git repo without a parent pom

demo
  .git
  .mvn
  fruit-backend-sb
  fruit-client-sb
  mvnw

• Binary push: OK
• Source push: OK
• Build mode: KO because of the s2i following problem as a pom.xml is needed within the /path of the project

2. Multi-module maven project under a single parent

demo
  .git
  .mvn
  fruit-backend-sb
  fruit-client-sb
  mvnw
  pom.xml

• Binary push: OK
• Source push: KO as parent pom doesn't get pushed along with the module code and therefore maven
  cannot build (unless parent is already published in a publicly available maven repo)
• Build mode: OK

3. Multi-module maven project under a single parent

Remark: The children don't reference the parent (BAD organization in terms of maven project)

demo
  .git
  .mvn
  fruit-backend-sb  // The children don't reference the parent
  fruit-client-sb       // The children don't reference the parent
  mvnw
  pom.xml

• Binary push: OK
• Source push: OK as parent pom doesn't exist for all intent and purposes of building the children
  modules. However, this can only work if nothing in the parent is needed by the children (though
  the same would happen with a regular maven build)
• Build mode: OK

[cmoulliard]

I propose that we only support project structure 1. and 2. Make sense @metacosm ?

[cmoulliard]

For project type2, this is I think the responsibility of the CLI tool to push in this case the project with : pom.xml, moduleA, moduleB,....,moduleX. WDYT @metacosm ?

[metacosm]

I agree that we should only support types 1 and 2 since these are the logical organizations that people are likely to use. We should also support the most common use case which is: single module per git repo.

For project type2, this is I think the responsibility of the CLI tool to push in this case the project with : pom.xml, moduleA, moduleB,....,moduleX. WDYT @metacosm ?

I'm not sure as this means that some of the intelligence needs to move to the client and I think that the operator should actually handle that case. That said, I'm not sure what can be done without the client informing the operator about it. I really don't like this because that means having to handle special cases in the client. Then if consider that's only one special case among possibly many for different build systems and you start to see why I don't really like opening this Pandora's box.

[cmoulliard]

That said, I'm not sure what can be done without the client informing the operator about it.

Even if the client informs the operator, all the code should be pushed or at least the module plus the parent pom.xml

[metacosm]

That said, I'm not sure what can be done without the client informing the operator about it.

Even if the client informs the operator, all the code should be pushed or at least the module plus the parent pom.xml

And that's exactly what I would like to avoid because that requires the client to know about maven (and gradle, and npm and…). Problem is: I'm not sure how to make it work otherwise… :(

[cmoulliard]

Something else to be considered is :

• Do we want to continue to use the s2i image which suffers from the limitation or restriction that a pom.xml is needed at the root of the project from where mvn is executed OR
• That we use too for the Tekton build our mvn-jdk image where we can define the contextDir and moduleName OR
• That we use JIB to build the image from the code source

[cmoulliard]

And that's exactly what I would like to avoid because that requires the client to know about maven (and gradle, and npm and…). Problem is: I'm not sure how to make it work otherwise… :(

The only solution that I see is to ask a question to the developer with the CLI in order to know if this is :

• A maven project with only one module -> 1 component
• A maven project with several modules + parent -> x components
• A maven project with several modules without pa rent -> not supported

[metacosm]

And that's exactly what I would like to avoid because that requires the client to know about maven (and gradle, and npm and…). Problem is: I'm not sure how to make it work otherwise… :(

The only solution that I see is to ask a question to the developer with the CLI in order to know if this is :

* A maven project with only one module -> 1 component

* A maven project with several modules + parent -> x components

* A maven project with several modules without pa rent -> not supported

This still requires the client to know about maven…

[cmoulliard]

This still requires the client to know about maven…

Why. According to the response, you copy/push the content of the current folder for the scenario - 1 component and for the second scenario (x comonents) all the files and sub-folders

[metacosm]

This still requires the client to know about maven…

Why. According to the response, you copy/push the content of the current folder for the scenario - 1 component and for the second scenario (x comonents) all the files and sub-folders

How does the tool know that the directories are actually maven modules that should be considered as components without knowing about maven?