On 29/07/2011, at 12:46 PM, Hani Suleiman wrote:
> 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.
The idea plugin can handle both of those things (assuming by 'exclusions' you
mean excluded folders). You do have to do a little bit of configuration in the
build script to make this work.
Something you can do as a workaround, is add a task to copy the project's
dependencies into a directory somewhere under the project directory, and point
your ide at that directory (or individual files in that directory):
task ideLibs(type: Sync) {
from configurations.testRuntime
into 'ide/libs'
}
You could even take this approach and extend the idea plugin to first copy the
dependencies to the project directory. Given that the idea plugin automatically
converts files under the project directory to $MODULE_DIR$ references, you
would be able to check the generated files in. So, you'd do something like this:
1. change the dependencies in the build.gradle
2. run 'gradle idea'
3. check the project files in
after an update, each dev would
1. update from source control
2. run 'gradle idea'
> 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.
Absolutely. I think there's plenty of goodness we get from moving/duplicating
the cache in $projectDir, including better support for those who manually
manage dependencies, or have an unsupported IDE. It also means we can use
relative paths in the generated IDE project files, which makes it possible to
check those files in. It will help us with some of the c/c++ stuff we're doing
now, too.
So, we might tackle that before the .idea dir support.
>
> 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
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
