Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Jacques Le Roux]

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/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 resolved either:
1. The patch already submitted or
2. Enable all default dependencies types in the add-on modules which I think is 
the best approach because here we won’t be limiting a user to a feature subset 
of what gradle actually offers.

The Ofbiz platform by default can be restricted to compile and runtime 
dependencies but a plugin developer should not be limit to these two in my 
opinion.

Thanks,
--Valery


On 11/21/16, 00:21, "Jacques Le Roux"  wrote:

 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'll double check and revert if it's the case. I will though then

 change the framework/resources/templates/build.gradle file to suggest the 
possibility of compileOnly and introducde pluginLibsCompile in the main
 build.gradle . Before your Jira issue I was not aware of this and related 
options.
 
 Thanks
 
 Jacques
 
 
 Le 20/11/2016 à 23:53, Valery Ngah a écrit :

 > 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 detection tools. These annotations 
are only required during development, compile time and other defect detection 
tools.  I use IntelliJ for development and they do have an OOTB support for these 
annotations.
 >
 > This is just one example where I needed compileOnly dependency.
 >
 > If there is a better way to deal with this in Ofbiz am all ears.
 >
 >
 > --Valery
 >
 > On 11/20/16, 02:25, "Jacques Le Roux"  
wrote:
 >
 >  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 want also to check javax.servlet:servlet-api
 >
 >  Anyway before reverting we can wait a bit to see if Valery has done 
some work for OOTB libs (as I asked few days ago). Else I don't understand why he
 >  would want to push that instead of only using it in his own 
component/s.
 >
 >  Jacques
 >
 >
 >  Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
 >  > 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, Jacques Le Roux <
 >  > jacques.le.r...@les7arts.com> wrote:
 >  >
 >  >> 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 
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 declared in build.gradle for 
plugins only
 >  >>> when
 >  >>> a need arises, otherwise this is just code bloat. I would 
rather only add
 >  >>> things when we actually need them.
 >  >>>
 >  >>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
 >  >>>
 >  >>> Author: jleroux
 >  

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Jacques Le Roux]

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
   actually modify our build script to include by default all the dependency
types declared in here -> https://docs.gradle.org/

current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management.
I am suggesting that so that we have a root solution that covers all such
corner cases in the future.

That’s actually a better approach I will submit a patch for this later.

Thanks,


On 11/21/16, 00:29, "Taher Alkhateeb"  wrote:

 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 correct? If yes why not just declare as compile and then
 comment it out before shipping? Also from what I read about it and your
 description it seems to be actually testCompileOnly to be used in unit
 tests, wouldn't that be more appropriate for you? Does library just work
 during compile time and spit out errors? or does it run some tests?
 
 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/
 
current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management.
 I am suggesting that so that we have a root solution that covers all such
 corner cases in the future.
 
 
 On Nov 21, 2016 1:53 AM, "Valery Ngah"  wrote:
 
 > 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 detection tools. These annotations
 > are only required during development, compile time and other defect
 > detection tools.  I use IntelliJ for development and they do have an OOTB
 > support for these annotations.
 >
 > This is just one example where I needed compileOnly dependency.
 >
 > If there is a better way to deal with this in Ofbiz am all ears.
 >
 >
 > --Valery
 >
 > On 11/20/16, 02:25, "Jacques Le Roux" 
 > wrote:
 >
 > 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 want also to check javax.servlet:servlet-api
 >
 > Anyway before reverting we can wait a bit to see if Valery has done
 > some work for OOTB libs (as I asked few days ago). Else I don't 
understand
 > why he
 > would want to push that instead of only using it in his own
 > component/s.
 >
 > Jacques
 >
 >
 > Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
 > > 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, Jacques Le Roux <
 > > jacques.le.r...@les7arts.com> wrote:
 > >
 > >> 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 other
 > types of
 > >>> dependencies (compile, compileOnly, testCompile, testCompileOnly,
 > >>> compileClasspath, testRuntime, etc ...)
 > >>>
 > >>> I think the two most common uses are compile and runtime (both
   

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Valery Ngah]

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/
>
> current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management.
>I am suggesting that so that we have a root solution that covers all such
>corner cases in the future.

That’s actually a better approach I will submit a patch for this later.

Thanks,


