Latest Activity

[WSS4J 1.6] SAML property changes

Colm O hEigeartaigh - Sun, 03/13/2011 - 16:02
A previous blog entry described how WSS4J 1.6 will have support for creating, parsing, signing, verifying, etc. SAML 2 assertions. WSS4J 1.5.x had limited support for creating and signing SAML 1.1 assertions via the default SAMLIssuer implementation, combined with a properties file. These configuration values consisted of:
  • org.apache.ws.security.saml.issuerClass - The SAML Issuer implementation (defaults to "org.apache.ws.security.saml.SAMLIssuerImpl").
  • org.apache.ws.security.saml.issuer.cryptoProp.file - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • org.apache.ws.security.saml.issuer.key.name - The KeyStore alias for the issuer key.
  • org.apache.ws.security.saml.issuer.key.password - The KeyStore password for the issuer key.
  • org.apache.ws.security.saml.issuer - The issuer name
  • org.apache.ws.security.saml.issuer.sendKeyValue - Whether to send the key value or the X509Certificate. Defaults to: "false".
  • org.apache.ws.security.saml.subjectNameId.name - The Subject DN.
  • org.apache.ws.security.saml.subjectNameId.qualifier - The Subject qualifier.
  • org.apache.ws.security.saml.authenticationMethod - The authentication method (e.g. "password").
  • org.apache.ws.security.saml.confirmationMethod - The confirmation method, either "senderVouches" or "keyHolder".
The configuration tags for WSS4J 1.5.x completely controlled the creation and signing of a SAML 1.1 Assertion, and hence produced only a very limited set of possible assertions.  WSS4J 1.6 takes a different approach, where the configuration tags correspond to the configuration of the issuer, i.e. whether to sign the assertion or not, the issuer name, crypto instance, etc. All instructions about how to create the SAML Assertion itself, are left to a CallbackHandler implementation.

The following configuration tags in WSS4J 1.6 are exactly the same as in WSS4J 1.5.x:
  • org.apache.ws.security.saml.issuerClass - The SAML Issuer implementation (defaults to "org.apache.ws.security.saml.SAMLIssuerImpl").
  • org.apache.ws.security.saml.issuer.cryptoProp.file - The crypto properties file corresponding to the issuer crypto instance, if the assertion is to be signed.
  • org.apache.ws.security.saml.issuer.key.name - The KeyStore alias for the issuer key.
  • org.apache.ws.security.saml.issuer.key.password - The KeyStore password for the issuer key.
  • org.apache.ws.security.saml.issuer - The issuer name
  • org.apache.ws.security.saml.issuer.sendKeyValue - Whether to send the key value or the X509Certificate. Defaults to: "false".
The following configuration tags are new to WSS4J 1.6:
  • org.apache.ws.security.saml.issuer.signAssertion - Whether the SAMLIssuer implementation will sign the assertion or not. Defaults to: "false".
  • org.apache.ws.security.saml.callback - The name of the SAML CallbackHandler implementation used to populate the SAML Assertion.

[WSS4J 1.6] Basic Security Profile 1.1 compliance

Colm O hEigeartaigh - Tue, 03/08/2011 - 14:44
The Basic Security Profile (BSP) 1.1 specification provides an industry-standard way of making sure that different WS-Security stacks can communicate with each other, by clarifying and narrowing the scope of the various WS-Security standards. WSS4J 1.5.x does not implement the BSP in any meaningful way. The WSSConfig class supports a "isWsiBSPCompliant" method (default is false), which will enable the generation of an InclusivePrefix list for signature generation, something that is mandated by the BSP spec.

WSS4J 1.6 provides support for the BSP 1.1 specification, in so far as it pertains to the core WS-Security specifications that WSS4J supports. The enforcing of BSP compliance for inbound messages is controlled by the WSSConfig class, as per WSS4J 1.5.x. An important change is that BSP compliance is now turned on by default. In addition, a new WSHandlerConstants configuration parameter has been added so that BSP compliance can be controlled via a WSHandler implementation.

Maven Surefire executing only one test method in a test class

Olivier Lamy - Thu, 02/24/2011 - 11:13
I have just worked on a improvement in Apache Maven Surefire Plugin.
Most of the time you have a test class which contains a lot of test methods.
When only one failed you have to execute all methods of the class (with -Dtest=MyClass)
This can be long and boring :-).

