I have two questions to ask;
The first is that I am needing to know what the importance is of signing a java project's artifacts with "GnuPG".
My current situation is that I am looking into releasing my first public java project. I am using Maven to build and manage the project, and came across the "Maven-GPG-Plugin". The documentation on the plugin is extremely vague and does not describe why one should sign artifacts with "GnuPG". I have no experience with GnuPG/Maven-GPG, so I am wondering what the benefit is of using this maven plugin?
The second question I have is how would I go about using this plugin on my java project in Eclipse?
Would just adding the following to my pom.xml sign the project for me when I build it?
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
If not, how would I go about properly signing the project with maven in Eclipse?
Thank you!
I have no experience in actually using GnuPG with Maven (I have never released Maven-plugins), thus I'll limit my answer to the first part of your question.
The documentation on the plugin is extremely vague and does not describe why one should sign artifacts with "GnuPG". I have no experience with GnuPG/Maven-GPG, so I am wondering what the benefit is of using this maven plugin?
Simple hash sums that can only be used to realize accidental transmission problems like bit flips. Unlike those, GnuPG issues cryptographic signatures, which also are capable of recognizing transmission issues, but additionally enables you to verify the author of the signed data.
Without cryptographic signatures, there is no way to know whether the code/program you're downloading and executing is actually the one you're expecting. Missing or unverified cryptographic signatures again and again result in downloads with backdoors, just recently Linux Mint had such an issue.
Cryptographic signatures do not mean the code is correct and has no (security) issues, but at least know you have the same code the author published, which reduces chances of backdoors significantly.
Related
I'm working with a project that has, historically, been supported and developed in an Eclipse environment. I'm hoping to move this over to Intellij, and I'm currently using the full (Ultimate) package.
There are a few intricacies of the build process that don't appear to be working, which relate to selectively building the resources for the project. I could work around this, but would rather try and understand why IntelliJ and Eclipse are building the same project in a slightly different way.
I've noticed in my parent POM that the following code has an issue:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includes>
<include>**/*.js</include>
</includes>
<nosuffix>true</nosuffix>
</configuration>
</plugin>
Intellij is saying element includes is not allowed here' and itcannot resolve symbol 'include'`.
As far as I can see, the declarations are valid and in the correct place, and maven appears to be set up as required with the maven plugins installed as required too. The POM uses the http://maven.apache.org/maven-v4_0_0.xsd schema.
This kind of stuff has generally been left untouched for a number of years, but I can't see why it is having issues with this particular symbol/declaration?
As above, I've checked the plugins, Maven settings, all the usual suspects. Another of the plugins uses <excludes> with no errors, which makes it a bit more of a puzzle to me?
Can anyone help?
I am new to Maven and I am trying to get strong hold of it. I have gone through the beginner's tutorials and I am able to understand the basic stuff, but I have a complex pom.xml file in my project and my next goal is to understand that.
With the limited knowledge acquired from beginner's guide it is not possible for me to understand that complex pom.xml, so i was thinking of adding some sort of log statements in pom.xml or looking for an alternative via which i could track the flow of execution in pom.xml, since that would help me in knowing how things are moving.
You could printout some log messages to maven console using the maven-antrun-plugin, you can also specify the phase you want to print the message in, see the code below (it goes to the plugins section)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>print-log</id>
<phase>initialize</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<echo message="Your log message for project ${project.artifactId}" />
</target>
</configuration>
</execution>
</executions>
</plugin>
I believe that output generated by debug option in maven can be quite huge and time consuming for reading. I use it only for some specific problem analysis.
For me it allways worked to go through complicated pom.xml files by reading and try to understand intent of the author of the particular section (I think good reference for the pom.xml elements can be found on: http://maven.apache.org/pom.html).
Once you run build afterwards, you can see what and when is it executed and you can find mapping between what you've learned before and how it really works :)
You can start by issuing
mvn -X install
That will give you the flow of execution.
According to mvn --help:
-X,--debug Produce execution debug output
An alternative if you want to see all your dependencies, properties, plugins, directories etc. the try this:
mvn help:effective-pom
I would recommend to read more about Maven build lifecycle. Maven is not a script-like build automation tool (like ant or make). It's a different approach. Logs should be less important than output artifacts produced in ./target directory.
I'm currently in the midst of converting a large multi-module project (~100 sub-modules) to use Maven. Currently we use Ant + Ivy.
So far no major issues have cropped up and I'm comfortable that Maven is still a good fit. However, I wonder if there is a better way to handle native dependencies.
So far I have come to the following conclusions.
It's best to install each native dependency into the maven repo either as a standalone library or an archived package containing multiple dependencies.
Rather than get lost in declaring each and every dependency with the Maven dependency plugin, I opted to give each a classifier (e.g. natives-win32) and use the following in the parent POM:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy</id>
<phase>compile</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<includeScope>runtime</includeScope>
<includeClassifiers>natives-win32</includeClassifiers>
<outputDirectory>${project.build.directory}/natives</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
So far this seems to be a simple all-round solution that doesn't require too much messing about to add new native dependencies. It also offers me a simple all-round solution for managing natives. The only thing I must do is ensure that my /natives/ directory is defined on java.library.path.
One thing that bothers me (a little) about this approach is that all my native dependencies get copied around to each sub-module that expresses a transitive dependency on them, whilst my happy jar libraries are added to the classpath referenced to where they sit in my local repository (no copy required).
Is there no way to be smarter about this and have my natives referenced from withing their repository location (assuming I don't have them archived, i.e. dll). That would save a bunch of unnecessary copying about.
Are there any other potential gotchas' that I should be concerned about with the above approach?
Your snippet shows a goal attached to a build phase, not a dependency. Is the 'copy dependencies' goal in a super pom and inherited by all modules? There's no way to move it only to the modules which are going to be run/packaged as an app?
It could be, that I didn't got it. But why don't you deploy all your native libs into the repository at first. If the native libs are stable and change seldom, That could be done in a seperate reactor.
And afterwards you reference those native dependencies simply via GAV as any other dependency. Also the problem af unnecessary copying is solved by that.
I ended up using the maven natives plugin and dealing with the fact that I have redundant copies of the native libraries around the place. The reason for this was primarily due to the simplicity that the plugin offers and the fact that it also has a related eclipse plugin that sets up natives in developers eclipse environment without intervention.
I've been a long time user of the Make build system, but I have decided to begin learning the Maven build system. While I've read through most of the online docs, none seem to give me the analogies I'm looking for. I understand the system's lifecycle, but I have not see one reference to compile step dependencies. For example, I want to generate a JFlex grammar as part of the compile lifecycle step. Currently, I see no way of making that step a pre-compile phase step. Documentation seems to be limited on this. In general, the concept of step dependencies seem to be baked into Maven and require a plugin for any alteration. Is this the case? What am I missing, because currently the Maven build system seems very limited in how you can setup compilation steps.
You can do anything in Maven. It generally has a default way to do each thing, and then you can hook in and override if you want to do something special. Sometimes it takes a lot of Stack Overflowing and head scratching to figure it out.
There is even an official JFlex Maven plugin.
Whenever possible, find someone who has made a Maven plugin do what you want. Even if it isn't 100% right, it may at least give you an idea on how to make maven do something.
Minimal configuration
This configuration generates java code of a parser for all grammar files (.jflex , *.jlex , *.lex , .flex ) found in src/main/jflex/ and its sub-directories. The name and package of the generated Java source code are the ones defined in the grammar. The generated Java source code is placed in target/generated-source/jflex , in sub-directories following the Java convention on package names.
pom.xml
<project>
<!-- ... -->
<build>
<plugins>
<plugin>
<groupId>de.jflex</groupId>
<artifactId>jflex-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<!-- ... -->
</build>
<!-- ... -->
</project>
This feels like the maven way to do things. Put your stuff in the right folders (src/main/flex), and this plugin will automatically build it into your project. If you want to do fancier custom stuff, there are some options. but Maven is all about favoring convention over configuration.
To be frank I think that your current mindset maps much better to ant than to maven, and I would suggest starting with that.
I'm a lone Emacs user in a group that's hung up on Eclipse. Time and again, code diffs are made larger by imports that have been "organized" or "cleaned up" by Eclipse.
I don't have a strong opinion on the subject of import style in Java, but I do want to minimize our diffs. What can I do?
We use Maven2 for builds; is there a plugin that can help me? Can a piece of Eclipse be abstracted out & turned into a Maven plugin? I currently use ImportScrubber and have encountered a few other stand-alone pieces that do the same thing. What I'm really looking for is a Maven plugin that can integrate with the build.
Barring the above, I'll put an ImportScrubber invocation into my .git/hooks/post-commit.
The Hybridlabs beautifier which is used internally in the openArchitectureWare project (an open source generator framework) is doing what you're looking for. As explained in this blog entry, the beautifier is available as a Google Code project and its documentation describes a maven 2 plugin:
<plugin>
<groupId>org.hybridlabs</groupId>
<artifactId>maven-beautifier-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>beautify-imports</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- Recursively scan for *.java and beautifies imports -->
<inputDirectory>${pom.basedir}/..</inputDirectory>
<!--outputDirectory>${pom.basedir}/..</outputDirectory>
<runBeautifier>true/runBeautifier>
<runJalopy>false</runJalopy-->
</configuration>
</plugin>
There is indeed a mojo in the source tree but it doesn't match the groupId mentioned above (this is a bit confusing) and I've not been able to find the plugin in maven's public repository.
Maybe you'll be more lucky with the version available in AndroMDA plugin repository as documented in this thread (the plugin is indeed present in http://team.andromda.org/maven2/).
The plugin is under
org.apache.maven.plugins.maven-beautifier-plugin.
It can be run with the short form:
mvn beautifier:beautify-imports. It
can also be run as part of a project
pom by adding the plugin declaration
under <build><plugins>:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-beautifier-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<goals>
<goal>beautify-imports</goal>
</goals>
</execution>
</executions>
<configuration>
<inputDirectory>${pom.basedir}/target/src</inputDirectory>
</configuration>
</plugin>
Or contact the project's author (e.g. through twitter or by mail).
I think all of you (Eclipse, Emacs or whatever users) should use something like Jalopy which supports both Eclipse and Maven. This way it becomes irrelevant where the code was modified as long as it has been run through pretty-printer as part of checking code in. Said that - I'm not sure if Jalopy supports organizing imports beyond sorting these up
I have also found an ImportScrubber plugin. Can't as of yet attest to its quality.
Does your shop have code standards for how imports should be organized? If so then you are out of luck. Minimizing diffs is a small sacrifice to make towards incremental code improvement.