On 11/21/16, 00:29, "Taher Alkhateeb"  wrote:

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 correct? If yes why not just declare as compile and then
comment it out before shipping? Also from what I read about it and your
description it seems to be actually testCompileOnly to be used in unit
tests, wouldn't that be more appropriate for you? Does library just work
during compile time and spit out errors? or does it run some tests?

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/

current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management.
I am suggesting that so that we have a root solution that covers all such
corner cases in the future.


On Nov 21, 2016 1:53 AM, "Valery Ngah"  wrote:

> 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 detection tools. These annotations
> are only required during development, compile time and other defect
> detection tools.  I use IntelliJ for development and they do have an OOTB
> support for these annotations.
>
> This is just one example where I needed compileOnly dependency.
>
> If there is a better way to deal with this in Ofbiz am all ears.
>
>
> --Valery
>
> On 11/20/16, 02:25, "Jacques Le Roux" 
> wrote:
>
> 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 want also to check javax.servlet:servlet-api
>
> Anyway before reverting we can wait a bit to see if Valery has done
> some work for OOTB libs (as I asked few days ago). Else I don't understand
> why he
> would want to push that instead of only using it in his own
> component/s.
>
> Jacques
>
>
> Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
> > 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, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> 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 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 declared in build.gradle for plugins
> only
> >>> when
> >>> a need arises, otherwise this is just code bloat. I would rather
> only add
> >>> things 

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Valery Ngah]

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 resolved either:
1. The patch already submitted or
2. Enable all default dependencies types in the add-on modules which I think is 
the best approach because here we won’t be limiting a user to a feature subset 
of what gradle actually offers. 

The Ofbiz platform by default can be restricted to compile and runtime 
dependencies but a plugin developer should not be limit to these two in my 
opinion.

Thanks,
--Valery


On 11/21/16, 00:21, "Jacques Le Roux"  wrote:

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'll double check and revert if it's the case. I will though then 
change the framework/resources/templates/build.gradle file to suggest the 
possibility of compileOnly and introducde pluginLibsCompile in the main 
build.gradle . Before your Jira issue I was not aware of this and related 
options.

Thanks

Jacques


Le 20/11/2016 à 23:53, Valery Ngah a écrit :
> 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 detection tools. These annotations are 
only required during development, compile time and other defect detection 
tools.  I use IntelliJ for development and they do have an OOTB support for 
these annotations.
>
> This is just one example where I needed compileOnly dependency.
>
> If there is a better way to deal with this in Ofbiz am all ears.
>
>
> --Valery
>
> On 11/20/16, 02:25, "Jacques Le Roux"  
wrote:
>
>  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 want also to check javax.servlet:servlet-api
>  
>  Anyway before reverting we can wait a bit to see if Valery has done 
some work for OOTB libs (as I asked few days ago). Else I don't understand why 
he
>  would want to push that instead of only using it in his own 
component/s.
>  
>  Jacques
>  
>  
>  Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
>  > 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, Jacques Le Roux <
>  > jacques.le.r...@les7arts.com> wrote:
>  >
>  >> 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 
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 declared in build.gradle for 
plugins only
>  >>> when
>  >>> a need arises, otherwise this is just code bloat. I would rather 
only add
>  >>> things when we actually need them.
>  >>>
>  >>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
>  >>>
>  >>> Author: jleroux
>   Date: Sun Nov 20 09:05:31 2016
>   New Revision: 1770539
>  
>   URL: http://svn.apache.org/viewvc?rev=1770539=rev
>   Log:
>   Implemented: Build framework 

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Taher Alkhateeb]

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 correct? If yes why not just declare as compile and then
comment it out before shipping? Also from what I read about it and your
description it seems to be actually testCompileOnly to be used in unit
tests, wouldn't that be more appropriate for you? Does library just work
during compile time and spit out errors? or does it run some tests?

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/
current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management.
I am suggesting that so that we have a root solution that covers all such
corner cases in the future.


On Nov 21, 2016 1:53 AM, "Valery Ngah"  wrote:

> 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 detection tools. These annotations
> are only required during development, compile time and other defect
> detection tools.  I use IntelliJ for development and they do have an OOTB
> support for these annotations.
>
> This is just one example where I needed compileOnly dependency.
>
> If there is a better way to deal with this in Ofbiz am all ears.
>
>
> --Valery
>
> On 11/20/16, 02:25, "Jacques Le Roux" 
> wrote:
>
> 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 want also to check javax.servlet:servlet-api
>
> Anyway before reverting we can wait a bit to see if Valery has done
> some work for OOTB libs (as I asked few days ago). Else I don't understand
> why he
> would want to push that instead of only using it in his own
> component/s.
>
> Jacques
>
>
> Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
> > 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, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> 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 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 declared in build.gradle for plugins
> only
> >>> when
> >>> a need arises, otherwise this is just code bloat. I would rather
> only add
> >>> things when we actually need them.
> >>>
> >>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
> >>>
> >>> Author: jleroux
>  Date: Sun Nov 20 09:05:31 2016
>  New Revision: 1770539
> 
>  URL: http://svn.apache.org/viewvc?rev=1770539=rev
>  Log:
>  Implemented: Build framework (Plugin mechanism) missing gradle
>  compileOnly
>  dependency feature
>  (OFBIZ-9118)
> 
>  The current build framework only supports compile and runtime
>  dependencies
>  but
>  doesn't allow you to declare compile only dependencies which is
> important
>  for
>  non-transitive dependencies used only at compilation time.
> 
>  Thanks: Valery Chenzo
> 
>  Modified:
>    ofbiz/trunk/build.gradle
> 
>  Modified: ofbiz/trunk/build.gradle
>  URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
>  1770539=1770538=1770539=diff
>  

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Jacques Le Roux]

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'll double check and revert if it's the case. I will though then 
change the framework/resources/templates/build.gradle file to suggest the possibility of compileOnly and introducde pluginLibsCompile in the main 
build.gradle . Before your Jira issue I was not aware of this and related options.


Thanks

Jacques


Le 20/11/2016 à 23:53, Valery Ngah a écrit :

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 detection tools. These annotations are only 
required during development, compile time and other defect detection tools.  I 
use IntelliJ for development and they do have an OOTB support for these 
annotations.

This is just one example where I needed compileOnly dependency.

If there is a better way to deal with this in Ofbiz am all ears.


--Valery

On 11/20/16, 02:25, "Jacques Le Roux"  wrote:

 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 want also to check javax.servlet:servlet-api
 
 Anyway before reverting we can wait a bit to see if Valery has done some work for OOTB libs (as I asked few days ago). Else I don't understand why he

 would want to push that instead of only using it in his own component/s.
 
 Jacques
 
 
 Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :

 > 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, Jacques Le Roux <
 > jacques.le.r...@les7arts.com> wrote:
 >
 >> 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 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 declared in build.gradle for plugins only
 >>> when
 >>> a need arises, otherwise this is just code bloat. I would rather only 
add
 >>> things when we actually need them.
 >>>
 >>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
 >>>
 >>> Author: jleroux
  Date: Sun Nov 20 09:05:31 2016
  New Revision: 1770539
 
  URL: http://svn.apache.org/viewvc?rev=1770539=rev
  Log:
  Implemented: Build framework (Plugin mechanism) missing gradle
  compileOnly
  dependency feature
  (OFBIZ-9118)
 
  The current build framework only supports compile and runtime
  dependencies
  but
  doesn't allow you to declare compile only dependencies which is 
