Fail to generate Pojos from yang files using Yangtools - opendaylight

I am trying to use OpenDaylight to generate Pojos from Yang files according to this guide.
I cloned Yangtools from OpenDaylight github and built the project with mvn clean install
i've added the following to my pom:
<plugin>
<groupId>org.opendaylight.yangtools</groupId>
<artifactId>yang-maven-plugin</artifactId>
<version>2.0.8-SNAPSHOT</version>
<executions>
<execution>
<goals>
<goal>generate-sources</goal>
</goals>
<configuration>
<!-- directory containing yang files to parse and generate code -->
<yangFilesRootDir>src/main/yang</yangFilesRootDir>
<codeGenerators>
<generator>
<codeGeneratorClass>
org.opendaylight.yangtools.maven.sal.api.gen.plugin.CodeGeneratorImpl
</codeGeneratorClass>
<!-- directory into which generated files will be placed -->
<outputBaseDir>
target/generated-sources
</outputBaseDir>
</generator>
</codeGenerators>
<!-- if true, plugin will search for yang files also in dependent projects -->
<inspectDependencies>true</inspectDependencies>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.opendaylight.yangtools</groupId>
<artifactId>maven-sal-api-gen-plugin</artifactId>
<version>0.7.4-Lithium-SR4</version>
<type>jar</type>
</dependency>
</dependencies>
</plugin>
however i am unable to generate the sources. I am getting the following error:
[ERROR] Failed to execute goal org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources (default) on project odl-poc: Execution default of goal org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources failed: An API incompatibility was encountered while executing org.opendaylight.yangtools:yang-maven-plugin:2.0.8-SNAPSHOT:generate-sources: java.lang.AbstractMethodError: Method org/opendaylight/yangtools/maven/sal/api/gen/plugin/CodeGeneratorImpl.generateSources(Lorg/opendaylight/yangtools/yang/model/api/SchemaContext;Ljava/io/File;Ljava/util/Set;Ljava/util/function/Function;)Ljava/util/Collection; is abstract
what am i doing wrong?

Looks like a version incompatibility - you're referencing yang-maven-plugin version 2.0.8-SNAPSHOT, which is the current unreleased master branch, and dependency maven-sal-api-gen-plugin version 0.7.4-Lithium-SR4, which was like 5 major releases ago and long obsolete.

Related

Groovy Maven Compilation fails with error: Unable to determine Groovy version. Is Groovy declared as a dependency?

I have a fairly vanilla groovy project that builds using maven. It utilises the gmavenplus plugin, with the pom lifted straight from the gmaven plus web page
pom looks something like this:
<project>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>1.8.0</version>
<executions>
<execution>
<goals>
<goal>addSources</goal>
<goal>addTestSources</goal>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<!-- any version of Groovy \>= 1.5.0 should work here -->
<version>2.5.8</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
When I build, I get the following error on the compile stage.
[INFO] --- gmavenplus-plugin:1.8:compile (default) # myapp---
[INFO] Unable to get Groovy version from GroovySystem, trying InvokerHelper.
[WARNING] Unable to get Groovy version from InvokerHelper or GroovySystem, trying jar name.
[ERROR] Unable to determine Groovy version. Is Groovy declared as a dependency?
And the final maven error results in this:
[ERROR] Failed to execute goal org.codehaus.gmavenplus:gmavenplus-plugin:1.8:compile (default) on project myapp: Execution default of goal org.codehaus.gmavenplus:gmavenplus-plugin:1.8:compile failed. NullPointerException -> [Help 1]
I have tried all manner of tricks, hacks and cajoling to get it to compile. I actually got it working in Intellij by adding the groovy runtime as a direct module dependency (rather than a maven managed dependency), but this doesn't work from the command line.
I had previously had a similar setup working on gmaven plus 1.6 and groovy 2.4.7 on the same laptop, no idea why this is broken now.
So I eventually got it working properly by deleting the entire codehaus dir in the .m2 repo. Re-downloading everything seemed to sort it out and now it all works correctly without any hacks.
This github issue is somewhat related - https://github.com/groovy/GMavenPlus/issues/84 - and the final comment led me to zapping the repo.