So now (see [1]), you will be able to use -Dtest=MyClass#myMethod to execute only the method called myMethod from the test class MyClass.

The feature has been pushed in a github fork [2].
Why in a github fork : I'd like to have feedback fast :-)

So how to test it ? :

Get the sources :

git clone git://github.com/olamy/maven-surefire.git
cd maven-surefire
mvn clean install (add -DskipTests if you don't want to execute all integration tests).

Update you pom :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.3-SNAPSHOT</version>
</plugin>

And now test it :-)

-Dtest=MyTestClass#myMethod (note the support of * : -Dtest=MyTestClass#*Method )

NOTE : supported only for junit 4.x

Update : now supported for testng too.

Update 25 Feb : merged in ASF svn repo http://svn.apache.org/viewvc?view=revision&revision=1074633

Update 12 March : released in surefire 2.8 (Yeahhh :-) )

Have Fun ! (and don't miss to put feedback in case of issues)
--
Olivier

[1] http://jira.codehaus.org/browse/SUREFIRE-577
[2] https://github.com/olamy/maven-surefire


Categories: Olivier Lamy

Advanced Integration with the Talend Integration Factory

Sergey Beryozkin - Mon, 02/21/2011 - 15:56
Talend Integration Factory, the Community Edition, has been released recently and is available for the download. Additionally, the Advanced Examples distribution can be downloaded from here.

The Talend Integration Factory (TIF) is an advanced platform for building real-world application integration solutions. It is centered around the powerful Apache Camel integration engine.

What I'm finding interesting about this solution is that the people involved into building it have the in-depth knowledge about what it takes to build the integration solutions which work and scale really well. Their optimism and the number of their ideas is boundless, and this solution will grow and deliver the real value for the customers.

Give the examples a try - the team is planning to bring you some really interesting and advanced examples in time, please see Christian's blog entry for more information.
Categories: Sergey Beryozkin

Talend Integration Factory Released&#8230;.

Daniel Kulp - Wed, 02/16/2011 - 04:30
Back in December, I talked about the release of the Talend Service Factory as being the first step in the new product plans coming out of Talend. The second step occured today with the release of the Talend Integration Factory. (Click here for the official press release if you are interested.) Talend Integration Factory is [...]
Categories: Daniel Kulp

Sonar Instance @ASF

Olivier Lamy - Wed, 02/02/2011 - 22:30
A Sonar instance is now available at ASF http://analysis.apache.org/.

Builds are provided by Jenkins : http://analysis.apache.org/jenkins/ (yes I couldn't resist to use it even before the first official release :-) ).

If you want to add your project see : http://wiki.apache.org/general/SonarInstance

Have Fun and Thanks ASF INFRA !


Categories: Olivier Lamy

JAX-RS Attachments demo in TSF 2.3.2

Sergey Beryozkin - Tue, 02/01/2011 - 22:29
The Talend SF 2.3.2.0 distribution contains various minor improvements and has some dependencies, including the Karaf one, updated to new versions.

The Talend SF 2.3.2.0 Examples distribution contains a new jaxrs_attachments demo.

CXF JAX-RS offers a comprehensive support for reading and writing attachments and this demo tries to demonstrate it by showing how XOP and regular multiparts can easily be dealt with.

We are going to build upon it when we move on to doing the more advanced development with the proper support for multiparts being required.

Have a look at this demo if you're interested. And expect more interesting demos added soon. Stay tuned.
Categories: Sergey Beryozkin

Unified Search Experience Made Easy With CXF

Sergey Beryozkin - Fri, 01/21/2011 - 22:09
Providing the quality search experience is an important task for any serious web application project.

Most of the HTML forms let users do simple queries resulting in the equality or partial match checks on the server side. For example, "Find the book with the id starting from 123" or "Find all the books with the author's first name starting from Fred".

Imagine the following task. Provide a web interface which will let users search for all the books which have an id greater than 123. Or find the list if customers which paid less than 200 dollars.

What I've observed quite a few times is that when multiple services are built by individual teams within the same large organization or as part of single large project then every team will create its own query language.

One team will come with a custom query language built within this very team. And the other team working on some other service will build a slightly different variation of the custom query language.

The end result is that the users may need to learn two query languages, one in order to query the 1st service and the other one - in order to query the 2nd one.

Sometimes different teams will agree on using the same query language.

Using explicit SQL expressions is one option. Most likely a frontend UI tool will collect the user input and convert it into SQL and then pass it to the remote service. IMHO the use of SQL as a query language on the WEB should be discouraged for the obvious reasons: the fact the the end service uses an SQL database for storing the data is the very last thing the consumer should know about, just too much information is being leaked for this to work.

The use of XQuery or query languages created by Google Data and Microsoft teams is an entirely different approach. It does let developers provide a unified search experience to the users. For example, all the Google Data services have to support the same query language - something that users can appreciate.

As I mentioned in this post, CXF JAX-RS supports converting FIQL expressions into SearchCondition expressions which capture the FIQL queries and let users match them against the application data.

FIQL is indeed a simple language - please read this post from Arul for a nice introduction to FIQL. IMHO it does offer a viable alternative to more complex and advanced query languages and we'd like to continue enhancing the CXF search extensions for users be able to get the best out of FIQL.

The CXF SearchCondition interface offers a utility method for converting the FIQL queries to SQL expressions. This method (toSQL()) has been deprecated recently. While the users who find this method working for them may continue using it for a while, it is now recommended to use the SearchCondition visitors, thanks to Brian Topping for providing a patch.

It were possible to convert SearchCondition into more optimized SQL or non-SQL expressions even before the introduction of visitors but now the relevant code has become much cleaner. The SQLPrinterVisitor is shipped with CXF and it can be used to convert the queries to SQL, using the proper SQL aliases if needed. For example, imagine a query such as "a==b". The 'a' may easily be assumed to be the name of the column in some table - but we may not necessarily want the end users to 'hard code' the names of the columns in the queries; thus the SQL visitor lets the service developers to register an alias map, for the resulting query to contain say "A_Column" instead of 'a'.

I can imagine XQuery-aware and other visitors being added in time. In fact the way we are trying to build the search extensions is to make sure other query languages such as XQuery/etc are supported transparently. If users will start asking about supporting the new query language then we'll just provide the relevant SearchContext parser and SearchCondition visitor.

One immediate enhancement we are thinking of is to add a SearchQueryBuilder which users would use to build FIQL/etc queries using simple Java operations and pass the builder result to WebClients or proxies.

So imagine all the different web services within the same organization supporting the same simple URI friendly query language which is easy to understand and use. One thing you can be sure of is that the end users will appreciate it, especially when they start building their own client applications which need to query a number of those web services.

By the way, it should work nicely for CXF JAX-WS services too provided they've been JAX-RS-enabled.
Categories: Sergey Beryozkin

JAX-WS and JAX-RS United in CXF

Sergey Beryozkin - Sun, 01/09/2011 - 20:38
I've just reread the REST and SOAP United blog entry I did back in July 2008, more than 2 years ago.

This theme is as active as ever in CXF; as I've mentioned on this blog quite a few times we've been trying to provide the environment for SOAP developers to experiment with JAX-RS with as few changes as possible and indeed, quite a few CXF SOAP developers do use JAX-RS today while continuing running their SOAP services. Some developers are choosing to annotate the same service interface or implementation class with both JAX-WS and JAX-RS annotations, while some of those, preferring to do the WSDL-first approach, have tried to apply an external CXF JAX-RS user model, something that is demonstrated now in one of the Talend SF demos, and thus avoiding having to modify the (generated) code altogether.

There have been some new improvements recently in the integration between JAX-WS and JAX-RS runtimes.

First, many of the custom CXF annotations are now supported by the JAX-RS frontend. So one can easily do a combined JAX-WS and JAX-RS service which for example supports a FastInfoset feature by using CXF FastInfoset, Feature or In/OutInterceptors annotations, possibly also relying on say a DataBinding annotation enabling the CXF SDO DataBinding.

It was possible to wrap CXF DataBindings as JAX-RS MessageBodyReaders and MessageBodyWriters for a while, with XmlBeans being the latest DataBinding supported, thus effectively reusing the same provider instance between JAX-WS and JAX-RS endpoints.

But just a couple of weeks ago a CXF user asked about having JAX-RS MessageBodyWriters being used by SOAP JAX-WS endpoints. Does it sound a bit hairy to you :-), irrespectively of whether you are a JAX-WS or JAX-RS developer ?
It might sound so initially but I think it is just the next natural step in the way both frontends can get integrated.

A user who asked a question had developed an optimized XML Stax provider and did not want to rely on JAXB while working with JAX-WS services. So I just went ahead and added a utility JAX-RS DataBinding which can be plugged in into JAX-WS endpoints and which will delegate to custom JAX-RS writers and readers. I used a JAXBElementProvider shipped with the JAX-RS frontend to test this feature. Thus, even though most SOAP developers will unlikely use the feature due to a number of limitations, some of them might go ahead and see if some of the existing JAX-RS XML-aware providers can do something useful for their SOAP applications.

I've just thought about doing SOAP-Atom with Atom payloads being transmitted inside SOAP envelopes and handled by CXF JAX-RS Atom providers. But no, I won't advocate doing the double enveloping (soap:Envelope plus atom:feed) at all even though this feature makes it possible now :-).

Have fun :-)
Categories: Sergey Beryozkin

XMas for hudson users

Olivier Lamy - Fri, 12/24/2010 - 14:00
Done maven3 support branch in hudson has been merged in master : https://github.com/hudson/hudson .
The maven native plugin will now supports maven 3 builds too.

It will be part of the next release 1.392.

Until it's released you will find a build here : http://people.apache.org/~olamy/hudson/main-maven3-support/hudson.war
To test it it's as simple as :
wget http://people.apache.org/~olamy/hudson/main-maven3-support/hudson.war -O hudson.war

