-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSHADE-373: adds a property to skip manifest transformer application when transforming a source file. #59
Conversation
Hi @raphw , I wonder if it wouldn't be more consistent and correct to handle it at transformer level. So here is how I'm seeing it:
Does it makes sense for your case? |
I don't think that that's my problem: I shade the actual jar and the source jar. Doing so, I want to add a class-bundle name which I do not want to be part of the original, unshaded jar. I neither want it to be part of the source jar since the bundle name identifies the jar file uniquely within OSGi. If a tool (Exclipse in this case) depends on both jars, the actual jar and the source jar, on it's OSGi class path, this resolution will fail since both jars specify the same unique name. I need to be able to inject this unique name into the shaded jar file without also injecting it into the shaded source jar. Is there a better way to do this? The problem is reproduced here: https://github.com/raphw/byte-buddy/blob/master/byte-buddy/pom.xml and breaks Eclipse. |
@raphw hmm, ok, let me try to reformulate because if I get it right I tend to see the "skip" fix as a quick workaround but an inaccurate (hope next part explains why). So my understanding is that createSourcesJar leads to a duplicated manifests in 2 different jars and this is an issue for you because eclipse uses both jars in an OSGi container. My understanding of this issue leads me to these two lacks in current plugin we can fix:
Here is a pseudo config illustrating that:
Does it make sense or did I get it wrong? |
Yes, your approach would probably be an even better solution since it still allows to shade the sources jar's manifest file. My particular issue is the When using the |
Ok so 2 questions/points:
|
I can do it but wonder how one would capture the |
Yes we can but just code it as another child (an enum or steing in the transformer directly. It is enough IMHO. |
From looking into the code, I don't quite understand where to begin. As it is now, the |
@rmannibucau Is this what you had in mind? I would not know how to test this appropriately, unfortunately. Any hits? Is this the right approach? |
@raphw i was thinking to do it for manifest transformer specificly since we cant break backward compatibility for transformer api - we had issues in last 2 versions and it was a very bad idea so hope we avoid it now. High level i was envisionning a filterManifestTransformer(transformers, phase) which would copy the list keeping only a single manifest transformer if any depending the phase - we can probably fail or log an error if ambiguous since we extract a single manifest transformer elsewhere already. Not as generic as your solution but does not need a compatibility layer which requires to add proxying logic we dont have yet and we can probably avoid. About the list vs String I think String can be enough but no strong opposition to a list. |
ca0423a
to
92da058
Compare
Alright, I adjusted the PR and added an integration test. Let me know if you want med to do anything more. |
…manifest-removal test + handle the case multiple manifest transformers are used for the same build
MSHADE-373 proposal
Dp you have an idea when this patch is being released? |
Manifest transformers in the shade plugin are often used to add meta-data for OSGi use since the shade and OSGi plugins are not overly compatible. If the same transformer is applied to the source plugin's manifest, the resolution will fail due to a duplicate bundle id.
It is therefore necessary to being able to opt-out of the manifest transformer when shading a source file. An example of this problem is documented in raphw/byte-buddy#894.
https://issues.apache.org/jira/browse/MSHADE-373