https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-266 controller <p>Currently due to a bug in Eclipse, code generation is handled intermittently in ways that can make development challenging. We need to find a workaround for this Eclipse bug.</p> <p>Operating System: Linux<br/> Platform: All</p> CONTROLLER-266

Fix handling of code generation in Eclipse

Bug Resolved Done Unassigned Ed Warnicke Wed, 2 Apr 2014 12:45:20 +0000 Tue, 25 Jul 2023 08:23:23 +0000 Mon, 14 Apr 2014 15:33:33 +0000 mdsal 0 4 <p>The build-helper-maven-plugin allows eclipse to see the generated source folders. The projects that are red are basically missing the build-helper-maven-plugin in the pom. However, if you do Project-&gt;Clean you lose the generated source. It would be ideal if eclipse could run the yang-maven-plugin during the generate-sources phase as the CLI does. I tried "un-ignoring" the yang-maven-plugin but that resulted in errors (went red in Maven-&gt;Lifecycle Mapping). I think a yang m2e connector plugin for eclipse would have to be developed for this to work (similar to the ones for build-helper, jaxb and other maven plugins). </p> <p>The common pom defines a profile that tells eclipse to use the target-ide directory. I'm new to ODL so I assume this was done to keep eclipse output separate from CLI so they don't affect one another. This is OK although devs have to know to first run 'mvn -P IDE ...' if they want to use eclipse (I didn't see it doc'ed on the wiki). However, after cloning the latest source last nite, the IDE profile yields compile errors in some netty projects - it works fine otherwise so it appears changes were made that assume generated source is under target. Since at least some devs have gone away from eclipse or don't use any IDE, I think the use of target-ide for eclipse will be problematic going forward - I'd like to remove it.</p> <p>I've used eclipse for years and prefer it over IntelliJ. IntelliJ has better support for generated source - eclipse is better at other things. Both have pros and cons. In the end, I think it's personal preference and we shouldn't preclude the use of one over the other. My 2 cents...</p> <p>Another option re: generated source is to just check it in under src/main/java.</p> <p>Devin, Greg and I got our build errors down to 0 in eclipse. Some projects were simply missing the build-helper-maven-plugin. Others, mostly in the md-sal projects, incorrectly overrode the build-helper-maven-plugin execution definition from the parent pom so we removed the overridden execution definition. </p> <p>For Xtend, we had to add the 2.4.3 version of the xtend plugin. One xtend source file used a generic type syntax that resulted in the eclipse compiler yielding an error while javac compiled fine. This is a result of the slight differences between EJC and javac.</p> <p>The other change we made is to remove the maven IDE profile so that eclipse and CLI mvn share the target dir. This was motivated by recent changes that caused compile errors when building with the IDE profile. The changes were most likely introduced by someone who doesn't use eclipse. Removing the profile will avoid such issues for those who do use eclipse.</p> <p>The IDE profile was introduced by <a href="https://git.opendaylight.org/gerrit/#/c/2679/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/2679/</a> to avoid "half-baked" class files generated by eclipse from affecting CLI mvn. This can occur if one tries to build from CLI when there are compile errors in eclipse (EJC generates the class file even if there are errors). In my experience, this scenario is (should be) uncommon and can be avoided if one does 'mvn clean install' after working in eclipse.</p> <p>Implemented a solution which is under review in gerrit</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/5914/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/5914/</a></p> Development External issue ID 651 External issue URL Rank 0|i02jc7: