-
-
Notifications
You must be signed in to change notification settings - Fork 302
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
bnd-maven-plugin: Problems with #1333 #1346
Comments
This is how bnd works, I am rather loath to special case thing here.
I am not sure what you mean here.
I don't understand this. The manifest can only be generated when you build the jar, and the main point of your recent requests was to avoid building the jar. It you always want the manifest built, then we also need to always build the jar. |
|
The jars are input to the builder whose lastModified time it used to decide whether to build the bundle.
Yes it can be changed but this would be rather the rare case as most of maven assume you use the default file layout.
The manifest is built as part of building the in-memory jar. You want to avoid building the in-memory jar in incremental builds which means it will not build the manifest. If the archiver plugin always rewrites the manifest and then the bnd-maven-plugin were to then always overwrite that manifest, then the bundle output will always appear to have been changed defeating the time savings of the incremental build. Or am I missing something here? It seems the bug is in the archiver plugin if it always writes a manifest even where there are no incremental changes. |
yes, and that would be ok. However, in the Constructor of the Jar the whole content is scanned (and if I'm not mistaken the lastModified time of all entries is used, too). As a project can have easily more than 50 dependencies, that load is significant - and just to find out there's nothing to do.
yes, in an incremental build when there's no change you do not want to build the Jar in memory. However, if it's not an incremental build or if there is no Manifest at the target location, then you'd need to build the Jar so that the Manifest can be written.
It's even worse, as without my patch the archiver plugin was overwriting the manifest (it comes later in the lifecycle!). With my patch it will not overwrite the manifest if one is already present (and the config option to use an existing manifest is on). It's just that with your latest changes I sometime see the "plain" Manifest instead of the bnd-generated one. Which leads me to believe that starting from a clean directory the bnd-maven-plugin somehow decided nothing is to do and then the m2e-archiver took over to generate the manifest. It worked before, also with my suggested changes. That's why I think there must be some oversight in the check when to generate the Jar and thus the Manifest. I'll try to locate the problem exactly, as of course it does work correctly if I just clean the project... |
I made PR #1347 to use BuildContext.isIncremental. If it returns false, the plugin will always build. |
I added another commit to PR #1347 to defer setting the builder classpath until the decision is made to build the jar. |
I tried out your branch and 3) seems fixed now |
Please try the latest from master to see if your issues are attenuated. |
I used it for a few days now and it looks good so far. Thanks! |
Good, so I will close this issue. If you encounter additional problems, please open a new issue. |
Quoting from #1333 there are several problems with this change:
and
and
The text was updated successfully, but these errors were encountered: