[MSOURCES-115] aggregate-sources yields different results based on reactor
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- java
- Domain
- build-system
Research direction
Start by locating the aggregate-sources goal and how it gathers projects from the Maven reactor. Reproduce the issue by building a child project directly and then from the parent, comparing the generated source JAR contents. Done means aggregate-sources includes only the current project's children and produces identical artifacts in both build modes.
Written by the indexing model from the issue text.
Description
Raymond DeCampo opened MSOURCES-115 and commented
The main idea here is that depending on whether a particular project is built from the parent project or on its own, the sources jar generated by aggregate-sources may be different. IMO this attacks the repeat-ability of the build. The root cause is that aggregate-sources pulls in all the sources in the reactor.
Consider a three layer structure. One parent project at the top level, say foo-parent. Then two child modules at the next level, say foo-client and foo-server. Then some number of children of foo-client and foo-server where the actual Java code lives.
The poms for foo-server and foo-client have aggregate-sources set up. If a build is executed directly on foo-client for example, then the resulting source foo-client-sources-*.jar will have the source from the children of foo-client.
If a build is executed from foo-parent, both foo-client and foo-server are included in the reactor. Now the resulting foo-client-sources-*.jar includes the source code from foo-server's children as well as its own.
I would expect that the aggregate-sources target would only include the source of the children of the current project instead of the source from any project in the reactor. I would also expect that the build should result identical artifacts whether or not it is invoked from the parent project or not.
Affects: 3.0.1
- Dominant language
- Java
- Stars
- 37
- Forks
- 38
- Avg merge
- 22h 35m
- Merged PRs (30d)
- 6
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/maven-source-plugin
-
Fix Jenkins buildOpenbug priority:critical
Difficulty 3/5 1-2 days Newbie friendliness 48/100
apache/maven-source-plugin#311 · 1 comment ·
-
TestSourceJarMojo forks to generate-sources instead of generate-test-sourcesMay be free again @elharo claimed this 58 days ago, and no pull request is open. Openbug priority:major
apache/maven-source-plugin#304 · 3 comments · 1 assignee ·
-
bug priority:blocker
Difficulty 4/5 3-5 days Newbie friendliness 25/100
apache/maven-source-plugin#261 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
apache/maven-source-plugin#244 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
apache/maven-source-plugin#239 ·
All issues in apache/maven-source-plugin
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
aoqia194/leaf-loader#19 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
apache/streampark#4521 ·
-
Update license yearOpen0 - Backlog 1 - Ready documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
cbor
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
FasterXML/jackson-dataformats-binary#844 ·
Maintainers usually reply within 1 day