This is a follow up on the “Maven local issues” discussion from the gradle-dev mailing list. But as this follow up is more user oriented, I decided to post it here rather than replying to that thread.
As pointed out on the mailing list there really are a number of combos to consider. The 2 specifically I use most and have question about are:
sharing from gradle build to maven locally - as I understand it, GRADLE-2762 (via John’s Pull Request) solves this when using mavenLocal() * sharing from one gradle build to another locally - as I understand it there is no concept currently of building the SNAPSHOT in a way to share it locally with another build. Instead I’d need to publish the SNAPSHOT to my remote repository and have the second build pull the SNAPSHOT down from the remote repository, and make sure I remember to use --refresh-dependencies so that it actually does pull it down. Is there a better way for this scenario as of this moment? And if not, is there a Jira I can watch/follow for this feature?
P.S. Out of curiosity, even though I voted for GRADLE-2762 and added myself as a watcher I never got any emails sent to me when it was resolved. Does Gradle Jira simply not send notification emails? And if so, why not?
For the second scenario, why wouldn’t you just publish/resolve with a local repository (not mavenLocal)?
I believe that doing so will remove your need to use ‘–refresh-dependencies’. Certainly you could do something in your build script using ‘cacheChangingModulesFor’ to make this automatic.
“My build” is Hibernate. What would you suggest as the “local repository” for Hibernate that would work for all people that check it out and build it? And the trouble is, I do also need to publish to the remote repository. In fact, that is the more common case. This scenario/need comes about when I am trying to test out fixes I make in Hibernate in other builds.
As a real-life example, I am adding support for some PostgreSQL specific features in Hibernate at the moment. So I created a project that defines dependency on Hibernate SNAPSHOT, points to a PostgreSQL database and makes all the PostgreSQL-specific calls. Your suggestion requires that I change the Hibernate build, which in my opnion is inverted. The need/desire to comsume this locally is really driven by the consuming project (imho). But I also dont think changing the consuming project to account for this specifically is the right answer either. Assume the consuming project here is an app server that uses Hibernate as its JPA provider and I want to locally test these changes within that app server. I am not a fan of locally changing these builds just for my transient desire to build/test locally.
I guess ultimately using mavenLocal will work in both situations assuming the consuming project defines mavenLocal() as a repository (and assuming they use a Gradle version with GRADLE-2762 fixed). But that makes me nervous as I seem to remember seeing y’all discussing removing support for it. And really your suggestion has the same problem; both projects have to agree on this same “local repo”
You don’t need to change the hibernate build: you just need a way to publish both locally and remotely. This is exactly what the ‘maven’ plugin provides, and is very is easy to add to your build. That said, this isn’t supported out-of-the-box.
The coordination between the consumer and producer is a bit tricker, as you point out. There’s no ‘standard’ local repository for Gradle like there is for Maven. The ideal solution would likely be one where Gradle was aware of the presence of the ‘hibernate’ project and could automatically substitute a regular module dependency with a local publication.
Currently, any solution requires that the same local repository be declared in both builds: whether that is ‘mavenLocal()’ or a custom local ivy/maven repository.
A nice intermediate solution might be a shared ‘gradleLocal’ plugin, that defined a common location for the local repository, together with some tasks/properties to specify when to publish/resolve locally. You could apply this plugin in an init script to avoid munging with any of your actual build files. I think that should work…
PS Sorry I have no knowledge of Jira notifications. Is there something in your user profile to configure it?
WRT to Jira, no that is controlled by the “notification scheme” y’all use. By default Jira will notify all watchers (and maybe voters too, not sure by default) on any changes to the issue. I did not get notified when that issue (which I am watching) was resolved. So either thats a problem with y’alls notification scheme or you guys explictly disable notifications to watchers, etc (which would be very counter-intuitive for Jira users).
How would I go about reporting trouble with your Jira?