There is a guide on the topic from Maven. But that guide is missing an example on how to use it from within Mojo.
So let me show you a short example on a topic… Read more…
[Update:] Looks like the originator is Brian Fox from Sonatype with this article.
A short example on how to find out if the given maven execution is the root of execution, — or in other words: how to know if you are inside of a multi-module project module or in the parent?
Just extend your Maven Mojo from this abstract mojo and call isThisTheExecutionRoot()…
import java.io.File;
import org.apache.maven.execution.MavenSession;
import org.apache.maven.plugin.AbstractMojo;
public abstract class AbstractMojo extends AbstractMojo {
/** Maven Session.
*
* @parameter default-value="${session}"
* @required
* @readonly
*/
protected MavenSession mavenSession;
/** Base working directory.
*
* @parameter default-value="${project.basedir}"
* @required
* @readonly
*/
protected File basedir;
/**
* Returns true if the current project is located at the Execution Root
* Directory (where mvn was launched)
*
* @return true if execution root
*/
protected final boolean isThisTheExecutionRoot() {
final boolean result = mavenSession.getExecutionRootDirectory()
.equalsIgnoreCase(basedir.toString());
return result;
}
}
This code probably originates from Maven Changes Report Plugin: http://maven.apache.org/plugins/maven-changes-plugin/xref/index.html, but as I failed to find it within 10 minutes, I thought it might worth sharing.
log4j:WARN No appenders could be found for logger (org.apache.openejb.resource.activemq.ActiveMQResourceAdapter).log4j:WARN Please initialize the log4j system properly.log4j:WARN No appenders could be found for logger (org.apache.openejb.resource.activemq.ActiveMQResourceAdapter).log4j:WARN Please initialize the log4j system properly.
That’s it.
This is just a short description on how to use OpenEJB with Tomcat to debug it within Eclipse.
The point is to be able to debug EJB applications from within Eclipse with a lightweight Tomcat container using OpenEJB.
Changes:
Link to project page: http://code.google.com/p/hunspell4eclipse/
You’re building a web application with some nice interface. You use JQuery and a bunch of Javascript libraries on top of it. So you download those applications and place them into your deployable package and reference them from your application.
But why do we wrestle with resources of (OSS) libraries? Downloading new versions, copying the resources to our application and deploying it again and again for each and every application.
I think W3C get that right. For example with XML Schemas: Usually XML Schema files (XSD) should be placed on some accessible URL on the Internet (or Intranet). So when you define your XML with schema definition you provide an URL which points to a resource on the Internet. Each application using the XML can fetch the Schema file and use it. Those URLs are fix URLs, does not change over time. So why don’t we do the same with Javascript files, images, etc.?
For example those popular FAMFAMFAM icons could be accessible one-by-one. Or just think of most popular JavaScript libraries like JQuery, Prototype, YUI, script.aculo.us, – you name it, – all could be accessible on a well defined URL. In that case we could access them whit a simple URL. Set up would be easy as pie…
We could provide a central repository for these resources. Something similar to Maven Repository but for other resources. It would be enough to have a unique name (as an Id).
For example I would put JQuery to a next path:
http://ossresources.org/jquery/jquery.js
Of course we need versions too. Or we could end up with non-working websites or applications from time-to-time.
My proposition would be, to extend the path from above to (kind of Maven way):
http://ossresources.org/jquery/1.3.2/jquery-1.3.2.js
Of course we could have Meta-versions too, like latest, snapshot, etc..
There are some problems with the setup from above. Lets see…
In corporate environment sometimes there are no access to the Internet, or the there are prussic proxy rules. In that case there is no access to the resources from above. – There is a same problem with XML Schemas too.
The only solution to this, is to set up a corporate repository that would proxy the resources to the Intranet. – Similar to Maven Repositories, like Artifactory or Nexus.
Okay. I’m not a lawyer but I think this is actually the bigger problem. We should find a way to distribute licences with resources too. We might put licences beside the resources, or provide a link for each resource. I just don’t know, I hope there are some folks that know the answer, and we could create a real repository…
I think this was the intention of the inventors of the web, but as usually something went wrong…
As you might know we use Maven extensively. We have a corporate Maven Repository served by JFrog‘s Artifactory. We have more than 30000 artifacts in our repository, – about 35GB of backup.
We try to keep up-to-date with new Artifactory releases. Unfortunately some times upgrade is not that smooth, so we need a backup and a drop-in service in case of failure.
As most of our artifacts are just old releases, we decided to create a secondary service, which acts as a drop-in service in case Artifactory is down. The idea is simple, just create a repo1.maven.org like service, with simple HTTP. Each time upgrade is to take place, copy all the new data to that repository and switch the service to point to it. – This works in case of failure too, just copy the backup to a simple “repository”.
To create the simple repository we took our Artifactory backup, removed the Artifactory specific meta-data and copied to a directory and configured an Apache HTTPD to serve it. Unfortunately the Artifactory backup contains no maven-metadat.xml, which plays key role in resolving versions. I was sure there is a maven-metadata.xml generator somewhere on the Net. But there were none! We needed it badly, so I created one. It is a simple Perl script that runs under Linux (uses shell commands extensively). It takes care of releases, but ignores SNAPSHOTs. Afterwards I realized that we need to produce md5 and sha1 checksums to, so I’ve created another script.
I thought it would be nice to share the scripts, so I’ve created a project on Google Code under maven-scripts name.
To create maven-metadata.xml:
You will see 2 lines for each maven-metadata.xml generated: one for the metadata, the other for sha1.
If you need md5 and sha1 sums for POMs and JARs:
(Well, this could be Bash script too…)
Script could be downloaded at download page.
Please report any problem, bug, issue at projects issues page.
If you have a lots of artifacts as we have, you could lift the weight a bit from your Maven Repository creating a repository as described above and setting it as a mirrored repository.
We do that, and now:
After my last article some folks at the company I work for asked for a Apache Commons Logging version of templates, so here it is.
Just as with the last article, import this templates: clogger-templates
The mappings are (in case you would like to use with SLF4J):
| clogger | create a logger instance with imports |
| cloginfo | create log entry of info level |
| clogerror | create log entry of error level |
| clogwarn | create log entry of warn level |
| clogtrace | create log entry of trace level |
| clogdebug | create log entry of debug level |
| clogfatal | create log entry of fatal level |
Have fun.
I’m sure lot of Eclipse developers are happy with Log4E, but for those who does not have Log4E or do not like to “pollute” Eclipse with plugins, I wrote few templates for SLF4J logging.
Just open Preferences and navigate to Java>Editor>Templates
Eclipse Preferences
…and press Import… button. And import: slf4j-eclipe-templates (download this file first)
Hit OK. Read more…
How nice it would be…
…to have DITA supported as a Doxia format, to be able to use DITA as a Maven site “language”.
…that Maven site could be rendered to eclipse help plug-in
…and deployed to Eclipse InfoCenter Server.
That would mean, that you could write single-source documentations that would be browse-able, indexed and search-able.
We use these technologies separately, and now I’m considering connecting them.
There are others with similar thoughts, but to be quite frank it looks like we’re alone…