gradle-versions-plugin OOTB?

[Jacques Le Roux]

Hi,

I was wondering: some projects use the trunk or I guess more often a release branch as source.

Should we not provide them a way to check the branch they use has the last libs versions using gradle-versions-plugin with a documented tasks, or
should this stay (a bit buried) in one of our Jiras?

I mean in a more global way, should we not document that for our users?

Jacques

[Jacques Le Roux]

Hi,

Nobody interested? So sounds like a lazy consensus.

Without any more comments I'll open a Jira and attach a patch

Jacques


Le 11/06/2018 à 14:02, Jacques Le Roux a écrit :

> Hi,
>
> I was wondering: some projects use the trunk or I guess more often a release branch as source.
>
> Should we not provide them a way to check the branch they use has the last libs versions using gradle-versions-plugin with a documented tasks, or
> should this stay (a bit buried) in one of our Jiras?
>
> I mean in a more global way, should we not document that for our users?
>
> Jacques
>
>

[taher]

I'm not sure I understand what you want to do exactly. Clarification would help

On Tue, Jun 26, 2018 at 11:27 AM, Jacques Le Roux
<[hidden email]> wrote:

> Hi,
>
> Nobody interested? So sounds like a lazy consensus.
>
> Without any more comments I'll open a Jira and attach a patch
>
> Jacques
>
>
>
> Le 11/06/2018 à 14:02, Jacques Le Roux a écrit :
>>
>> Hi,
>>
>> I was wondering: some projects use the trunk or I guess more often a
>> release branch as source.
>>
>> Should we not provide them a way to check the branch they use has the last
>> libs versions using gradle-versions-plugin with a documented tasks, or
>> should this stay (a bit buried) in one of our Jiras?
>>
>> I mean in a more global way, should we not document that for our users?
>>
>> Jacques
>>
>>
>

[Jacques Le Roux]

I thought my 1st message was clear enough. Let me try to phrase it better.

In order for our users to have an easier and secure life, I suggest to have this patch applied

Index: build.gradle
===================================================================
--- build.gradle    (révision 1834418)
+++ build.gradle    (copie de travail)
@@ -31,6 +31,7 @@
          classpath 'at.bxm.gradleplugins:gradle-svntools-plugin:latest.release'
          classpath 'org.asciidoctor:asciidoctor-gradle-plugin:1.5.7'
          classpath 'org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.16'
+        classpath 'com.github.ben-manes:gradle-versions-plugin:0.17.0'
      }
  }
  apply plugin: 'java'

And to create a Gradle task to use it. Actually just run

./gradlew dependencyUpdates -Drevision=release

And of course to document it in our main README

It would clarify how to keep libs updated to our users rather than having to look for this in Jira or by themselves.

What do you think (not only you Taher ;)) ?

Jacques


Le 26/06/2018 à 10:56, Taher Alkhateeb a écrit :

> I'm not sure I understand what you want to do exactly. Clarification would help
>
> On Tue, Jun 26, 2018 at 11:27 AM, Jacques Le Roux
> <[hidden email]> wrote:
>> Hi,
>>
>> Nobody interested? So sounds like a lazy consensus.
>>
>> Without any more comments I'll open a Jira and attach a patch
>>
>> Jacques
>>
>>
>>
>> Le 11/06/2018 à 14:02, Jacques Le Roux a écrit :
>>> Hi,
>>>
>>> I was wondering: some projects use the trunk or I guess more often a
>>> release branch as source.
>>>
>>> Should we not provide them a way to check the branch they use has the last
>>> libs versions using gradle-versions-plugin with a documented tasks, or
>>> should this stay (a bit buried) in one of our Jiras?
>>>
>>> I mean in a more global way, should we not document that for our users?
>>>
>>> Jacques
>>>
>>>

[taher]

Ok, so you have a plugin that essentially prints out a report of
dependencies and decides which ones are up to date. Here are my
thoughts