While creating a Maven project using archetype13, I have faced Sling IDE issues for core and test pom.xml

while creating a maven project using archetype13, I have faced Sling IDE issues as below for core and test pom.xml
This is the error that I get:
"Missing m2e incremental build support for generating the bundle manifest, component descriptions and metatype resources.
Please use the provided Quick Fixes on this issue to resolve this. pom.xml /AEMEditable.core line 1 Bundle Project Not Supporting M2E"
Note: Figured out how to solve this.
We need to manually modify the pom.xml for core and test, under maven-bundle plugin.
For both core and test pom.xml add the following code :
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<executions>
<!-- Configure extra execution of 'manifest' in process-classes phase
to make sure SCR metadata is generated before unit test runs -->
<execution>
<id>scr-metadata</id>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<supportIncrementalBuild>true</supportIncrementalBuild>
</configuration>
</execution>
</executions>
<configuration>
<instructions>
<!-- Import any version of javax.inject, to allow running on multiple versions of AEM -->
<Import-Package>javax.inject;version=0.0.0,*</Import-Package>
<Sling-Model-Packages>
AEMEditable.core
</Sling-Model-Packages>
<!-- Enable processing of OSGI DS component annotations -->
<_dsannotations>*</_dsannotations>
<!-- Enable processing of OSGI metatype annotations -->
<_metatypeannotations>*</_metatypeannotations>
</instructions>
<exportScr>true</exportScr>
</configuration>
</plugin>
Check image:
Once this is done, select the whole project in eclipse, right click, Click on Maven --> Update Project

Failed to execute goal (generate-scr-scrdescriptor) on project Unable to load compiled class

Have any one faced below error. why it causes.? am using the below version of plugins.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-scr-plugin</artifactId>
<version>1.20.0</version>
<executions>
<execution>
<id>generate-scr-scrdescriptor</id>
<goals>
<goal>scr</goal>
</goals>
<configuration>
<!-- Private service properties for all services. -->
<properties>
<service.vendor>Adobe</service.vendor>
</properties>
</configuration>
</execution>
</executions>
<configuration>
<outputDirectory>${project.build.directory}/classes</outputDirectory>
</configuration>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.5.11</version>
</dependency>
</dependencies>
</plugin>
[ERROR] Failed to execute goal
org.apache.felix:maven-scr-plugin:1.20.0:scr
(generate-scr-scrdescriptor) on project osgiexample.core:
E:\MY-Work\TESTProj\osgiexample\core\src\main\java\osgiexample\core\servlets\MyDataProviderServlet.java
: Unable to load compiled class:
osgiexample.core.servlets.MyDataProviderServlet -> [Help 1]
This means that the SCR plugin is unable to find a compiled class file corresponding to the file MyDataProviderServlet.java
I've only seen this happen in the following situations:
I had special characters in the path to my project, which caused the SCR plugin to fail to find the compiled classes.
I had a *.java file but its contents were temporarily commented out. The SCR plugin expected to find a compiled *.class file but there was nothing to compile (just comments). This caused an error message exactly like the one you saw.
Off the top of my head, I can't think of other cases where a class file would not be found by the SCR plugin without the Compiler plugin failing first.
I'd look for something unusual in the Java class itself. Does this happen for other classes with SCR annotations or just this one?
As a next step, I'd look at the file system. Could be a strange character or a file link confusing the plugin.
Finally, I'd inspect the rest of the Maven build. Perhaps you're using other plugins that might remove or otherwise mangle the class file prior to the SCR Plugin's execution?

Error when using groovy-eclipse-plugin and #Grab