important
  for
  non-transitive dependencies used only at compilation time.
 
  Thanks: Valery Chenzo
 
  Modified:
    ofbiz/trunk/build.gradle
 
  Modified: ofbiz/trunk/build.gradle
  URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
  1770539=1770538=1770539=diff
  
  ==
  --- ofbiz/trunk/build.gradle (original)
  +++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
  @@ -67,6 +67,8 @@ subprojects {
 pluginLibsCompile
 // runtime plugin libraries
 pluginLibsRuntime
  +//compile-only libraries
  +pluginLibsCompileOnly
 }
 }
 
  @@ -167,6 +169,7 @@ dependencies {
 subprojects.each { subProject ->
 

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Valery Ngah]

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 detection tools. These annotations are only 
required during development, compile time and other defect detection tools.  I 
use IntelliJ for development and they do have an OOTB support for these 
annotations. 

This is just one example where I needed compileOnly dependency. 

If there is a better way to deal with this in Ofbiz am all ears.


--Valery

On 11/20/16, 02:25, "Jacques Le Roux"  wrote:

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 want also to check javax.servlet:servlet-api

Anyway before reverting we can wait a bit to see if Valery has done some 
work for OOTB libs (as I asked few days ago). Else I don't understand why he 
would want to push that instead of only using it in his own component/s.

Jacques


Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :
> 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, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> 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 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 declared in build.gradle for plugins only
>>> when
>>> a need arises, otherwise this is just code bloat. I would rather only 
add
>>> things when we actually need them.
>>>
>>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
>>>
>>> Author: jleroux
 Date: Sun Nov 20 09:05:31 2016
 New Revision: 1770539

 URL: http://svn.apache.org/viewvc?rev=1770539=rev
 Log:
 Implemented: Build framework (Plugin mechanism) missing gradle
 compileOnly
 dependency feature
 (OFBIZ-9118)

 The current build framework only supports compile and runtime
 dependencies
 but
 doesn't allow you to declare compile only dependencies which is 
important
 for
 non-transitive dependencies used only at compilation time.

 Thanks: Valery Chenzo

 Modified:
   ofbiz/trunk/build.gradle

 Modified: ofbiz/trunk/build.gradle
 URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
 1770539=1770538=1770539=diff
 
 ==
 --- ofbiz/trunk/build.gradle (original)
 +++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
 @@ -67,6 +67,8 @@ subprojects {
pluginLibsCompile
// runtime plugin libraries
pluginLibsRuntime
 +//compile-only libraries
 +pluginLibsCompileOnly
}
}

 @@ -167,6 +169,7 @@ dependencies {
subprojects.each { subProject ->
compile project(path: subProject.path, configuration:
 'pluginLibsCompile')
runtime project(path: subProject.path, configuration:
 'pluginLibsRuntime')
 +compileOnly project(path: subProject.path, configuration:
 'pluginLibsCompileOnly')
}

// libs needed for junitreport

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Jacques Le Roux]

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 want also to check javax.servlet:servlet-api

Anyway before reverting we can wait a bit to see if Valery has done some work for OOTB libs (as I asked few days ago). Else I don't understand why he 
would want to push that instead of only using it in his own component/s.


Jacques


Le 20/11/2016 à 11:00, Taher Alkhateeb a écrit :

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, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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 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 declared in build.gradle for plugins only
when
a need arises, otherwise this is just code bloat. I would rather only add
things when we actually need them.

On Sun, Nov 20, 2016 at 12:05 PM,  wrote:

Author: jleroux

Date: Sun Nov 20 09:05:31 2016
New Revision: 1770539

URL: http://svn.apache.org/viewvc?rev=1770539=rev
Log:
Implemented: Build framework (Plugin mechanism) missing gradle
compileOnly
dependency feature
(OFBIZ-9118)

The current build framework only supports compile and runtime
dependencies
but
doesn't allow you to declare compile only dependencies which is important
for
non-transitive dependencies used only at compilation time.

Thanks: Valery Chenzo

Modified:
  ofbiz/trunk/build.gradle

Modified: ofbiz/trunk/build.gradle
URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
1770539=1770538=1770539=diff

==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
@@ -67,6 +67,8 @@ subprojects {
   pluginLibsCompile
   // runtime plugin libraries
   pluginLibsRuntime
+//compile-only libraries
+pluginLibsCompileOnly
   }
   }

@@ -167,6 +169,7 @@ dependencies {
   subprojects.each { subProject ->
   compile project(path: subProject.path, configuration:
'pluginLibsCompile')
   runtime project(path: subProject.path, configuration:
'pluginLibsRuntime')
+compileOnly project(path: subProject.path, configuration:
'pluginLibsCompileOnly')
   }

   // libs needed for junitreport

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Taher Alkhateeb]

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, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> 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 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 declared in build.gradle for plugins only
>> when
>> a need arises, otherwise this is just code bloat. I would rather only add
>> things when we actually need them.
>>
>> On Sun, Nov 20, 2016 at 12:05 PM,  wrote:
>>
>> Author: jleroux
>>> Date: Sun Nov 20 09:05:31 2016
>>> New Revision: 1770539
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1770539=rev
>>> Log:
>>> Implemented: Build framework (Plugin mechanism) missing gradle
>>> compileOnly
>>> dependency feature
>>> (OFBIZ-9118)
>>>
>>> The current build framework only supports compile and runtime
>>> dependencies
>>> but
>>> doesn't allow you to declare compile only dependencies which is important
>>> for
>>> non-transitive dependencies used only at compilation time.
>>>
>>> Thanks: Valery Chenzo
>>>
>>> Modified:
>>>  ofbiz/trunk/build.gradle
>>>
>>> Modified: ofbiz/trunk/build.gradle
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
>>> 1770539=1770538=1770539=diff
>>> 
>>> ==
>>> --- ofbiz/trunk/build.gradle (original)
>>> +++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
>>> @@ -67,6 +67,8 @@ subprojects {
>>>   pluginLibsCompile
>>>   // runtime plugin libraries
>>>   pluginLibsRuntime
>>> +//compile-only libraries
>>> +pluginLibsCompileOnly
>>>   }
>>>   }
>>>
>>> @@ -167,6 +169,7 @@ dependencies {
>>>   subprojects.each { subProject ->
>>>   compile project(path: subProject.path, configuration:
>>> 'pluginLibsCompile')
>>>   runtime project(path: subProject.path, configuration:
>>> 'pluginLibsRuntime')
>>> +compileOnly project(path: subProject.path, configuration:
>>> 'pluginLibsCompileOnly')
>>>   }
>>>
>>>   // libs needed for junitreport
>>>
>>>
>>>
>>>
>

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Jacques Le Roux]

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 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 declared in build.gradle for plugins only when
a need arises, otherwise this is just code bloat. I would rather only add
things when we actually need them.

