Xavier,
Sorry about not going into further detail. I was going to make a separate
post detailing the issue. I can do it here.
The problem seems to focus around the "build" folder in the root of our
build directory. Essentially, if we delete the build folder and run
assemble, we get a "Cannot access class error". The class it cannot find
exists inside a jar in the libs directory of the OsmMaps project.
If we run assemble again, however, the application builds without error.
Just as a visual aid to our project structure
Root
build (<-- the root build folder)
Lib 1
Lib 2
App_SDK
OsmMaps
MyProblemProject
The following is my gradle file. As you may notice, the only custom logic
we have involves a 'provided' dependency and turning off manifest merging:
-----------------------Gradle file -----------------
apply plugin: 'android'
dependencies {
compile fileTree(dir: 'libs', include: '*.jar')
compile project(':OsmMaps')
compile project(':Lib1')
compile project(':Lib2')
provided project(':App_SDK')
}
android {
applicationVariants.all { variant ->
variant.javaCompile.classpath += configurations.provided
variant.processResources.manifestFile = file('AndroidManifest.xml')
variant.processManifest.enabled=false
}
compileSdkVersion 17
buildToolsVersion "19.1.0"
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
// Move the tests to tests/java, tests/res, etc...
instrumentTest.setRoot('tests')
// Move the build types to build-types/<type>
// For instance, build-types/debug/java,
build-types/debug/AndroidManifest.xml, ...
// This moves them out of them default location under
src/<type>/... which would
// conflict with src/ being used by the main source set.
// Adding new build types or product flavors should be accompanied
// by a similar customization.
debug.setRoot('build-types/debug')
release.setRoot('build-types/release')
}
}
On Wednesday, July 2, 2014 1:54:59 PM UTC-4, Xavier Ducrohet wrote:
>
> What's going on with your projects? Do you have custom logic in there?
>
> I'm interested in helping you figure out the need to call assemble twice.
>
>
> On Wed, Jul 2, 2014 at 10:40 AM, Justin Breitfeller <mrs...@gmail.com
> <javascript:>> wrote:
>
>> > From what I can tell, most of the really good teams are using Android
>>> Studio + Gradle or IntelliJ + Maven already.
>>>
>>
>> I think that is a bit early to say. I would say we are a "good" team, but
>> we haven't successfully been able to migrate over due to our builds simply
>> not working in gradle. In fact, I would guess that there are many
>> developers who have tried to switch to gradle but failed due to some issue.
>> For example, our team's app collection is what I would consider a "large"
>> project (+1,000,000 lines of code), and we have tried switching to gradle
>> on 3 ocassions. We are actually in the middle of a conversion attempt right
>> now but we may not be able to complete the conversion because gradle won't
>> build a few of our projects unless we run assemble on it twice. Why this
>> happens, I have no idea.
>>
>> I am confident the bugs will all be solved with the new build system, but
>> it still isn't ready for prime time. I think the Google developers are just
>> being responsible and waiting for gradle to be ready before wasting peoples
>> time if things don't work. Trust me when I say, I am eager to move away
>> from the bear that is Eclipse. We deal with crashes on an almost daily
>> basis.
>>
>> On Wednesday, July 2, 2014 12:16:24 PM UTC-4, Mark Murphy (a Commons Guy)
>> wrote:
>>>
>>> On Wed, Jul 2, 2014, at 11:18, Kevin Schultz wrote:
>>> > I have never met anyone that has used
>>> > IntelliJ extensively but still prefers Eclipse
>>>
>>> I do not know how you define "extensively", but I definitely have met
>>> people who do not like IntelliJ. There are developers who use NetBeans
>>> too, or no IDE at all.
>>>
>>> > #2) Those that think Android Studio + Gradle are not yet stable
>>> enough. I
>>> > think this is the bulk of those that haven't yet switched, and I think
>>> > this
>>> > is largely a result of the messaging from the tools team.
>>>
>>> #3) People who have limited English literacy. Android Studio knowledge
>>> is thin on the ground even in English, compared with Eclipse.
>>>
>>> #4) People who have limited Java experience (or, in many cases, limited
>>> programming experience). Again, there is a lot more written about
>>> Android development with Eclipse than there is with Android Studio.
>>>
>>> Etc.
>>>
>>> --
>>> Mark Murphy (a Commons Guy)
>>> http://commonsware.com | http://github.com/commonsguy
>>> http://commonsware.com/blog | http://twitter.com/commonsguy
>>>
>>> _The Busy Coder's Guide to Android Development_ Version 5.9: Now With
>>> More Gradle!
>>>
>> --
>> 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 adt-dev+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 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 adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
