Hi, sorry for the late response, for some reason I didn't get the
notification.
-SNAPSHOT versions are meant for big teams to share their partial work
before its done so that other developers can start to develop against it in
their project without waiting for the actual release.
This is efficient in various ways: it gives an early feedback on your
development and reduce the time you block other teams before letting them
use your code.
>From maven what I DO NOT like of these mechanism is that your development
commits are not reproducible but that's another story.
If you are developing a multi-module project where some of your modules
should be shared among your teams you need to deploy -SNAPSHOTS while
developing.
compile project(':project:path') force you to have the actual sources in
your project folder (git submodules or full copy)
if you upgrade Android Studio you need to also upgrade the Android gradle
plugin and gradle version on ALL projects, even projects you want just to
include
these two things means that you are forced to put your module in a separate
repository and include it with git submodule and you have to keep all the
project using it with the same version of gradle/android gradle plugin and
all your team using the same version of Android Studio.
This could be solved by having a way to install artifacts locally, the
maven install command does exactly that.
I'm looking for a gradle install command and a way for gradle to
automatically refresh artifacts with -SNAPSHOT that have been locally
installed.
Then when your -SNAPSHOT development can be shared with the team you can
just issue an uploadArchives command to share your work with your team.
I'm currently handling these situations with git submodules or manually
issuing uploadArchives and adding --refresh-dependencies parameters in the
next compile.
I hope I gave you an idea of why I found that feature useful in maven.
Regards,
Daniele
On Tuesday, February 11, 2014 7:33:52 PM UTC+1, Xavier Ducrohet wrote:
>
> What's the problem with using compile project(':project:path')?
>
> When it's time to publish Gradle will resolve the inter-project
> dependencies into proper Maven dependencies (at least for projects that
> define the group, version, archivesBaseName, and apply the maven plugin)
>
>
> On Tue, Feb 11, 2014 at 8:42 AM, Daniele Segato
> <[email protected]<javascript:>
> > wrote:
>
>> Hi,
>>
>> I've (little) experience with maven and I know you can develop a maven
>> project using different modules that depends each others.
>>
>> Dependencies are defined using the standard dependency mechanism like if
>> they are published on a maven repository but you can still use them locally
>> without pushing.
>>
>> This very handy because it allow you to mix together different separate
>> libraries that will be released as artifact but you can still refactor them
>> and immediately see the effect of a modification on your code.
>>
>> I couldn't find a way to do this with gradle.
>>
>>
>> I either define the dependency locally:
>>
>> compile project(':project:path')
>>
>> which use the local sources
>>
>> or I define the remote dependency
>>
>> compile 'my:project:0.1.0-SNAPSHOT'
>>
>> which try to download the snapshot from a maven repository.
>>
>>
>> Trying with the second way cause these issues:
>>
>> - you have to uploadArchives every time you modify something to see the
>> effect in the other projects that depends on this
>> - you have to force a dependency update with --refresh-depencencies
>> option to gradle
>>
>>
>> is there something like the maven "install" command that deploy the
>> artifact in the local maven repository?
>> Can I leave the artifact-style dependency in my modules and still develop
>> them locally seamlessly?
>>
>>
>> As a plus some of my libraries has its own git repository which makes
>> things more complex, if possible, but that could be solved by creating a
>> "super repo" that combines them with git submodules.
>>
>>
>> Any suggestion?
>> Do anyone understood what I'm talking about?
>>
>> thank you and regards,
>> Daniele
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "adt-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Xavier Ducrohet
> Android SDK Tech Lead
> Google Inc.
> http://developer.android.com | http://tools.android.com
>
> Please do not send me questions directly. Thanks!
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
