HannesWell commented 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 while 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
