Lóránd Somogyi

Just a short bash script on how to check out only trunks of Maven projects (single and multi-module).

Note: This works only for default svn layout with default maven layout.

output=`svn ls -R | grep trunk/pom.xml`

for line in $output
do
  len=`expr ${#line} - 8`
  p=${line:0:$len}
  echo $p
  res=`svn up --parents $p`
done

Usage: check out the “root” of form the SVN with -N, like this:

svn co -N https://my.com/svn/myRoot

Go to the new directory (cd myRoot) and execute the script.

At the time of writing this openconnect in Ubuntu 12.10 have a bug, that disconnects the client from the VPN.

There is an issue for it: https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1072328

And a solution from Michael R. Crusoe.

Just do:

sudo apt-add-repository ppa:misterc/ppa

sudo apt-get update

sudo apt-get upgrade

That’s it.

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.

Read more…

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.

Read more…

Changes:

• threshold feature
• update site back to normal
• limited Java support – reports misspelled words (underline), but no proposals
• latest JNA

Link to project page: http://code.google.com/p/hunspell4eclipse/

Eclipse has a built in spell checker. It’s based on word list files. It is just fine for languages that does not use pre- and postfixes extensively. But for languages like Hungarian, it is a no go. – I’ve tried to generate a word list of Hungarian words, but when I noticed that the word list reached 35 GB (not a typo!) I’ve canceled the process. – Just imagine Eclipse loading 35+ GB of dictionary…

In my search for a spell checker for Eclipse I found eSpell, but eSpell is also a word list based engine, so that is a no go too. I left with no choice but to create one. So here it is:

Hunspell4Eclipse

Immature. In beta stage. Lot to do. But it works…

Plans

I’m planning to provide content sensitive checking for Java and XML. Actually my plan is to create extension points for that purpose, to provide possibility for others to contribute too.

Comments please

I hope you’ll enjoy the plug-in and that you found it worthy to comment.

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…

The next step: repository

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

Versions

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…

The first problem: Prussic Corporate Environment

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.

The second problem: Licensing

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…

Conclusion

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:

• cd to root of the Maven Repository folder, in my case: cd /data/mvnrepo/releases-backup
• execute the script: /path/to/script/mvn-metadata-gen.pl

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:

• cd to root of the Maven Repository folder, in my case: cd /data/mvnrepo/releases-backup
• execute the script: /path/to/script/mvn-sha1md5.pl

(Well, this could be Bash script too…)

Script could be downloaded at download page.

Please report any problem, bug, issue at projects issues page.

Lift the weight

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:

• Artifactory eats up less Memory, CPU and disk space
• Backup is much smaller
• Maintenance is easier
• Upgrades are less painful

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):

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…