Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Child modules never built #13

Open
ava1ar opened this issue Aug 18, 2021 · 5 comments
Open

Child modules never built #13

ava1ar opened this issue Aug 18, 2021 · 5 comments

Comments

@ava1ar
Copy link

ava1ar commented Aug 18, 2021

Hi!

Thanks for implementing such nice thing - I was thinking about making something like this to manage out complex structure maven project and speed up the build. However somehow it never builds any child modules except the parent project.

Here is the debug output:

java -jar C:\Apps\mvnmin\mvnmin-1.0.1-jar-with-dependencies.jar -p
[
    M xxx-module1/src/main/java/com/org/Class1.java
    M xxx-parent1/xxx-module2/src/main/java/com/org/Class2.java
]
found 1 projects
mvnmin.xml does not exist, skipping.
modules to build: [com.mlp:xxx]
Reactor@2007328737 [
    reactorNumber:0
	skipReactor:false
	modulesInReactor:[.*]
	pathFromProjectRoot:pom.xml
	singleThread:false
	activeModules:[com.org:xxx]
	extraParams:
]
com.org:xxx

Basically, xxx-module1 is a jar module under the parent, xxx-parent1 is a pom module, with xxx-module2 jar module under it. If I understand correctly, mvnmin supposed to select xxx-module1 and xxx-module2, but it picked only parent pom project com.org:xxx and nothing else. Am I doing something wrong here?

@ivanjensen-ep
Copy link
Collaborator

Hi @ava1ar,

I would expect xxx-module1 to be under xxx-parent and a peer to xxx-module2. is there a reason module1 is at the top-level and module2 under the parent?

Could you include the output of the command with --all included to see all the pom.xml files mvnmin can find (scanning the file system):

java -jar C:\Apps\mvnmin\mvnmin-1.0.1-jar-with-dependencies.jar -p --all

Thanks,

-Ivan

@ava1ar
Copy link
Author

ava1ar commented Aug 19, 2021

is there a reason module1 is at the top-level and module2 under the parent?

Maven allows such mixed hierarchies and it works well for my use case: module1 is independent (i.e. "core"), while module2 is part of the larger group (i.e. it is named as "codec-a", there are also "codec-b", "codec-c", etc - all under "codecs" pom project).

@ava1ar
Copy link
Author

ava1ar commented Aug 19, 2021

Output of all modules (slightly altered):

com.aaa.bbb.ui:bbb-ui-appium
com.aaa.bbb.ui:bbb-ui-common
com.aaa.bbb.ui:bbb-ui-ranorex
com.aaa.bbb.ui:bbb-ui-selenium
com.aaa.bbb.ui:bbb-ui-synq
com.aaa.bbb.ui:bbb-ui-webdriver
com.aaa.bbb:bbb-actors
com.aaa.bbb:bbb-aeron
com.aaa.bbb:bbb-agent
com.aaa.bbb:bbb-api-trader
com.aaa.bbb:bbb-artio
com.aaa.bbb:bbb-avro-generator
com.aaa.bbb:bbb-binary
com.aaa.bbb:bbb-binary-generator
com.aaa.bbb:bbb-boe
com.aaa.bbb:bbb-cmf
com.aaa.bbb:bbb-cmf-generator
com.aaa.bbb:bbb-codegen
com.aaa.bbb:bbb-common
com.aaa.bbb:bbb-compare
com.aaa.bbb:bbb-core
com.aaa.bbb:bbb-csidentity-proxy
com.aaa.bbb:bbb-csouch
com.aaa.bbb:bbb-db
com.aaa.bbb:bbb-elastic
com.aaa.bbb:bbb-email
com.aaa.bbb:bbb-epa
com.aaa.bbb:bbb-epa-emulator
com.aaa.bbb:bbb-exec
com.aaa.bbb:bbb-fix-generator
com.aaa.bbb:bbb-fix42
com.aaa.bbb:bbb-fix44
com.aaa.bbb:bbb-fix50
com.aaa.bbb:bbb-glue42
com.aaa.bbb:bbb-glue42-actor
com.aaa.bbb:bbb-http-client
com.aaa.bbb:bbb-ilink3
com.aaa.bbb:bbb-kafka
com.aaa.bbb:bbb-limits-refdata
com.aaa.bbb:bbb-load-runner
com.aaa.bbb:bbb-marketdata
com.aaa.bbb:bbb-mbus-generator
com.aaa.bbb:bbb-meteor
com.aaa.bbb:bbb-mirror
com.aaa.bbb:bbb-mmw
com.aaa.bbb:bbb-mmw-shm
com.aaa.bbb:bbb-multicast
com.aaa.bbb:bbb-nvpx
com.aaa.bbb:bbb-obs
com.aaa.bbb:bbb-ouch
com.aaa.bbb:bbb-pillar
com.aaa.bbb:bbb-posttrade
com.aaa.bbb:bbb-protocols
com.aaa.bbb:bbb-rbmq
com.aaa.bbb:bbb-remote-file
com.aaa.bbb:bbb-remote-ssh
com.aaa.bbb:bbb-replay
com.aaa.bbb:bbb-rest
com.aaa.bbb:bbb-sbe-generator
com.aaa.bbb:bbb-sentinel-gui
com.aaa.bbb:bbb-sessions
com.aaa.bbb:bbb-socket
com.aaa.bbb:bbb-solace
com.aaa.bbb:bbb-soms
com.aaa.bbb:bbb-ssh
com.aaa.bbb:bbb-standalone
com.aaa.bbb:bbb-tibrv
com.aaa.bbb:bbb-trace
com.aaa.bbb:bbb-tse
com.aaa.bbb:bbb-ubsouch
com.aaa.bbb:bbb-ui
com.aaa.bbb:bbb-websocket
com.aaa:bbb

So, the artifact structure is flat (except the ui part, which I would also want to make flat), while modules layout is tree-like.

@ivanjensen-ep
Copy link
Collaborator

Thanks for trying this out, I hope we can get you going.

The structure Is fine. And yes, mvnmin should be activating the two modules you are expecting. And it shouldn't be activating parent1 as nothing has changed in that module.

Currently, the algorithm starts at each of the changed files and walks up the directory tree looking for a pom.xml file, and stops at the first it finds.

@ava1ar
Copy link
Author

ava1ar commented Aug 19, 2021

Thanks! Let me know if I can help troubleshooting this further. I really like the project, so would definitely try to contribute to it in future!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants