I would rather not turn off "all compiler warnings are errors" in a module unless we absolutely have to, since I think compiler warnings give us useful information.
I wanted to talk about a structure that might work for what Dan is suggesting and anticipate some questions that Dipti might have for the beam community. Assumptions I'm working under: (I haven't worked with enforcer before, so please correct me if I'm wrong) * java enforcer runs on all the code currently being used (ie, compile/test-compile goals would produce different sets of classes to be examined, and if the phrase being requested by the user is "verify" then it'll look at both) - the enforcer plugin's * java enforcer can be turned off on a per module level (by changing the settings for the enforcer in that module's pom ) * java enforcer can be turned on or off for a given module via a profile (by putting the settings change for enforcer in the profile in that module) 1. One naive approach would be to have the enforcer off by default and only enable the enforcer rule in the HIFIO module when a particular profile (jdk-version-enforcer?) is enabled. We would then only run that profile when specifying only the compile goal on the command line. This would imply that the community would need to add to the (travis or jenkins?) test runs a configuration that runs that separate profile. Are we okay with adding another test run like that/is that a pattern we like others to follow? This would mean that if there's an enforcer break in the HIFIO module, we likely wouldn't catch it until those test runs, since it's unlikely most developers will run the tests on their own. 2. Move HIFIO's cassandra tests into a separate child module of the HIFIO which has enforcer set to JDK1.8 3. Configure enforcer in the HIFIO module to just use JDK1.8 My assumption is that if #2 (module based) would work, that the beam community would prefer it over #1 (profile based) since it's fewer test runs and less surprising, and prefer it over #3 (HIFIO is only 1.8) since we don't want HIFIO to be 1.7 only (it wouldn't be restricted and should work fine, but could break without us knowing.) It seems to me like we it would be preferable to change enforcer's rules in the cassandra module instead of disabling all compiler warnings (again, this is on the assumption that that is possible.) S On Mon, Feb 27, 2017 at 9:18 PM, Dipti Kulkarni < [email protected]> wrote: > Sure , I am going to investigate this. Will update the thread shortly. > > -----Original Message----- > From: Dan Halperin [mailto:[email protected]] > Sent: Monday, February 27, 2017 11:32 PM > To: [email protected] > Subject: Re: Enforcer Rule- JDK1.7 for Beam > > I think there are a few separable questions: > > 1. Can the module itself be used with Java7 only, and can we enforce this? > 2. When testing, can we use Java 8 dependencies and how? > > I think that the automated enforcements are useful to ensure property #1, > assuming we want the module to work in Java7. Not enforcing it means we're > at risk of losing it. So I'm not a fan of simply disabling these checks. > > However, it should be possible to use java8 code as well. Maybe it goes in > a profile? Maybe it goes into a separate module, maybe just a separate > profile? > > Can you investigate? > > On Mon, Feb 27, 2017 at 9:23 AM, Jean-Baptiste Onofré <[email protected]> > wrote: > > > Hi Dipti, > > > > I had the same "issue" on CassandraIO. > > > > If you take a look on: > > > > https://github.com/apache/beam/pull/592/files > > > > you will see that I use <compiler.error.flag></compiler.error.flag> to > > remove the default -Werror causing issue with Java8 dependencies. > > > > Regards > > JB > > > > > > On 02/27/2017 06:16 PM, Dipti Kulkarni wrote: > > > >> Hi all, > >> > >> While working on HadoopInputFormatIO, when I rebased my code to fetch > >> the latest from Beam repo, I see an Enforcer rule added to the parent > >> POM to ensure that all dependencies used are compliant with JDK 1.7 I > >> have written tests for Cassandra and Elasticsearch to test if HIFIO > >> works ok to read data from these sources using their respective > >> inputformat classes, for these tests, I am using the latest version > >> of ES, and Cassandra which need dependencies working on JDK 1.8. > >> These dependencies are marked as test scope, .and my builds continue > >> to fail due to the Banned Dependency error. Is it mandatory for the > >> tests also to comply with the enforcer rule of JDK 1.7? Or is there > >> any way we can override the JDK compliance for Tests? Thoughts? > >> > >> -Dipti > >> > >> > >> DISCLAIMER > >> ========== > >> This e-mail may contain privileged and confidential information which > >> is the property of Persistent Systems Ltd. It is intended only for > >> the use of the individual or entity to which it is addressed. If you > >> are not the intended recipient, you are not authorized to read, > >> retain, copy, print, distribute or use this message. If you have > >> received this communication in error, please notify the sender and > delete all copies of this message. > >> Persistent Systems Ltd. does not accept any liability for virus > >> infected mails. > >> > >> > >> > > -- > > Jean-Baptiste Onofré > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is > the property of Persistent Systems Ltd. It is intended only for the use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Persistent Systems Ltd. does not accept any liability for virus infected > mails. > >
