Thanks Valery,
I must say I did not try with a new plugin and this point was not obvious to me
Thanks for your contribution!
Jacques
Le 21/11/2016 à 23:20, Valery Ngah a écrit :
Hi Jacques,
compileOnly is used only in the add-on modules but because of the way the
plugin framework is setup/
Hi Valery, Taher,
I agree with Taher's proposition to complete with all options.
Jacques
Le 21/11/2016 à 23:29, Valery Ngah a écrit :
Hi Taher,
If you want to always use the library for your development by declaring
compileOnly or testCompileOnly then my alternative suggestion is to
Hi Taher,
>If you want to always use the library for your development by declaring
>compileOnly or testCompileOnly then my alternative suggestion is to
> actually modify our build script to include by default all the dependency
>types declared in here -> https://docs.gradle.org/
>
Hi Jacques,
compileOnly is used only in the add-on modules but because of the way the
plugin framework is setup/designed you can’t directly use the “compileOnly”
feature in the build.gradle file of the module. It evaluates to an error if its
being used directly.
Two ways I see how this can be
Hi Valery,
Thank you for your feedback which is highly appreciated. I have to say that
I'm quite happy to get feedback on the plugin system which is exactly what
we need to continue to improve it.
So if I may ask, my understanding is that you want to use this library only
during development corre
Hi Valery,
We don't need to have compileOnly in the main build.gradle file if it's only used in "add-on modules" (we call them plugins). You can use the local
build.gradle (in the plugin, aka component) for that.
I'm not quite sure yet but it seems we have no need of compileOnly OOTB (yet). I'
Hi Jacques, hi Taher,
It’s true that compile and runtime are the most used types of dependencies but
that doesn’t mean that add-on modules won’t require compileOnly dependencies.
Take for example com.google.code.findbugs:jsr305 (JSR 305) which provides a set
of annotations to assist defect dete
Yes it might be the case indeed.
I looked for possible compileOnly libs before committing. I must say I did not
find anyone clearly.
I thought about the Junit ones, but that would be testCompileOnly (needed I guess) and I found some use case in no test code but we can maybe change
that.
I wa
I don't think we currently have any compileOnly libs, and I would think we
would rarely ever need those.
So, I recommend removing them, but I also recommend not to introduce
anything unless it is "used" or "will very likely be used soon" (the YAGNI
principle)
On Sun, Nov 20, 2016 at 12:52 PM, Jac
Hi Taher,
I was wondering if this could not be helpful to OOTB minimise the dependencies.
I must say I have still to check which libs is compile only, any ideas?
Jacques
Le 20/11/2016 à 10:28, Taher Alkhateeb a écrit :
Hi Jacques,
I'm not sure this is a very good idea. Gradle supports many
Hi Jacques,
I'm not sure this is a very good idea. Gradle supports many other types of
dependencies (compile, compileOnly, testCompile, testCompileOnly,
compileClasspath, testRuntime, etc ...)
I think the two most common uses are compile and runtime (both needed and
used). Other kinds should be d
11 matches
Mail list logo
