Fix OSGi manifest for no_aop: remove unnecessary aopalliance package

[ctranxuan]

The MANIFEST.MF of the no_aop jar file shouldn't declare
an OSGi import package of org.aopalliance.intercept since no aop
is used.
The issue comes from the fact the maven-bundle-plugin generates
the MANIFEST.MF from the orginal source files and not the munged
source files for the 'guice.with.no_aop' profile.
This commit fixes the issue by:

• defining the proper source location for the maven-bundle-plugin
  for the "aop" and "no_aop" profile
• changing the phase of munge-maven-plugin to "generate-sources":
  this ensures the munge-maven-plugin is called before the
  maven-bundle-plugin, so that this latter one can use the proper
  source files to generate the appropriate MANIFEST.MF

By removing this import, using the guice_no_aop.jar within an OSGi
container does no more require to deploy an OSGi bundle of the aopalliance.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[mcculls]

This and the related property changes actually has no effect because this setting controls where SCR (ie. declarative services) files are generated and not where the source is loaded from. In fact the bundle plugin analyses the bytecode to generate OSGi metadata and doesn't scan the Java source.

The reason the aopalliance import is appearing in the 'no-aop' jar is because bundleplugin 3.5.0 attempts to merge in headers from the main jar into forked builds, like the 'no_aop' munged build. This overwrites the custom 'no_aop' headers.

So the key difference is your change to the munge-maven-plugin phase on line 184 - changing that to generate-sources means the bundleplugin is no longer merging in those headers. I have an earlier pending PR that solved this a different way: #1173 - but both solutions are valid, just drop the SCR related changes here because they aren't necessary

[ctranxuan]

Damn, I was so focused on how configure the maven-bundle-plugin with another source directory that I've read srcLocation instead of scrLocation :/ And I didn't spot your PR was also fixing the issue. Thanks for the review!
I'll update the PR and let the Guice team decide what PR should be applied. Yours is fixing more stuff.

[sameb]

Closing this b/c there's no more no_aop variant of Guice.