Getting the following error when running mvn clean compile on a new system. It works fine on my local (windows) environment.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project visa-threatintel: Compilation failure: Compilation failure:
[ERROR] /path/to/Class.groovy:[2,2] 1. ERROR in /path/to/Class.groovy (at line 2)
[ERROR] #Grab(group="javax.mail", module="mail", version="1.5.0-b01", type="jar"),
[ERROR] ^^^
[ERROR] Groovy:Ambiguous method overloading for method org.apache.ivy.core.settings.IvySettings#load.
Both local and new system use Maven 3.2.5 and the POM is identical. Relevant excerpts below:
<groovy.version>2.2.1</groovy.version>
<ivy.version>2.4.0</ivy.version>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<extensions>true</extensions>
<configuration>
<!-- http://maven.apache.org/plugins/maven-compiler-plugin/ -->
<source>1.6</source>
<target>1.6</target>
<compilerId>groovy-eclipse-compiler</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.0-01</version>
</dependency>
<!-- 2.2.1 version isn't available as a release, so it needs to be acquired
from the codehaus nexus repository -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>${groovy.version}-01-SNAPSHOT</version>
</dependency>
<!-- to allow #Grab annotations -->
<dependency>
<groupId>org.apache.ivy</groupId>
<artifactId>ivy</artifactId>
<version>${ivy.version}</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>src/main/groovy</source>
</sources>
</configuration>
</execution>
I tried changing groovy version to 2.4.3 but got the same error. Anyone seen anything like this before?
Having just encountered a similar issue, I found that I had two issues:
Maven deps that failed a download
A maven dependency (maven-assembly-plugin) had failed a download.
Deleting the .lastUpdated files in your local m2 repository:
#> find ~/.m2/repository -name *.lastUpdated
~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.2-beta-5/maven-assembly-plugin-2.2-beta-5.pom.lastUpdated
#> find ~/.m2/repository -name *.lastUpdated -delete
grapeConfig.xml & repository ssl certificate
Also your ~/.groovy/grapeConfig.xml file needs to be configured to tell groovy where to pull the dependencies from - in my case it was from a corporate nexus repository, which also meant i had to install the https certificate in the JRE cacerts file.
How to test
One suggestion to test you have everything set up correctly would be to call grape install on a test dependency and that will give you a clearer sense of what is wrong (grape is distributed as part of the groovy binaries, so include it on your path, or fully qualify its path):
grape install javax.mail mail 1.5.0-b01

using QueryDSL in osgi

I have been trying to use querydsl in a project which is an osgi bundle.
my pom.xml has the following dependencies:
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-apt</artifactId>
<version>2.5.0</version>
</dependency>
<dependency>
<groupId>com.mysema.querydsl</groupId>
<artifactId>querydsl-jpa</artifactId>
<version>2.5.0</version>
</dependency>
As well as the plugin
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>maven-apt-plugin</artifactId>
<version>0.3.2</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>target/generated-sources/java</outputDirectory>
<processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.ops4j</groupId>
<artifactId>maven-pax-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<!-- | the following instructions build a simple set of public/private
classes into an OSGi bundle -->
<configuration>
<instructions>
<Import-Package>com.mysema.query.jpa,*</Import-Package>
<Export-Package>com.mypackage.package.*;version="${project.version}"</Export-Package>
</instructions>
</configuration>
</plugin>
Still when I try to start the bundle I get:
Error executing command: Unresolved constraint in bundle com.mypackage.package [163]: Unable to resolve 163.0: missing requirement [163.0] package; (&(package=com.mysema.query.jpa)(version>=2.5.0)(!(version>=3.0.0)))
I was using an older version of querydsl but apparently they fixed some stuff about osgi recently so I upgraded. The problem persists.
What I am missing for querydsl to work inside osgi?
Installing each dependency by hand will be a pain, but AFAIK there's nothing that will take a maven artifact and chain back of all dependencies - this would fail as where would it stop?
You could end up with every version of every logging framework (even if you had pax-logging installed), or the wrong implementation.
Alas in maven's case there's currently no way of applying semantic versioning or higher level requirement and capability. (Though BND (maven-bundle-plugin, bndtools) makes some sensible assumptions at a code level)
Karaf features (see the PDF manual in distribution's ${KARAF_HOME}) can do a lot to alleviate this but it can take some work to setup. There's a(t least) couple of ways to generate features files;
Use the features-maven-plugin
Use the maven-build-helper plugin to publish an XML file that you handcraft (laborious but you can maintain versions using resource filtering).

Resources