So have Fun and nice XMas !!
--
Olivier


Categories: Olivier Lamy

Using gwt sdk 2.1.1 with Gwt Maven Plugin 2.1.0-1

Olivier Lamy - Mon, 12/20/2010 - 11:44
In the last Gwt Maven Plugin, the gwt sdk used is now the one defined in the Maven plugin dependencies.
This means only update your pom dependencies to gwt 2.1.1 won't be enough to compile your project with the last Gwt Sdk version.
To override the Gwt Sdk version used by the Maven plugin, you must add the following configuration :
I'm sure you follow good pratices and have put the version in a property :P

<project>
....
<properties>
<gwt.version>2.1.1</gwt.version>
</properties>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.1.0-1</version>
.....
<dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>${gwt.version}</version>
</dependency>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
</dependency>
</dependencies>
.....
</project>


Have Fun !


Categories: Olivier Lamy

Authentication and Authorization the CXF Way

Sergey Beryozkin - Fri, 12/17/2010 - 14:16
I've been working recently on a number of tests and a demo showing how CXF endpoints can be protected by having consumers relying either on Basic Authentication or WS-Security UsernameTokens authenticated and the authorization rules enforced.

Often enough, when confronted with the problem of making sure the authentication and the authorization works, many users think of using either the J2EE-style authentication (configured via web.xml) or Spring Security.

The former option does not really work with WS-Security and sometimes may not be easy to configure in a fine-grained fashion, besides one may want to defer the role verification until just before the actual invocation occurs. The latter option can let you do it all, given how advanced the Spring Security is. If you're a Spring Security savvy person then wiring it in to secure the endpoints against some arbitrary WS-Security tokens can be a child's play :-) but one have to admit that it might be a bit 'intimidating' sometimes and in some cases Spring is simply not used in a given project. Additionally, making it work in OSGI may present quite a challenge on its own.

The other thing I've heard of is that users dealing with WS-Security may not necessarily want to deal directly with the WSS4J library at the level of their CXF interceptors (by the way, please subscribe to the Colm's blog for more information about WSS4J and other security-related thoughts and updates).

So in the end a number of CXF security interceptors has been introduced to make it as easy as possible for CXF users to secure the endpoints at the authentication and authorization levels.

Additionally, a CXF-specific UsernameToken has been introduced which at the moment encapsulates the information obtained from the WSS4J UsernameToken.
As you can see, it implements the SecurityToken interface with the idea being that more token types will be supported in time. For example, an AbstractSecurityContextInInterceptor converts a token to a CXF SecurityContext instance by delegating to subclasses which know about a current token type, with
AbstractUsernameTokenInterceptor being one such subclass. In the end, say a concrete AbstractUsernameTokenInterceptor implementation only sees CXF UsernameToken which it needs to use somehow for authenticating and populating a current Subject.

The Subject instance will be wrapped in a CXF SecurityContext which will be used later on to do the authorization or further wrapped by JAX-RS or JAX-RS SecurityContext objects and injected into service beans. You may want to use SimplePrincipal and SimpleGroup helpers if needed when creating custom Subjects.