- First, your patch is not correct and does not add the task you
mentioned. It seems you didn't test it?
- Upon testing this plugin, I found packages that match, exceed
milestones, have later milestones (don't know the difference), and it
failed to determine for some packages. I'm not sure what is useful
about this information and how to apply it? I'm also not sure if this
information is accurate?
- Package updates is not something that can not be done easily and /
or automated. It has to be done with care.
- It seems like we are incurring the cost of pulling in more packages,
more dependencies and more build time for no apparent immediate value?
- The report does not distinguish between security updates and regular
minor updates, which again does not provide a lot of value.
- Finally, it seems that for a value to be derived from this plugin
[1] it should automate the report and add more conditions and whatnot.
Just putting it there doesn't do much on its own.

So perhaps more care and thought should be put into this, and better
analysis of value added should be done. And if anything, maybe we
should consider _reducing_ our libraries in the first place, instead
of adding more stuff into the pile.

[1] https://github.com/ben-manes/gradle-versions-plugin/blob/master/examples/build.gradle

On Tue, Jun 26, 2018 at 7:11 PM, Jacques Le Roux
<[hidden email]> wrote:

> I thought my 1st message was clear enough. Let me try to phrase it better.
>
> In order for our users to have an easier and secure life, I suggest to have
> this patch applied
>
> Index: build.gradle
> ===================================================================
> --- build.gradle    (révision 1834418)
> +++ build.gradle    (copie de travail)
> @@ -31,6 +31,7 @@
>          classpath
> 'at.bxm.gradleplugins:gradle-svntools-plugin:latest.release'
>          classpath 'org.asciidoctor:asciidoctor-gradle-plugin:1.5.7'
>          classpath 'org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.16'
> +        classpath 'com.github.ben-manes:gradle-versions-plugin:0.17.0'
>      }
>  }
>  apply plugin: 'java'
>
> And to create a Gradle task to use it. Actually just run
>
> ./gradlew dependencyUpdates -Drevision=release
>
> And of course to document it in our main README
>
> It would clarify how to keep libs updated to our users rather than having to
> look for this in Jira or by themselves.
>
> What do you think (not only you Taher ;)) ?
>
> Jacques
>
>
>
> Le 26/06/2018 à 10:56, Taher Alkhateeb a écrit :
>>
>> I'm not sure I understand what you want to do exactly. Clarification would
>> help
>>
>> On Tue, Jun 26, 2018 at 11:27 AM, Jacques Le Roux
>> <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Nobody interested? So sounds like a lazy consensus.
>>>
>>> Without any more comments I'll open a Jira and attach a patch
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 11/06/2018 à 14:02, Jacques Le Roux a écrit :
>>>>
>>>> Hi,
>>>>
>>>> I was wondering: some projects use the trunk or I guess more often a
>>>> release branch as source.
>>>>
>>>> Should we not provide them a way to check the branch they use has the
>>>> last
>>>> libs versions using gradle-versions-plugin with a documented tasks, or
>>>> should this stay (a bit buried) in one of our Jiras?
>>>>
>>>> I mean in a more global way, should we not document that for our users?
>>>>
>>>> Jacques
>>>>
>>>>
>

[Jacques Le Roux]

Thanks for your feedback Taher,

Rest inline...

Le 26/06/2018 à 18:49, Taher Alkhateeb a écrit :
> Ok, so you have a plugin that essentially prints out a report of
> dependencies and decides which ones are up to date. Here are my
> thoughts
>
> - First, your patch is not correct and does not add the task you
> mentioned. It seems you didn't test it?
Of course I tested it :) We already used it to update our libs.
Actually Michael was at the start of the initiative
     https://issues.apache.org/jira/browse/OFBIZ-9674
I then created an umbrella task
     https://issues.apache.org/jira/browse/OFBIZ-10213
But I never updated the libs myself, only Michael did so far.
More about that below.

"My patch" was just to show how it's an easy thing to add.
Thinking more about it, I think we don't need to add it to the build
A simple documentation in the main README should be enough.
A warning should be added, it's something to use with care.

