In the past, when something does modification to the classes other than the javac process, I had been putting the modified classes in another location that is higher on the classpath to avoid this problem. The largest example of this is with instrumentation from Cobertura, or some other coverage tool. In that case, the main motivation was because I didn't want the instrumented classes to end up in the war.
Would this type of an approach be more appropriate for your binary modification of the classes? Jeremy D. Young Web Architect O'Reilly Auto Parts Adam Murdoch <[email protected]> wrote on 05/03/2011 02:59:37 AM: > From: Adam Murdoch <[email protected]> > To: [email protected] > Date: 05/03/2011 03:07 AM > Subject: Re: [gradle-user] Compiler up-to-date check problem > > On 03/05/2011, at 2:23 PM, Marco Hunsicker wrote: > > Howdy, > > As mentioned in a previous message, my goal is to have some sources > recompiled after they were modified. The modification requires the > binary project information and therefore happens after the standard > compile phase. > > As the recompile task copies the configuration from the default > compile task, I was originally running into the problem that Gradle > was thinking that no recompilation was necessary. I did not > investigate why, but simply disabled the up-to-date check for the > output as there really is no need to perform up-to-date checking > here. This seemed to make things work as expected. Until I realized > that there is one additional factor: Ant. > > The modification might be performed very fast, such that the time > stamps of the source files and the corresponding .class files are > not recognized as different by Ant. Ant applies some platform > heuristics and might assume a 1 sec timestamp resolution which is > clearly not enough for my use case. > > I can workaround the problem (manually deleting the .class files in > question), but I wonder how you would assess the situation. Isn't > the additional Ant checking superfluous and only adds overhead, as > Gradle performs it's own logic and invokes the compile task only > when deemed necessary anyway? Are there plans to move away from Ant > under the hood to eliminate such idiosyncrasies? > > Yes, and yes. Definitely. We just haven't gotten around to it yet. > > > Please let me know if you think the issue warrants a Jira. Thanks. > > That would be useful. Thanks. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ยง 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