Note that CXF ships two SecurityContext implementations which attempt to figure out which Subject Principals are roles. DefaultSecurityContext assumes Group instances represent primitive or group roles, while RolePrefixSecurityContextImpl find the Principals by checking if their names start from the configurable role prefix, example, from "ROLE_" (this post has some more information).

So far so good - the authentication has been taken care of if you use WS-Security. If you don't them the authentication will occur earlier on at the container entry level, with or without SpringSecurity involved. However, after working on the container-level authentication demo last week it became apparent that CXF needs a utility JAASLoginInterceptor. You only need to tell it the name of the LoginContext to resolve and optionally provide a role prefix name in case Subject does not use Groups to represent the roles. You may also need to override its getCallbackHandler method returning NamePasswordCallbackHandler instances by default, for example, this custom interceptor ensures it can handle Jetty ObjectCallbacks for setting the password.

Another good news is that the JAASLoginInterceptor will work equally well with CXF UsernameTokens (created during WS-Security-related requests) and AuthorizationPolicy capturing Basic or Digest authentication details.

Next we may need to enforce the authorization rules. SimpleAuthorizingInterceptor can be injected with a method names to roles map, while SecureAnnotationsInterceptor takes it one step further and lets users just inject a reference to a secured object and it will figure out how individual methods are supposed to be secured; it checks RolesAllowed annotations by default but one can provide the annotation class name used to specify the roles.
If you have roles stored in say the database then you may want to extend AbstractAuthorizingInterceptor and override its getExpectedRoles method.

If you are securing JAXWS or JAXRS endpoints, you only need to add one or two interceptors, say an optional JAASLoginInterceptor and SimpleAuthorizingInterceptor. When securing JAX-RS endpoints with these interceptors you may also want to add a custom CXF out fault interceptor, for example, like this one, if you want 403 or 401, instead of 500 being returned; alternatively you can let the exception propagate up to the servlet level when possible and deal with the ServletExceptions at the filter levels.

The JAX-RS frontend also ships two utility filters wrapping JAASLoginInterceptor and both authorization interceptors, The one which wraps the JAASLoginInterceptor returns 401 by default and adds a realm name to the WWW-Authenticate response header if needed. It also lets users specify the resource URI where the client needs to be redirected to instead of getting 401. If needed a simple subclass can ensure unrecognized callbacks are dealt with the same way it's done with JAASLoginInterceptor. Here is a sample filter .

Finally, some more information on how to configure the interceptors. Have a look at this beans.xml. The test assumes the authentication is managed by the container, for example, one can configure a Maven Jetty plugin to enforce it. The web.xml requests the authentication only and see how SimpleAuthorizingInterceptor and SecureAnnotationsInterceptor are set up to do the rest - the authorization.

This beans.xml introduces the JAASLoginInterceptor (and the JAX-RS filter) into the picture. I think it would be fare to say it is simple to setup both the JAAS authenticator and the authorization filters in CXF. And guess what - this very configuration can make your application secure without changing a bit in the standalone server, the servlet container and the OSGI container such as Karaf.

The varying part is ensuring the server/container sees the JAAS configuration such as this one (FYI, "BookLogin" is the name injected into JAASLoginInterceptor, while BookLoginModule is wrapping a Jetty PropertyFileLoginModule).

In my test I'm passing a system property "java.auth.security.login.config" to the test server process. In Karaf one needs to deploy a bundle containing the JAAS config. The bottom line is that the issue of bootstrapping the server with this information is an issue of its own.

So what do you do in the end once you set these new CXF interceptors ? You can just relax and see your secure CXF application working like a charm irrespectively of where it is deployed to :-)

Enjoy !



Categories: Sergey Beryozkin

Talend Service Factory Examples

Sergey Beryozkin - Fri, 12/17/2010 - 12:17
As Dan has already mentioned, we have created a number of documented examples which have been tuned to run within the OSGI Karaf container shipped as part of the Talend Service Factory release.

The OSGI container in the release is really an optimized OSGI-aware Web Services stack with only the most relevant bundles being loaded. We've also tried to take care of minor issues such as ensuring that the default HTTP port is 8080 and that the HttpService context is set to "/services" by default as opposed to "/cxf". You can set these initial settings in 30 seconds yourself - but don't you want the demos just to work without having to know how to configure pax web and cxf osgi properties from the very start :-) ?

