Bug in CandyProcessor.processCandies
Hi, there seems to be a problem in the CandyProcessor.processCandies line 155 .
if (newStore.equals(candiesStore)) {
logger.info("candies are up to date");
return;
}
This condition checks if the candys are present in the .jsweet folder. The .jsweet folder is never deleted, this acts like a cache and after the first clean/build this condition will always be true. The problem is that in the maven plugin we define : <candiesJsOut>target/js/candies</candiesJsOut> which is not processed after the first time because of the above condition which always exit the function.
Or there process flow has an issue or the .jsweet folder should be placed in the /target/ folder and be erased at each build.
This code is quite tricky but I believe it is ok though. If you look at the implementation of CandyStore.equals, it uses a containsAll, which in turn will compare the CandyDescriptor instances (stored in the store). The CandyDescriptor.equals() function contains a test on the last update timestamp...
All this means that newStore.equals(candiesStore) will be false if any of the candy jar in the classpath has been updated (timestamp-wise).
@lgrignon, I am missing something? @Eclesia, does it make sense?
what you say is right but it's not the issue here. Imagine the following :
- build the projet once -> the *.js files are extracted in the .jsweet folder
- update your build configuration and add the target/js/candies
- build the projet again -> nothing gets extracted because they are already extract in the .jsweet folder in the end the *.js of the candys are not extracted in the target folder
From what I understand the target/js/candies parameter is passed down to the candy-management classes which uses it to extract the *.js if it's not already done. The candy-management classes should not take the 'target/js/candies' and always extract the *.js in the .jsweet folder, and only afterward if a 'target/js/candies' is given then it should copy the *.js to the requested folder. (I believe it should be the maven plugin which makes the copy, not the candy-management classes)
Right. I get it now. I don't think that it is too critical for now but it should be fixed at some point. Thanks for your insights!