> - Upon testing this plugin, I found packages that match, exceed
> milestones, have later milestones (don't know the difference), and it
> failed to determine for some packages. I'm not sure what is useful
> about this information and how to apply it? I'm also not sure if this
> information is accurate?
It's accurate

> - Package updates is not something that can not be done easily and /
> or automated. It has to be done with care.
I totally agree and we already suffered from 2 too quick updates with Tomcat 8.5 and itext:4.2.0

> - It seems like we are incurring the cost of pulling in more packages,
> more dependencies and more build time for no apparent immediate value?
Yes, I agree. A simple documentation as I suggested above should be enough

> - The report does not distinguish between security updates and regular
> minor updates, which again does not provide a lot of value.
Yes, for security updates I used to use OWASP Dependency Check before the introduction of Gradle.
Quoting myslef at https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check
<<Since OFBiz uses Gradle, all dependent libraries (ie also dependencies from the libraries OFBiz uses and recursively) are loaded by Gradle and
analysed by the OWASP Dependency Check plugin. So it's materially impossible to check all the possible vulnerabilities. >>

> - Finally, it seems that for a value to be derived from this plugin
> [1] it should automate the report and add more conditions and whatnot.
> Just putting it there doesn't do much on its own.
Yes, maybe, but that's another task different from simply documenting it with a warning that I now propose

> So perhaps more care and thought should be put into this, and better
> analysis of value added should be done. And if anything, maybe we
> should consider _reducing_ our libraries in the first place, instead
> of adding more stuff into the pile.
Yes, if that's possible +1

Jacques

>
> [1] https://github.com/ben-manes/gradle-versions-plugin/blob/master/examples/build.gradle
>
> On Tue, Jun 26, 2018 at 7:11 PM, Jacques Le Roux
> <[hidden email]> wrote:
>> I thought my 1st message was clear enough. Let me try to phrase it better.
>>
>> In order for our users to have an easier and secure life, I suggest to have
>> this patch applied
>>
>> Index: build.gradle
>> ===================================================================
>> --- build.gradle    (révision 1834418)
>> +++ build.gradle    (copie de travail)
>> @@ -31,6 +31,7 @@
>>           classpath
>> 'at.bxm.gradleplugins:gradle-svntools-plugin:latest.release'
>>           classpath 'org.asciidoctor:asciidoctor-gradle-plugin:1.5.7'
>>           classpath 'org.asciidoctor:asciidoctorj-pdf:1.5.0-alpha.16'
>> +        classpath 'com.github.ben-manes:gradle-versions-plugin:0.17.0'
>>       }
>>   }
>>   apply plugin: 'java'
>>
>> And to create a Gradle task to use it. Actually just run
>>
>> ./gradlew dependencyUpdates -Drevision=release
>>
>> And of course to document it in our main README
>>
>> It would clarify how to keep libs updated to our users rather than having to
>> look for this in Jira or by themselves.
>>
>> What do you think (not only you Taher ;)) ?
>>
>> Jacques
>>
>>
>>
>> Le 26/06/2018 à 10:56, Taher Alkhateeb a écrit :
>>> I'm not sure I understand what you want to do exactly. Clarification would
>>> help
>>>
>>> On Tue, Jun 26, 2018 at 11:27 AM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> Nobody interested? So sounds like a lazy consensus.
>>>>
>>>> Without any more comments I'll open a Jira and attach a patch
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 11/06/2018 à 14:02, Jacques Le Roux a écrit :
>>>>> Hi,
>>>>>
>>>>> I was wondering: some projects use the trunk or I guess more often a
>>>>> release branch as source.
>>>>>
>>>>> Should we not provide them a way to check the branch they use has the
>>>>> last
>>>>> libs versions using gradle-versions-plugin with a documented tasks, or
>>>>> should this stay (a bit buried) in one of our Jiras?
>>>>>
>>>>> I mean in a more global way, should we not document that for our users?
>>>>>
>>>>> Jacques
>>>>>
>>>>>