Ok, I found out the cause(s). There were multiple layers to this problem:
- I can't type properly (the pom.xml file had inconsistent pathing and snapshot -vs- release settings in the wrong places)
- Roo can't deal with redirects from http:// -> https:// when loading from an OBR repository, and it expects you are only using an http:// one
- I was using an https:// based maven repo with cloudbees, but Roo tried to access it as http://, only to be requested to switch with a 302 MOVED - they aren't using http client, but that is an easy fix and it would follow redirects.
- Further, there should be support for a httpspgp:// url pattern as well as a httppgp:// pattern so that we don't start with http:// only, therefore cause a redirect in the first place
Details...
My POM file for review: https://gist.github.com/2378379 - it could still use some cleanup but it works for me now.
The maven pom.xml file is generated assuming you use a http:// based Maven repository during deployment of an add-on. However, https:// is what I use.
I am going to point to a gist of my working pom.xml file for those of you who have ever struggled with setting one up on git - I know I have and will post a blog entry on this shortly.
Here is the offending block that causes the pain for accessing SSL repositories, in the middle of the soup:
Code:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.4</version>
<extensions>true</extensions>
<configuration>
...
<bundleUrl>httppgp://ec2-54-248-4-46.ap-northeast-1.compute.amazonaws.com:8081/nexus/content/repositories/releases/org/sillyweasel/addons/jqueryui/org.sillyweasel.addons.jqueryui/${project.version}/${project.artifactId}-${project.version}.jar
</bundleUrl>
</configuration>
</plugin>
Because Roo has this special bundleUrl entry with a prefix httppgp it can't handle SSL requests. It doesn't have a correlated httpspgp to handle that. So, we request non-SSL traffic on an SSL port, and the Nexus server is nice enough to return a 302 MOVED script pointing to the SSL version. At which point, Roo chokes.
This is easily fixed by using HTTP Client, I think, and also by adding an httpspgp prefix and just chopping off pgp from the end of either of them.
So, for now until Roo can handle public ssl-based repositories, try to either upload the artifacts by hand or use a manual local repo build. For example, you can build into a directory structure like this:
Code:
mvn -DaltDeploymentRepository=snapshot-repo::default::file:../sillyweasel-maven-repos/snapshots clean deploy
The above: -DaltDeploymentRepository says to take the server id'ed 'snapshot-repo' in the distributionManagement section, and replace it with a deployment to a file-based directory on your hard disk. That can be a git repo btw, which you can then add your changes to and push up. YAY.
Also, one more thing:
With this setup and with httppgp, you can't necessarily use mvn release prepare and release perform. I had trouble doing this even with releases. When Roo writes out the repository.xml OBR directory in the root, it has to manipulate a lock file, and that makes the lock file have to respond to a re-writing of the value. Except with nexus, that file is not allowed to be changed (we are uploading releases so no replacements). So I had to disable checks on this as well. I will potentially be filing another JIRA as a result of this.
I'll keep you all posted on the patch I'm working on, plus make sure to let you know what I run into as I keep going deeper into add-on writing.
Best,
Ken
Roo, cloudbees, and maven - not complete joy can anyone help?
erform as maven tells me that it got error '1' - with NO OTHER MESSAGE
Reply With Quote
