Good idea, isolated in a dedicated file will be easy to switch off. Regards JB
On 04/03/2018 06:32 PM, Romain Manni-Bucau wrote: > +1 > > also ensuring each optional task has a switch off flag will be important > (currently i cant use my computer while building with gradle which is a big > lost > of time in a day) > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > 2018-04-03 18:27 GMT+02:00 Jean-Baptiste Onofré <[email protected] > <mailto:[email protected]>>: > > Hi guys, > > "Europe located guys" started to work on test and changes on Gradle. > > I would like to propose a little change in the gradle structure. > > Today, lot of tasks and plugins definition are describe in an unique > file. It's > pretty hard to find quickly what we are looking for. > > What do you think to describe each "high level" tasks in a dedicated file > located in the gradle folder. > > To illustrate this, I created the following PR: > > https://github.com/apache/beam/pull/5004 > <https://github.com/apache/beam/pull/5004> > > It's about publishing the artifacts on Nexus repositories (snapshot or > staging). > The PR is not yet fully ready but you can see a publish.gradle dedicated > to this > in the gradle folder: > > > https://github.com/apache/beam/pull/5004/files#diff-2634489a13e9ba4c3db8f067716556a4 > > <https://github.com/apache/beam/pull/5004/files#diff-2634489a13e9ba4c3db8f067716556a4> > > We can imagine to have: > > - gradle/jacoco.gradle for code coverage > - gradle/rat.gradle for RAT > - gradle/dependencies.gradle for dependencies resolution > ... > > Thoughts ? > > Regards > JB > > On 03/29/2018 04:46 AM, Reuven Lax wrote: > > Hi all, > > > > Last week we discussed having a "fixit" day for Gradle, and I > volunteered to > > organize it. A number of people volunteered to help, from multiple > organization. > > I'd like to say that it's great to see such a diverse set of people > volunteering > > to help here - this is a great way to build community! Everyone who > explicitly > > volunteered is directly cced on this email, though we'd love for more > of the > > community to help. > > > > The agreed upon date is April 3. The top-level JIRA tracking this work > is > > > > ttps://issues.apache.org/jira/browse/BEAM-3249 > <http://issues.apache.org/jira/browse/BEAM-3249> > > <https://issues.apache.org/jira/browse/BEAM-3249 > <https://issues.apache.org/jira/browse/BEAM-3249>>, and we currently have > 26 > > subtasks linked to it. I've created a Kanban board to track these > issues, > which > > I'll share out soon. We will use Slack the day of the fixit for > collaboration > > and for questions. > > > > > > Two major goals for this fixit should be to 1. Remove Maven runs from > our > > Jenkins executors and 2. to migrate our release process fully over to > Gradle. A > > lot of work has already been done on 1., and we've made some progress > on 2.. > > Slightly longer-term the goal is to delete all of the pom files; I'm > not sure > > we'll get as far as completely deleting Maven in one day, but we should > get > > within striking distance! > > > > > > Thanks in advance to everyone who's helping out! > > > > > > Reuven > > > > -- > Jean-Baptiste Onofré > [email protected] <mailto:[email protected]> > http://blog.nanthrax.net > Talend - http://www.talend.com > > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
