On Wed, Mar 10, 2010 at 6:41 PM, Hans Dockter <[email protected]> wrote:

>
>
> On Wed, Mar 10, 2010 at 5:07 PM, Andreas Netter <[email protected]> wrote:
>
>>
>> Hi Ross,
>>
>> it seems that the additional "_" is not only a problem in multi project
>> builds.
>> We have a similiar behaviour in a normal project build.
>>
>> The gradle version we use: gradle-0.9-20100121145940+1100
>>
>> During publish to our Ivy Repository, the [module] part of our ivy pattern
>> is replaced by "_".
>>
>> The module name is the project name as Adam Murdoch posted in another
>> thread.
>> The project name is a read-only property. It is the name of the directory
>> containing the build script.
>> To my understanding, there is no (miss-)configuration of module name /
>> project name possible, as it is set per convention.
>>
>> We've checked the project name during build. It is set correct. It seems
>> that it gets lost when publishing to Ivy.
>>
>
> First of all. The reason why we use the underscore as a replacement for the
> colon is that windows does not accept colons as part of file names.
>
> The single _ when publishing a root project is owed to the fact that we use
> project.path to determine the name for the ivy module. In the case of the
> root project this is :. This is obviously a bug.
>
> For subprojects the path is always : + project name. Therefore the _one
>
> Let's say we have the following project structure (in brackets possible
> strategies for module name)
>
> superapp (superapp)
> - superapp (superapp_superapp, superapp)
> - api (superapp_api, api)
> - services (superapp_services, services)
> -- web1 (superapp_services_web1, services_web1, web1)
>

There is one more aspect to that. Gradle uses ivy modules for handling
dependencies in a multi project build. Those module are published to an
in-memory repository. For that scenario uniqueness is very important. That
is the main reason for the current behavior. I need to think a bit more
about how to satisfy both use cases.

- Hans

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz

Reply via email to