-
Notifications
You must be signed in to change notification settings - Fork 110
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
incrementalBuild breaks with different groups using same resources #209
Comments
This one is tricky :) |
Thanks go out to my coworker who stresses wro4j with cascaded imports as if there were no tomorrow. :) The only reason it works on the first run seems to be that the directory "generated2" does not exist. See ro.isdc.wro.maven.plugin.Wro4jMojo.isIncrementalCheckRequired():
|
A possible solution could be holding a storage per group (which is expensive), or treating import statements differently when dealing with change detection... |
My first idea was to store the hashes not only by path
but also by group
But I'm not sure if this is a good solution. |
This is similar to have storage per group. The disadvantage is that there will be multiple checks for change for the same resource when it is referred from different groups. I would prefer not checking twice for change. Instead of keeping a |
In my project muffl0n/wro4j-scss-test I have two different groups using two different scss-files:
wro.xml:
The base.scss and base2.scss however both import the same header.scss:
On the first run the plugin does just fine:
But after changing the header.scss from
to
only the first group get's regenerated:
The problem seems to be that on the first plugin execution "css_test" the new fingerprint for header.scss get's written to the fallbackStorage. On the second execution "css_test2" the "previousFingerprint" is the one that was just written to the fallbackStorage by the first execution and not that one that was written there by the previouse run of the plugin. See: ro.isdc.wro.maven.plugin.support.ResourceChangeHandler.isResourceChanged(Resource).previousFingerprint
So in fact, if two executions share the same resources they have a problem sharing the same fallbackStorage, too.
The text was updated successfully, but these errors were encountered: