[GitHub] [felix-dev] HannesWell edited a comment on pull request #124: [FELIX-6493] Extend is-up-to-date logic of Manifest goal

[GitBox <gi...@apache.org>]

HannesWell edited a comment on pull request #124:
URL: https://github.com/apache/felix-dev/pull/124#issuecomment-1003042843


   > > > * consider pom.xml modifications in up-to-date logic
   > > 
   > > 
   > > Actually the pom's of all parent projects have to be considered as well. I'm about to update this PR accordingly.
   > 
   > I'm not sure if this is not a bit out of scope. I would assume that if one updates the parent he also has to update the child to reflect the new version?
   
   For incremental builds in IDE's like Eclipse this is actually useful. If one modifies the parent pom (in a way that also affects the child's generated Manifest), Eclipse triggers an incremental build of parent and child project (I assume the ResourcesPlugin checks the project inter-dependencies). If the manifest plugin does not check the parent pom it falsely assume the manifest is up to date (because the child's pom did not change) and skips the execution. In order to re-generated the manifest a user would have to trigger a full build or modify the child pom manually. But especially during development between releases it is not necessary to change to version of the parent which would require adjustments of the child,
   
   
   > What I actually wonder is: Is there really a measurable benefit for all those stale checking? I could only think of a resource that was modified and thus do not change the generated manifest but does it really impact performance to regenerate the manifest in those scenarios?
   
   From my recent observations the BND-Analyzer takes some time for larger projects with many classes to scan. So I think it is not worthless. At the moment `biz.aQute.bndlib` version 5.1.1 is used while 6.1.0 is available maybe the new major version also brings performance improvements.
   
   But what I'm pretty confident about is that checking for new or modified Java-source files in anyJavaSourceFileTouchedSinceLastBuild() is not necessary because `isUpToDate()` checks the ${project.build.outputDirectory} for later modifications and the compiled class files are written there. So additional or modified java classes will cause later modifications in that directory.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@felix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org