We have some serious plans to make sure CXF plays really well in OSGI - please keep an eye on the CXF dev list. We will want to make sure the CXF services and indeed the consumers just work in OSGI.

Additionally, most of the examples provide options for starting the services from the command line and within the servlet container.

Next I'd like to actually spend a bit of time and describe what examples we ship. What we have now is some classical CXF examples, such as the one demonstrating all sorts of CXF interceptors in action and additionally prepared to run in the OSGI container. The OSGI-fied example demonstrating SOAP over JMS specification is also there.

Finally we have started closing the gap which has existed in the area of JAX-RS demos and we've added 6 new demos.

Two first demos are called jaxrs-intro and jaxrs-advanced with the idea to show the basic JAX-RS features and then progress to a more involved example, not only showing more sophisticated JAX-RS features but also applying them to solving a reasonably interesting problem, traversing the Person family tree in a number of ways and updating individual Persons. These demos will be regularly updated.

The next 2 demos, jaxrs-jaxws-java-first and jaxrs-jaxws-description-first show how SOAP and RESTful services can be combined.
The first one shows how both JAX-WS and JAX-RS annotations can be combined on a single interface, how endpoints can share the same service bean and how both JAX-WS and CXF JAX-RS proxies can effectively use the same code for invoking on the services. The second one shows how SOAP services developed using a WSDL-first approach can be selectively exposed as RESTful services by applying an external CXF-JAXRS user model giving that modifying the interface generated from WSDL is not an option.

What we actually want to show with these 2 demos is that making this experience as seamless as possible is a top priority for us - we do want users to really like developing both SOAP and RESTful services with CXF.

The next demo, jaxrs-jms-http, shows how a typical JAX-RS HTTP server can be enhanced to receive the JMS messages with just adding few extra lines to the configuration. As noted here, you may want to do it if you'd like to preserve your investment in the JAX-RS but also make sure the service is capable of getting the messages from a variety of (transport) channels. This demo also shows how HTTP requests can be processed oneway with the server picking up the messages and forwarding them further to the JMS destination.

The last example is jaxrs-jaxws-authorization. This example shows CXF authentication and authorization interceptors in action, authenticating the users via JAAS and populating the CXF SecurityContext with Principal and its roles, and then enforcing the authorization rules for both JAX-WS and JAX-RS endpoints. The JAAS interceptor is only used when the demo is run within Karaf so that the Karaf JAAS context can be resolved. When the demo is deployed into the servlet container, the container-managed authentication is utilized to populate the current Principal.

This demo will be significantly simplified in the next release due to the recent related CXF enhancements (the topic of the next post).

You'll see many more examples added in time.

So please download the examples and give them a try. Note, you have to register in order to download the examples, this is due to the fact the examples content in general is considered to be a premium content at Talend, hopefully it won't be a problem for those who are interested.
Categories: Sergey Beryozkin

Change the world and go home

Sergey Beryozkin - Fri, 12/17/2010 - 11:38
I recall I was reading the Change the world or go home post from Dare Obasanjo and being a bit confused not about the content (which was interesting and thought provoking as usual) but about the 'or' bit in the subject.

I was asking myself, would it make sense to say "Change the world *and* go home" :-) ? I believe all of us working with the Open Source are changing the world every day, then we go home in the end of the day, and then we are back at it the next day, changing the world with our individual contributions, negligible in the scope of the big picture.

Of course, "or" had the meaning in the Dare's post. But I kind of like 'and' more :-)
Categories: Sergey Beryozkin

Fast update with groovy to use maven 3.0 in Hudson

Olivier Lamy - Wed, 12/15/2010 - 15:18
As you are an early adopter and want to try the maven3 native support branch in hudson.
See previous blog entry Maven 3 support in Hudson Maven Plugin
If you have a maven installation called maven-3.0, just run the simple groovy script in your console :

prjs = hudson.model.Hudson.getInstance().getItems( hudson.maven.MavenModuleSet.class );
prjs.each{module -> println(module.maven= "maven-3.0")}

And that's it all your maven native plugin hudson jobs will use your maven installation called maven-3.0 .


Categories: Olivier Lamy

Maven 3 support in Hudson Maven Plugin

Olivier Lamy - Mon, 12/13/2010 - 23:39
You have developped hudson plugins using the maven-plugin or you are an early adopter user : so this blog entry is for you !

