Open Development Platform

Eclipse Platform

Subscribe to Eclipse Platform: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Eclipse Platform: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Eclipse Platform Authors: Janakiram MSV, Ken Fogel, Marcin Warpechowski, Michael Meiner, Liz McMillan

Related Topics: SSL Journal, Intel XML, Oracle Journal, XML Magazine, Eclipse Platform, CIO/CTO Update

Blog Feed Post

How to turn an XML Gateway into a Maven Repository

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.

Read the original blog entry...

More Stories By Josh Bregman

Josh Bregman has over 15 years experience architecting Java and JEE based security and identity management solutions. Josh is the Chief Solutions Architect at Vordel where he leads up the North American Pre-Sales team. Prior to Vordel, Josh worked for three years at Oracle as a Consulting Solutions Architect at where he advised Oracle and its key customers on technology, architecture, and implementation best practices. Prior to joining Oracle, Josh worked at BEA Systems for 3 years as the Enterprise Security Specialist for the Americas. In this role, Josh worked with customers to develop security solutions for WebLogic Server and related BEA technologies. Before joining BEA, Josh worked at Netegrity/CA for 5 years where he designed and developed a number of Java based security products, including IdentityMinder and SiteMinder Application Server Agents for BEA WebLogic Server and IBM WebSphere.Josh has also held engineering positions at GTE/Verizon Labs and IBM Global Services. Josh received a B.A. in Mathematics from the University of Rochester. Josh and had spoken at a number of industry conferences including the RSA Security Conference, BEA World and Oracle Open World. Josh was a contributing author to Wiley's Professional Oracle WebLogic Server (2009). He is a lead contributors and architect of the OpenAz open-source project - an initiative to standardize and promote the adoption of externalized authorization. He is also the author of the Vordel XML Gateway blog at http://xmlgateway.blogspot.com.