Ok, so I just pushed a major update. On my machine with these changes both the java7 and java8 builds seem to be working. In the next few days I’ll probably play around with some of the excluded modules and see if we can include them in the java7 build. Right now, it sort of looks as if they were excluded simply because they didn’t immediately work. So I’ll go through them and try to find out which ones we can add and write down why some cant (This information seems to be missing at the moment)
Another thing I did, was to add the RAT plugin, go through the exclusions and clean up the exclusions. Some were excluding stuff that shouldn’t be excluded and it reported quite a hand full of files without ASF headers. I added them so please have a look if this was ok. The Eclipse support is also on my list (even if I have to admit that I always hate having to open that IDE ;-) ) Chris Am 13.06.17, 17:45 schrieb "Dale LaBossiere" <[email protected]>: > On Jun 12, 2017, at 4:56 PM, Christofer Dutz <[email protected]> wrote: > ... > In my opinion IDE settings shouldn’t be checked in and should rather be added to the gitignore list. Don’t know how often we had issues in Flex with checked in IDE settings :-( Agreed, with maven projects/pom’s in place, the Eclipse IDE settings/.project/.classpath would be removed from the repo. > > The warnings are related to the fact that all Apache Maven configurations have the “Apache root pom” as top-most parent. A lot Some things are configured there. However I’m using different versions of some plugins and re-defining them in the edgent-parent. That’s what the first block of warnings are about. Since the overrides are intentional, can you add the “annotations” to eliminate the warnings? (and maybe a comment as to why a different version is being selected?) https://stackoverflow.com/questions/30782453/maven-suppress-overriding-managed-version-warning-in-eclipse <https://stackoverflow.com/questions/30782453/maven-suppress-overriding-managed-version-warning-in-eclipse> > > The rest of the blocks are because in order to work correctly the e2m plugin has built-in configurations on what to do for which default maven plugin. This is how Eclipse knows when to copy resources, compile classes and eventually even generate code. However per default not all plugins are handled by the m2e plugin. That’s what the second block is about. There is a way to get rid of them and eventually even tell Eclipse what to do, but this would need some fine tuning. I would like to address that as soon as we’re finished. Otherwise I would probably have to re-configure that over and over again. Mabe it would be good to tell Eclipse to ignore the plugins it doesn’t know so the errors go away and then to fine tune them afterwards. Dealing with the warnings later seems OK. Can you make the change to eliminate the errors now? You probably know what needs to be done but fwiw here’s what Eclipse quick-fix added: @dales-mbp:1049> diff test/fvtiot/pom.xml{,.sav} 62,96d61 < <pluginManagement> < <plugins> < <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.--> < <plugin> < <groupId>org.eclipse.m2e</groupId> < <artifactId>lifecycle-mapping</artifactId> < <version>1.0.0</version> < <configuration> < <lifecycleMappingMetadata> < <pluginExecutions> < <pluginExecution> < <pluginExecutionFilter> < <groupId> < org.apache.maven.plugins < </groupId> < <artifactId> < maven-dependency-plugin < </artifactId> < <versionRange> < [3.0.1,) < </versionRange> < <goals> < <goal>copy</goal> < </goals> < </pluginExecutionFilter> < <action> < <ignore></ignore> < </action> < </pluginExecution> < </pluginExecutions> < </lifecycleMappingMetadata> < </configuration> < </plugin> < </plugins> < </pluginManagement> @dales-mbp:1050> Thanks, — Dale
