[
https://issues.apache.org/jira/browse/ARTEMIS-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617006#comment-17617006
]
ASF subversion and git services commented on ARTEMIS-4048:
----------------------------------------------------------
Commit 8cba446e2b1fd2259c1b07a960adcb47158c666c in activemq-artemis's branch
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=8cba446e2b ]
ARTEMIS-4048: stop -all client modules needlessly grabbing their own -SNAPSHOT
sources during build
- Always produce the original basically-empty sources jar for the
module, before the shading, meaning its always available.
- Do the same for the main jar, to avoid the shading operating on a
previously-shaded renamed output from a prior run if not cleaning.
> stop the '-all' client modules grabbing their own -SNAPSHOT sources
> unnecessarily during build
> ----------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-4048
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4048
> Project: ActiveMQ Artemis
> Issue Type: Task
> Affects Versions: 2.26.0
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Major
> Fix For: 2.27.0
>
>
> The three '-all' partial-shaded uber client modules can each unnecessarily
> download their own 6MB previously-shaded -SNAPSHOT sources from
> repository.apache.org while they are being built, if a sufficiently new copy
> isnt already in the maven local repo. Typically this will be if a developer
> hasnt 'mvn installed' yet in a day, or as much as every build in a CI env
> that doesnt cache prior installed snapshot output. Taking GHA CI jobs as
> example, where 4 builds occur for the various jobs for each run, it can thus
> grab about 6x3x4=72MB of -SNAPSHOT sources unnecessarily on every push to a
> PR and/or main.
> The cause is that the shading is producing a sources jar, which naturally
> incorporates the original module sources itself (though it has no real
> content, in this instance), but finds this has not been prepared yet before
> the shading occurs (the parent pom arranges it at a later phase) so it has to
> go looking and downloads it if it doesnt find something 'up to date enough'
> in the local repo. The remote version is the already-shaded 6MB output of a
> prior shading run, rather than the modules original basically-empty one.
> The fix is to ensure the modules original [basically-empty] sources jar is
> always produced during the build, before the shading process, meaning it
> never needs to go looking for it and potentially then download it. Similarly,
> the modules original [basically empty] main jar should similarly always be
> created, so that the shading always operates on that, as opposed to
> potentially operating on the already-shaded renamed artifact output from a
> prior run, as it currently does if you dont do a mvn clean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