On Sun, Nov 20, 2016 at 12:05 PM,  wrote:


Author: jleroux
Date: Sun Nov 20 09:05:31 2016
New Revision: 1770539

URL: http://svn.apache.org/viewvc?rev=1770539=rev
Log:
Implemented: Build framework (Plugin mechanism) missing gradle compileOnly
dependency feature
(OFBIZ-9118)

The current build framework only supports compile and runtime dependencies
but
doesn't allow you to declare compile only dependencies which is important
for
non-transitive dependencies used only at compilation time.

Thanks: Valery Chenzo

Modified:
 ofbiz/trunk/build.gradle

Modified: ofbiz/trunk/build.gradle
URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
1770539=1770538=1770539=diff

==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
@@ -67,6 +67,8 @@ subprojects {
  pluginLibsCompile
  // runtime plugin libraries
  pluginLibsRuntime
+//compile-only libraries
+pluginLibsCompileOnly
  }
  }

@@ -167,6 +169,7 @@ dependencies {
  subprojects.each { subProject ->
  compile project(path: subProject.path, configuration:
'pluginLibsCompile')
  runtime project(path: subProject.path, configuration:
'pluginLibsRuntime')
+compileOnly project(path: subProject.path, configuration:
'pluginLibsCompileOnly')
  }

  // libs needed for junitreport

Re: svn commit: r1770539 - /ofbiz/trunk/build.gradle

[Taher Alkhateeb]

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 declared in build.gradle for plugins only when
a need arises, otherwise this is just code bloat. I would rather only add
things when we actually need them.

On Sun, Nov 20, 2016 at 12:05 PM,  wrote:

> Author: jleroux
> Date: Sun Nov 20 09:05:31 2016
> New Revision: 1770539
>
> URL: http://svn.apache.org/viewvc?rev=1770539=rev
> Log:
> Implemented: Build framework (Plugin mechanism) missing gradle compileOnly
> dependency feature
> (OFBIZ-9118)
>
> The current build framework only supports compile and runtime dependencies
> but
> doesn't allow you to declare compile only dependencies which is important
> for
> non-transitive dependencies used only at compilation time.
>
> Thanks: Valery Chenzo
>
> Modified:
> ofbiz/trunk/build.gradle
>
> Modified: ofbiz/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=
> 1770539=1770538=1770539=diff
> 
> ==
> --- ofbiz/trunk/build.gradle (original)
> +++ ofbiz/trunk/build.gradle Sun Nov 20 09:05:31 2016
> @@ -67,6 +67,8 @@ subprojects {
>  pluginLibsCompile
>  // runtime plugin libraries
>  pluginLibsRuntime
> +//compile-only libraries
> +pluginLibsCompileOnly
>  }
>  }
>
> @@ -167,6 +169,7 @@ dependencies {
>  subprojects.each { subProject ->
>  compile project(path: subProject.path, configuration:
> 'pluginLibsCompile')
>  runtime project(path: subProject.path, configuration:
> 'pluginLibsRuntime')
> +compileOnly project(path: subProject.path, configuration:
> 'pluginLibsCompileOnly')
>  }
>
>  // libs needed for junitreport
>
>
>