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
<jacques.le.r...@les7arts.com> 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
<jacques.le.r...@les7arts.com> 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
