All CLA requirements met.

I tried to review the failing build, but I can't access it ( status 401 ). Can anyone look into what is going on?

FWIW, the tests consistently fail for me, both before and after my patch with

[INFO] Running TestSuite
[ERROR] Tests run: 60, Failures: 1, Errors: 0, Skipped: 59, Time elapsed: 1.574 s <<< FAILURE! - in TestSuite
[ERROR] setUp(com.microsoft.aad.msal4j.RefreshTokenIT)  Time elapsed: 1.443 s  <<< FAILURE!
java.lang.RuntimeException: Error getting user from lab: Error acquiring token from Azure AD: Error getting certificate from keystore: KeychainStore not found
	at com.microsoft.aad.msal4j.RefreshTokenIT.setUp(RefreshTokenIT.java:25)

I did not find a way to make them pass, maybe they are masking a problem with my submission, but I can't tell right now.

@rombert Yes, the build issues are not related to your changes. Will take a look at what's causing this and will update this thread once it is fixed.

Sounds good, thanks @sangonzal !

@rombert The build is now fixed (had to update the build vm to use newer version of maven), but I am not able to re-trigger the build on your branch since it's from a forked branch. Easiest way might be to just close this PR and reopen a new one from the same branch.

Before doing so though, could you provide some more context on why you'd like to get this merged in? I'm not very familiar with OSGI bundles, but my understanding is that you can either use a command line tool such as bnd to convert a JAR to a bundle which you could then deploy, or you can just include the JAR directly into your bundle. (both solutions which wouldn't require including the maven plug-in directly into MSAL)

Thanks for looking into this @sangonzal . The main reason for adding OSGi metadata to MSAL directly is that it will become immediately consumable by any downstream consumer. The alternatives you mentioned are valid, but all have their downsides:

• repackaging means that I have to rebuild/redeploy the artifact, and redo the work each time the artifact gets a new version
• wrapping the artifact in my own bundle leads to 'fat' artifacts, which are less cohesive, take longer to deploy and restart ( many more classes ) and potentially lead to conflicts - two different consumers may wrap the classes twice; worse even - they may reexport them which leads to inconsistent class spaces

Adding OSGi metadata to the "original" artifact is IMO a best practice and it's unintrusive - just some extra entries in the MANIFEST.

Thanks for explaining. This looks fine to me. @SomkaPe can you please review?

@sangonzal , @SomkaPe - should I resubmit the PR is it fine to merge as-is?

@rombert Yes please re-submit so it's run against the new build vm. Once it's green I will merge it in.