Pretty much any of the solutions below would address the issue!
In my case, I'm doing it manually until the .idea directory support is in. Even
when that's done, there are still configuration elements that the idea plugin
doesn't really handle (for example, the 'provided' dependencies), exclusions,
etc. As things stand I basically have to stick to M3 and wait for the next
release which will hopefully address this (or find the time to write a patch
for .idea support for M4).
I know IDEA 11 will supposedly treat gradle builds as first class citizens and
automatically sync dependencies etc, but that's many months in the future (a
final release that I can force onto ~50 or so devs without feeling bad!), so a
sensible interim solution is definitely required.
Another thing worth considering is people who don't use IDEA/Eclipse, what
about netbeans users? I think saying 'you can't use the local repo unless we
support your IDE' is a needless impediment, when all you need to do is ensure
that the cache dir format is stable and easy to work with.
On Jul 28, 2011, at 8:01 PM, Adam Murdoch wrote:
> At the moment, we consider the layout of the artifact cache to be an internal
> interface, and it may change at any time. We discourage people from referring
> directly to the cache contents. However, there are certainly use cases for
> getting hold of the cached artifacts, so we want to have solutions for those
> use cases.
>
> I'm curious why you want to maintain your dependencies manually? There might
> be something we can change with the IDE plugins to solve the problem and so
> let Gradle take care of the dependencies for you.
>
> For example, perhaps adding support of the .idea directory format would solve
> your problem. Or the upcoming Idea integration, which will let you import a
> Gradle build as an Idea project.
>
> Another option might be to offer some capability to keep a replica of the
> cache in a friendlier format. For example, perhaps when Gradle resolves a
> configuration, it also creates a copy of the dependencies in
> $projectDir/.gradle/dependencies/$configName (perhaps using symlinks into the
> cache, or perhaps as copies). Then, you can just point the IDE at
> $projectDir/.gradle/dependencies/testRuntime (say).
>
> Or, building on this: the artifacts under $userDir/caches/artifacts are all
> just links into $userDir/caches/artifacts/filestore. We could perhaps get rid
> of these artifact links under $userDir, and just use the above links under
> $projectDir instead. This way, the artifacts are arranged according to
> purpose, rather than origin, and this removes the need for the repo id, and
> make the artifacts much easier to find from other tools, not just those that
> Gradle is aware of.
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
