Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inside Gradle build causes android.jar download from MavenCentral/JCenter #73

Closed
paulvi opened this issue Jul 31, 2014 · 9 comments
Closed
Labels

Comments

@paulvi
Copy link

paulvi commented Jul 31, 2014

I have tried inside Gradle build with

compile group: 'com.github.tony19', name: 'logback-android-core', version: '1.1.1-3'
compile group: 'com.github.tony19', name: 'logback-android-classic', version: '1.1.1-3'
compile group: 'org.slf4j', name: 'slf4j-api', version: '1.7.6'

and got

err-gradle-logback

@tony19 tony19 closed this as completed Aug 2, 2014
@paulvi
Copy link
Author

paulvi commented Aug 4, 2014

I used Android Studio 0.8.2 and created new project with mobile and wear subprojects.

then added section to dependencies of mobile subproject

compile group: 'com.github.tony19', name: 'logback-android-core', version: '1.1.1-3'
compile group: 'com.github.tony19', name: 'logback-android-classic', version: '1.1.1-3'
compile group: 'org.slf4j', name: 'slf4j-api', version: '1.7.6'

I think it is not correct for gradle build to pull android.jar (as for maven build) and not use Android SDK (as configured in Manifest.xml or overrriden in gradle defaultConfig section, e.g.

defaultConfig { //gradle can override values in AndroidManifest.xml
    //minSdkVersion 15
    //targetSdkVersion 19
    //versionCode 1
    //versionName "1.0"
    //applicationId  // (was packageName )
    //applicationIdSuffix
}

@tony19
Copy link
Owner

tony19 commented Aug 5, 2014

Ok, I think you're probably right. I'll take another look.

@tony19 tony19 reopened this Aug 5, 2014
@iangregsondev
Copy link

I can confirm that this is still happening.

@tony19
Copy link
Owner

tony19 commented Jan 11, 2015

As a workaround, please try the following exclusion rule:

compile('com.github.tony19:logback-android-classic:1.1.1-3') {
    exclude group: 'com.google.android', module: 'android'
}

@iangregsondev
Copy link

Thanks @tony19 . Works great.

@gsprdev
Copy link

gsprdev commented Nov 2, 2017

When using the new 3.0.0 build system, this issue has now become a blocker.
When building Release (not Debug) builds, the build fails with this error (provided in full for search engines so people find this):

Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.

The workaround described here and your README.md solves the issue just the same. The impact is simply greater now.

ashimokawa added a commit to Freeyourgadget/Gadgetbridge that referenced this issue Nov 14, 2017
@hardikpansuria
Copy link

I have upgraded android Gradle plugin 3.0.0 then after getting same error

Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.

NOTE : getting error Only in Release not in Debug !!

@tony19
Copy link
Owner

tony19 commented Mar 6, 2018

Fixed in v_1.1.1-7

@tony19 tony19 closed this as completed Mar 6, 2018
@lock
Copy link

lock bot commented Feb 27, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the archived label Feb 27, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Feb 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants