[MGNLEE-162] Some clover artifacts end up in the bundle Created: 29/Sep/09  Updated: 23/Jun/14  Resolved: 28/Oct/09

Status: Closed
Project: Magnolia DX Core
Component/s: build / bundling
Affects Version/s: 4.1.1
Fix Version/s: 4.1.2

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled

 Description   

unzip -l magnolia-enterprise-bundle/4.1.1/magnolia-enterprise-bundle-4.1.1-bundle-jdk15.zip | grep clover

If we trust the jar names, this shouldn't cause any other issue than having silly folder names; the only "clover jar" would be the newsletter bundle jar, which is empty anyway.

Currently no idea how this happened.



 Comments   
Comment by Magnolia International [ 28/Oct/09 ]

clover-instrumented get installed in our local repositories, and somehow, despite them being built with the correct name (...-bundle-clover.zip for instance), they end up being copied to the local repo as ..-bundle.zip, thus overriding the "real" bundle. This does not affect the deploy phase, which is why this is only occuring when the same local repo was used to build module-bundles and the ee-bundle, for instance.

We can avoid this by using the instrument-test goal instead of instrument.
See http://forums.atlassian.com/thread.jspa?messageID=257322053

This will get fixed by BUILD-23 (parent-pom-10)

Comment by Magnolia International [ 28/Oct/09 ]

This will not happen anymore after projects have moved to parent v10.
In the interim, for safety, before doing a release, clean your local repo.

Generated at Mon Feb 12 05:27:17 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.