http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-2.3.7/doc/site/wrap-mojo.html says bundle:wrap is deprecated, same with bundle:bundleall. I currently use wrap to create an OSGi bundle from a non-OSGi dependency, as described at http://www.lucamasini.net/Home/osgi-with-felix/creating-osgi-bundles-of-your-maven-dependencies. What should they be replaced by and what's the reason for the deprecation?
The alternative is to just use the bundle:bundle goal, then in your pom.xml configure the plugin similar to the following:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<configuration>
<instructions>
<Embed-Dependency>*;scope=compile;inline=true</Embed-Dependency>
<_exportcontents>*</_exportcontents>
</instructions>
</configuration>
</plugin>
You can control what dependencies get embeded and exported by changing the wildcards "*", scope, etc. attributes.
I've wondered the same question, found some clue here:
http://www.mail-archive.com/dev#felix.apache.org/msg22221.html
"Instead new features/goals will be added to solve common use-cases such as
creating mega-bundles, etc."
I guess they're going to rework the current goals because the current codebase doesn't support all that they want to implement in the plugin.
Related
Since last few days a lot of doubts got cleared because of the you all experts. I have one more question, when i see my pom.xml in my project , I see a lot of plugins with quite a few configuration. for e.g
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M4</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit-platform</artifactId>
<version>3.0.0-M4</version>
</dependency>
</dependencies>
<configuration>
<forkCount>1</forkCount>
<reuseForks>true</reuseForks>
<argLine>${argLine} -Xmx4g -XX:MaxPermSize=1g</argLine>
<includes>
<include>**/*Test.java</include>
<include>**/*Spec.java</include>
</includes>
</configuration>
</plugin>
My question is how they decided the these forkcount , argLine needed to be used here? plus the dependency also. When i checked the bealdung doc for same plugin the config was very simple. is it necessary to read docs for a perticular plugin before using it. like how people take decisions for the same that what are the tags to be used or what are the mandatory tags. any links will be helpful.
Thanks
I strongly recommend reading the docs of the appropriate plugin which would show like in your example defining the provider (the dependency) https://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html is usually not needed nor helpful/useful. For the other settings it depends on what kind of tests you are running but from my point of view I would strongly review my tests because needed to set 4 GiB for heapspace sounds weird .... especially for a tests? The others parts depends on the testing framework you are using.. and your use case. I usually start without any configuration for my builds ...only If i really need to change something I do so which is rarely the case. (Convention over configuration)... and read the docs: https://maven.apache.org/surefire/maven-surefire-plugin/plugin-info.html
I only want to document two classes from a package. In standard javadoc tool, it would be something like:
C:> javadoc -d C:\home\html C:\home\src\java\awt\classA.java C:\home\src\java\awt\classB.java
How can I do it in maven-javadoc-plugin?
sourceFileIncludes should do what you're looking for.
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#sourceFileIncludes
Here's an example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<sourceFileIncludes>
<include>com/mycompany/myproject/MyClass.java</include>
</sourceFileIncludes>
</configuration>
</plugin>
UPDATE:
I tried this out on one of my maven projects and it worked at the package level, but not on individual classes. It looks like these open Maven issues are the cause:
http://jira.codehaus.org/browse/MJAVADOC-388
http://jira.codehaus.org/browse/MJAVADOC-365
Note that issue #365 is actually related to sourceFileExcludes; the fix for that is scheduled for maven-javadoc-plugin 2.11.
Question
How to make a maven build fail if source code contains a keyword / regex?
Bonus
Be able to specify which path to check
Be able to specify which "kind" of path to check :
"I want to be sure that KEYWORD is not contained in 'main' resources. I don't care about 'test'"
"I want to be sure that KEYWORD is not contained in 'test' resources. I don't care about 'main'"
...
Be able to specify on which phase to execute the test (Eg. before compilation)
Solution
(Based on current answers 2013-09-26)
Best solution yet seems to be #BaptisteMathus answer that fully integrates with maven and is platform independant.
In my use case, #GregWhitaker answer is the good one because it's cheaper to implement as I don't care about platform independency (<= the required command is availiable on all my hosts).
The code sample below is a solution based on this answer, it forbids usage of "FIXME" or "Auto-generated method stub" but is assuming that egrep is availiable.
Please see also #MarkOConnor answer that is cleaner in "SONAR enabled" project
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<phase>process-sources</phase>
<configuration>
<executable>egrep</executable>
<successCodes>
<successCode>1</successCode>
</successCodes>
<arguments>
<argument>-rqm</argument>
<argument>1</argument>
<!-- Forbidden Keywords -->
<argument>FIXME|Auto-generated method stub</argument>
<!-- search path -->
<argument>src/main</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Going to SonarQube to do that is not a bad idea.
Anyway, if someone wants to use a maven-only solution, then the right way would then be by using a plugin dedicated to "enforce" things with maven builds. Using exec-maven-plugin is not that standard and certainly too much platform-dependent.
This plugin is logically named maven-enforcer-plugin and writing a custom enforcer rule is actually very simple.
I would create a small program to run these checks and then execute it via the exec-maven-plugin. If you find the keyword in the main resources then just return a non-zero return code which will cause the plugin to fail the build.
Sonar has a taglist plugin, which allows you to search for strings in your comment blocks and specify the severity handling. I'm assuming that is what you're looking for... Parsing the source code itself might require a custom rule for a tool like checkstyle, I haven't tried this approach but it's documented on the Sonar site.
This can be coupled with the build breaker plugin, which fails your build when an alert criteria is breached in your project's quality profile.
I think the taglist-maven-plugin is exactly what you want.
Actually when i build my project it deploys the bundle to the running OSGI console. Now the bundle is in installed state and shows an red alert that commons-net bundle can not be find.
One way of solving this is problem is to install the bundle to the running osgi framework itself explicitly.
Another way could be adding Embeded-Dependency to the maven. But this approach is not working.
I added Embeded-Dependency to the instruction tag in maven-build-plugin. It didn't show any error.
Please let me know if any suggestions.
Embeded-Dependency did not show any error as you can place anything into the instructions. If the key-value pair is not known it will be simply inserted into the MANIFEST.MF as it is. Try writing Embed-Dependency, that should make it work.
A good example could be the following (how we created hibernate bundle for ourselves):
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>
<_exportcontents>
!org.hibernate.validator.*,
org.hibernate.*;-noimport:=true,
</_exportcontents>
<Import-Package>
javax.persistence*;version="1.1.0",
javax.naming*,
javax.sql,
javax.transaction*;version="1.1.0",
javax.xml.stream.*,
javax.xml.*,
org.slf4j,
org.w3c.dom,
org.xml.sax*,
antlr.*,
org.jboss.logging.*,
org.dom4j*,
*;resolution:=optional
</Import-Package>
<Embed-Dependency>
groupId=org.hibernate;artifactId=hibernate-core,
groupId=org.hibernate;artifactId=hibernate-entitymanager,
groupId=org.hibernate.common;artifactId=hibernate-commons-annotations
</Embed-Dependency>
</instructions>
</configuration>
</plugin>
I feel a bit stupid about this question but i can't figure out how to add a SINGLE dependency (jdom.jar) into another jar.
Context: We developed a simple plug-in for our application, this plug-in have many dependency. We were using fatjar to include jdom.jar into it. I am trying to fix a bug in this plug-in, so i decided to "maven-ize" it at the same time. (We just switched to maven) This plug-in is loaded on the runtime so the only dependencies we want packaged with it is the jdom.jar.
Problem: I found that there is a maven fatjar plug-in! Unfortunately i could not find any documentation and this maven plug-in add EVERY dependency into the ouput jar. After many try i decided to give up on this fatjar plug-in and searched for another one. I found one-jar , shade but after a quick read on them they look like they add every dependency.
Question: what would be a simple way to add only jdom.jar into my plug-in jar like this:
-MyPlug-in.jar
|
|-src
|-main
|-java
|-*.java
|-jdom.jar
Also I don't want to alter the manifest or the output jar filename
Thank a lots for your time.
There was no answer here regarding how to use maven to include one single jar-file with the maven-shader-plugin. It took me some time to figure out how to actually do that. Here is a snippet to include just the classes from the dependency com.googlecode.json-simple:json-simple.
<project>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<includes>
<include>com.googlecode.json-simple:json-simple</include>
</includes>
</artifactSet>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
...
</project>
For this kind of purpose i would suggest to use the maven-shade-plugin which will create a ueber-jar which can be controlled in many ways.
With the shade plugin you can exclude things you don't like. But this might be caused by not using a separate maven module where you can control the dependencies.
Using maven Shade would work fine, one-jar would have done the job too.
But we finally decided that packaging jdom in our extension would be a bad practice.
So instead we gonna do this:
|-Root application Folder
|-Extension Folder
|-MyExtension.jar
|-libs Folder
|-jdom.jar
The jar into the lib folder will be loaded dynamically and won't be loaded if the extension cannot find the appropriate libs into the libs folder.
For the people who look to solve my primary problem please check out #khmarbaise Answer.