Properties resolution in Maven and its implications on Antrun plugin

Two days ago I did some internal research in order to understand how do resolved properties propagate from Maven to Ant via maven-antrun-plugin. On my way I had to recall several rarely remembered facts and learn some new ones. The implications of their combination leads to pretty interesting results that are worth writing them down. At least, now I’ll know where to look for this information next time.

Fact #1
There are multiple sources for properties resolution in Maven – implicit project properties (like project.version), environment variables, user-defined properties (ones you use in properties tag or your pom.xml), Java system properties… The full list with detailed explanations is available in The Complete Reference online book.
Pay attention – when you “override” some user-defined property via command line parameter (-D), in fact you are setting a new Java system property. This works because system properties have higher precedence during properties resolution process.

Fact #2
All properties that are explicitly used in pom.xml are resolved before Maven lifecycle actually starts, even before the initialize phase. It happens when so-called “effective pom” (full project definition, including all implicit data and configuration settings propagated from parent project) is generated. BTW, you can see this in action by call mvn help:effective-pom on your project.

Implication #1
Modifications of project properties that happen during project lifecycle have no effect on the effective pom – it is just too late. Examples of such modifications include groovy scripts (via gmaven-plugin) and properties loaded from external files via maven-properties-plugin. So, why do we need them at all? Since they can be used by other plugins in runtime, when they are read directly from properties collection during plugin invocation.

Continue reading “Properties resolution in Maven and its implications on Antrun plugin”

How to attach Maven artifact from external build.xml file

As you probably know, maven-antrun-plugin provides a custom AttachArtifact task that is able to attach artifacts generated by Ant to the current Maven project. The usage is really straightforward with inline Ant targets, but an attempt to use this task with external build.xml results in an error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (...) on project ...: 
  An Ant BuildException has occured: The following error occurred while executing this line:
[ERROR] C:\...\build.xml:158: Maven project reference not found: maven.project

[ The solution described here does not really work. See update at the bottom. ]

The solution is simple – external Ant invocation should inherit references from the inline target:

<plugin>
	<artifactId>maven-antrun-plugin</artifactId>
	<executions>
		<execution>
			<id>...</id>
			<phase>compile</phase>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<target>
					<ant antfile="build.xml" target="..." inheritRefs="true" />
				</target>
			</configuration>
		</execution>
	</executions>
</plugin>

Update: It appears that this change eliminates the error, but the artifact is not actually attached. I’ve opened a bug report to the Maven Antrun Plugin team about that.

How to unpack RAR files on AWS-hosted Ubuntu servers

It appears that regular unrar package is not available by default via apt-get on AWS Ubuntu servers. If you still need to unpack RAR files and prefer to install packages from default APT repositories only, the right package to install is unrar-free. It will do the job for you in most of the cases.

ubuntu@ip-10-0-0-38:/work/$ sudo apt-get install unrar-free
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
pike7.8 pike7.6 pike
The following NEW packages will be installed:
unrar-free
0 upgraded, 1 newly installed, 0 to remove and 43 not upgraded.
Need to get 24.8 kB of archives.
After this operation, 101 kB of additional disk space will be used.
Get:1 http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ saucy/universe unrar-free amd64 1:0.0.1+cvs20071127-2 [24.8 kB]
Fetched 24.8 kB in 4s (6,201 B/s)
Selecting previously unselected package unrar-free.
(Reading database ... 67423 files and directories currently installed.)
Unpacking unrar-free (from .../unrar-free_1%3a0.0.1+cvs20071127-2_amd64.deb) ...
Processing triggers for man-db ...
Setting up unrar-free (1:0.0.1+cvs20071127-2) ...
update-alternatives: using /usr/bin/unrar-free to provide /usr/bin/unrar (unrar) in auto mode
ubuntu@ip-10-0-0-38:/work$ 

Unfortunately, sometimes unrar-free is not enough – for example, when you have to unpack multipart archives. In this case you’ll have no choice but to obtain the original RAR for Linux software by enabling Multiverse repository. Alternatively, you can download the trial version directly from the official RARLAB site.

Opening SSH to AWS-hosted Linux servers via mRemoteNG

mRemoteNGmRemoteNG is nice and lightweight tabbed session manager. It is a perfect fit to manage your remote server farm with both Windows and Linux machines, since it supports multiple connection protocols out of the box – including SSH and RDP (yet, you may need to update your older Windows client to run newer RDP version).

However, connecting to Linux instances that run on AWS requires a bit more than just SSH client. As you probably know, Linux EC2 instances have password authentication disabled by default to prevent brute-force attacks and want you to supply your private key instead. But there is no such field in mRemoteNG configuration pane! So, how can you configure it to send your private key instead of password?

It appears that mRemoteNG relies on embedded PuTTY to provide SSH support. In turn, PuTTY by itself is able to work with private keys authentication required by AWS. Here is the detailed explanation about the configuration steps.

Continue reading “Opening SSH to AWS-hosted Linux servers via mRemoteNG”

How to fix WebSphere 7.0 on Windows 2003 that hangs on startup

WebSphere Today I spent several hours troubleshooting the fresh install of WebSphere 7.0 on Windows 2003. The server passed all post-installation steps successfully, but refused to start after the OS reboot. The last line in the server logs was “Server launched. Waiting for initialization status.”, and the actual server state was unclear – any attempt to start it anew claimed that the service was running, but the server console was not available.

It appears that the Windows service installation, which happens by default during setup time, was problematic. Once you remove the service and reboot the system, you can start WebSphere manually without any trouble.

Here is how to remove the Windows service:

  1. Go to the “bin” folder under WAS installation directory (usually “C:\Program Files\IBM\WebSphere\AppServer\bin”)
  2. Execute the following command: “WASService –remove <name-of-server-node>”

Typically, the name of server node is composed from the computer name with “Node01” suffix.
For example, the node name on “was70-win.mycompany.com” will probably be “was70-winNode01”.

Hat tip to this IBM DeveloperWorks community post for the hints!