Input files upTodate-check customization


(Pavel Trka) #1

Hello,

my problem is lack of possibilities to customize input files uptodate checking. I have exactly the same problem as described in this post but I cant ommit the dynamic part because we have to include SVN revision in the MANIFEST.MF. And as we are releasing very often adn SVN revision could be changed very frequently, this causes many unnecessary rebuilds.

I tried to study gradle source code and tried to remove MANIFEST.MF from update check but in case of input files this is very difficult. So instead of some nasty hacking I want to ask if there is some schedule for mentioned input update check customization possibility mentioned in the original post.

Thank you, Pavel


(Luke Daley) #2

So instead of some nasty hacking I want to ask if there is some schedule for mentioned input update check customization possibility mentioned in the original post.

There’s no formal schedule for this at this time.


(Pavel Trka) #3

Ok. Then I have to ask if somebody has some idea how to work around this problem :slight_smile:

I think the best conceptually simple solution would be removing MANIFEST.MF from input check but I found it very hard to accomplish with underlying data structures stored in DefaultTaskInput class. I have to admit I had not much time to study it…

Thank you, Pavel


(Peter Niederwieser) #4

Don’t you do a clean build for releases anyway? And for developer builds, you could refrain from adding the revision information, compensating for this where necessary.

Another option might be put classes directories on a project’s outgoing configurations (e.g. ‘archives’) rather than the Jars, or at least to reconfigure consuming tasks to use directories instead of Jars. Not sure if that’s feasible, but worth a try.

The last resort is to implement your own up-to-date check. One thing to note is that some tasks will have to rerun whenever the revision number changes (e.g. ‘jar’), and others won’t (e.g. ‘compileJava’, possibly ‘test’). I wonder if the classes/Jar discrimination isn’t a better way to deal with this, though.


(Pavel Trka) #5

Im affraid that we have quite unique structure and workflow - we dont do clean builds. We are producing incremental updates and as we have more than 40 constantly evolving components (one component = 1 jar), we are releasing new versions of some component nearly every day. In our workflow it doesnt matter if it is release or development build, the build is always done as incremental update based on what changed.

Im not sure if I undestand the second part of the answer well but I guess it is not solution also as my biggest problem is JAR files rebuild - someone changes one *.java in one component, does SVN commit, then he runs build. In ideal world only the class and jar belonging to component which he changed is built but as the MANIFEST.MF is changed thanks to changed revision, all jars are rebuild (the manifest is the same for every component, jar tasks are created dynamically in configration phase, one for every component).

Maybee I need to clarify the project structure - that this project is using one src directory which is partitioned by java packages to several sourcesets (components). All sources are compiled in one step and jar tasks are created dynamically, one jar task for every sourceset.


(Peter Niederwieser) #6

I don’t quite understand. If the manifest changes for all components, you’ll have to rebuild all Jars, or they will contain an outdated manifest.


(Pavel Trka) #7

I understand that this could be confussing but I dont need (maybee “want” is better word) to rebuild all jars.

When Im doing changes in source code of some component I only want to build and release that component, I dont want to touch others. Yes you can say that SVN revision changed and should be injected to all components (=rebuild) and it seems logical but we dont want that - we want other jars to remain untouched with MANIFEST.MF SVN revision from the time they were built. In other words, I dont want the SVN revision information to be the rebuilding trigger, that should be only *.class change.

Simply put I want full control of what I want include and what I want ignore in input upToDate check. I hope I clarified it little bit.

Other and maybe best solution would be to get own SVN revision for every component so then every MANIFEST.MF will contain own revision and that revision will be changed only if the source code of that component is changed and then I dont need to alter gradle input upToDate check. But there is some problem with current version of Ant SVN task and this doesnt work, it seems like some bug.

So for now Im trying to accomplish it some other way.


(Peter Niederwieser) #8

If you change source code of A and B depends on A, B will have to be rebuilt anyway. So let’s say B does not depend on A. Then you just have to make sure not to change the manifest input of B. You can do so by declaring the manifest in a ‘doFirst {}’ block. Then it won’t be part of the up-to-date check.


(Pavel Trka) #9

Our components are not dependent on each other, there is only one base component, every other component depends on it, but thats all.

doFirst - great tip, thank you, i think this could work.

Pavel


(Pavel Trka) #10

Just FYI if someone will need it too - it worked. Im banging my head against wall that I didnt came up with this obvious solution and was trying overengineered dirty hacks for couple of days :slight_smile: