I've made some real progress on the Maven integration with the Vordel XML Gateway. I've updated the
incubator with the latest set of policies. These policies provide two main features:
- The ability to download the Gateway libraries as dependencies directly from the gateway
- The ability to deploy Maven artifacts to the gateway
Exposing the libraries of the Gateway as POMs
One of the main challenges in getting a technology like the gateway that isn't built using Maven into the Maven world is the mapping of jars to POMs. As I showed previously, you can do this, but its a manual process. You could automate it with ANT tasks, but its still tricky. I encountered this problem before when I was trying a
similar exercise with Oracle Entitlements Server. For that I wrote a bunch of custom code and deployed it as a WAR to the OES Admin Server. Not bad, but with the gateway it was even simpler.
Basically I used the static content service to point to the directories on gateway, and then used a policy to handle a view of the subtleties - we only have MD5 checksums, POMs need to get generated since we don't have them, some of the mappings for the org.eclipse libraries are irregular. For the main case, retrieving the jar, I'm just manipulating the http.request.uri property and passing it to the static content service. Magically, it returns the POM, the JAR, and the MD5 checksum of the JAR. I also used a cool feature new to 6.0.3 - the ${env.xxx} capabilities. You can use this namespace from inside of a policy, and the gateway will resolve the value based on the
envSettings.props file. I used this to specify the values of the location of the gateway in my environment
env.maven.gateway.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\vordelgateway\\system\\lib
env.maven.policystudio.path=c:\\Users\\jbregman\\Documents\\products\\xml gateway\\policystudio\\plugins
env.maven.repo2.path=c:\\Users\\jbregman\\repo2
In order to take advantage of my gateway as a repository, I modified the parent POM of the sample-filter, to include:
<repositories>
<repository>
<id>vordelgateway</id>
<url>http://localhost:9090/repo</url>
</repository>
</repositories>
This means that when its looking for the dependencies, it will check the gateway, and they will be downloaded to your local repository so you can compile. Maven supports SSL and Basic Authentication, so these things could easily be added to both the Maven configuration as well as applied to the Maven policies running on the gateway.
Deploying Maven Artifacts to the Gateway
The first question is "Why would you want to do that?". One use case that I'm working on is for custom filters. Once the jar is built, it needs to be copied to the gateway's lib directory, so this is the foundation for that. I'm not there yet - need to do something with the file once its there, but I like the simplicity of using the mvn deploy task to push the artifact to the gateway for me. Ultimately my goal is to package up all of the dependent artifacts and push/deploy them to the gateway.
The policies for this one were a little more complicated because the static content service only gets me so far - it doesn't handle HTTP PUT requests- which is what Maven uses to push the files to the server. No problem - I simply used the
Save to File filter - to store the file on disk. Again, I used the ${env.xxx} to define the location on disk for the repository.
In order for projects to take advantage of this capability, I again modified the parent POM:
<distributionManagement>
<repository>
<id>dev-integration-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</repository>
<snapshotRepository>
<id>dev-integration-snapshot-gateway</id>
<name>Dev Integration Gateway</name>
<url>http://localhost:9090/repo2</url>
</snapshotRepository>
</distributionManagement>
This means than when you run
mvn deploy the artifact can be pushed and stored on the gateway. Presumably, in addition to just deploying the file, other actions could be taken - synchronously or asynchronously.
Implications for the SDLC
Notice that in the parent POM, there is the same server (localhost) referenced both times. I put the two separate repositories on different relative paths to simplify the implementation, but in practice these repositories are likely to be on separate instances. The idea is that a developer working on a sandbox instance can download the libraries to their local repository, develop the component and then deploy it to the dev-integration-gateway. The thinking here is that this gateway is the first managed gateway. The gateway's configuration is then pushed using the policy directory from the dev-integration gateway to QA. Getting all of this to work end-to-end using Maven is the goal of
Maven Integration project on the incubator.
If you like where this is headed, get involved, join the incubator at
cloudservicebroker.googlecode.com.