Some stuff has been done in a branch called main-maven3-support [1] in github to support maven 3 in the Hudson native maven plugin.
The plugin now supports both maven 2 and maven 3.
Note the pom parsing to detect modules now use the maven 3 apis. (ProjectBuilder maven component [2])
You don't have something to install (just choose the maven version for your maven build) the plugin will detect which maven version is used for the maven build and use differents implementation to "listen" the build.

To test it, you can build it .
First build the embedder (note this will move to github soon)

svn co https://svn.java.net/svn/hudson~svn/trunk/hudson/lib/hudson-maven-embedder
cd hudson-maven-embedder
mvn clean install -DskipTests

Then build hudson from the branch

git clone https://github.com/hudson/hudson.git
git checkout main-maven3-support
mvn clean install -DskipTests

And hudson.war is in war/target/hudson.war

I have pushed builds here : http://olamy.googlecode.com/files/hudson.war

Currently : maven2 build on master node doesn't work (under work !)

We need you for more testing and nice feedback (before merging this to master)

You can follow what's happened in the dedicated jira entry : http://issues.hudson-ci.org/browse/HUDSON-4988

Have Fun !
--
Olivier

[1] https://github.com/hudson/hudson/commits/main-maven3-support
[2] http://maven.apache.org/ref/3.0.1/maven-core/apidocs/org/apache/maven/project/ProjectBuilder.html


Categories: Olivier Lamy

Gwt Maven Plugin 2.1.0-1 Released

Olivier Lamy - Mon, 12/06/2010 - 21:31
The Gwt Maven Plugin 2.1.0-1 has been released.

38 issues has been fixed (full changelog).

New features :

* AppEngine Launch
* Css Interface Generator
* More Gwt compiler options : -compileReport, -optimize, -XsoycDetailed, -strict (see the mojo Compile Mojo)
* Compiler Report
* @RemoteServiceRelativePath annotation processing

To use it :

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.1.0-1</version>
</plugin>


Web Site : http://mojo.codehaus.org/gwt-maven-plugin/

Have Fun !
--
Olivier


Categories: Olivier Lamy

Gwt Maven Plugin 2.1.0-1 Staged

Olivier Lamy - Fri, 12/03/2010 - 16:19
Yeah ! The Gwt Maven Plugin 2.1.0-1 has been staged (and release vote started [1] )

Release Notes : http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11860&version=16878

Staging repo : https://nexus.codehaus.org/content/repositories/orgcodehausmojo-047/

Documentation site : http://mojo.codehaus.org/gwt-maven-plugin

What's new in this release : http://mojo.codehaus.org/gwt-maven-plugin/whats_new.html

If you have any trouble please load an issue in jira : http://jira.codehaus.org/browse/MGWT .

Have Fun and push a +1 !

[1] http://goo.gl/DeJue


Categories: Olivier Lamy

What's new in the coming Gwt Maven Plugin 2.1.1

Olivier Lamy - Fri, 11/26/2010 - 18:52
The coming Gwt Maven Plugin 2.1.1 will have new features.

This stuff is currently available as 2.1.1-SNAPSHOT in the codehaus repo : https://nexus.codehaus.org/content/groups/snapshots-group/

Running your application in debug mode with AppEngine Launcher

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.1.1-SNAPSHOT</version>
<configuration>
<server>com.google.appengine.tools.development.gwt.AppEngineLauncher</server>
</configuration>
</plugin>
</plugins>
</build>


See appengine-launcher

Css Interface Generator

See Css Interface Generator

More Gwt compiler options
-compileReport, -optimize, -XsoycDetailed, -strict (see Documentation )

Compiler Report
To have link to the Gwt compiler report in your Maven generated web site
See Compiler Report

Full changelog

Do not hesitate to test and send feedback.
Thanks !


Categories: Olivier Lamy

Sopera opens the development center in Ireland

Sergey Beryozkin - Thu, 11/18/2010 - 11:13
Last week myself and my colleague Colm stepped in into an office that Sopera secured for us in Dublin, Ballsbridge. We can nearly see the IONA Building we used to go to not that long ago from our place. The view from its window is really nice.

We are delighted. Being able to get to the office and work with and talk to your colleagues but also work from home on a given day is the ideal situation for software engineers and it really does feel it is the beginning of the new journey for us, with the only way ahead from here - onwards, especially now that Sopera has been acquired by Talend.
Categories: Sergey Beryozkin

Pages

Subscribe to Talend Community Coders aggregator