As part of the Eclipse Live series of webinars, Sonatype software developer Pascal Rapicault is giving a presentation on Tycho: Building Eclipse plugins with Maven.

About the webinar:

Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGI bundles with Maven. Eclipse plugins and OSGI bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. Tycho supports bundles, fragments, features, update site projects and RCP applications. Tycho also knows how to run JUnit test plugins using OSGi runtime and there is also support for sharing build results using Maven artifact repositories.

Join this webinar to get an overview of the Tycho project and to learn what plans the project has for the future.

• Date: May 3, 2011
• Time: 9:00 am PST / 12:00 pm EST / 4:00 pm UTC / 6:00 pm CET
• Length: 60 minutes
• Enroll here!

Another year of great talks and Eclipse workshops are just around the corner!

EclipseCon 2011 is being held in Santa Clara, California from March 21 – 24.

As a Strategic Member of the Eclipse Foundation and as a proud Gold Sponsor, Sonatype is looking forward to another year of great talks, tutorials and BOF’s at EclipseCon 2011. Sonatype technical leaders will host a number of sponsored talks on Tuesday, March 22 in the Cypress Room. Topics we will cover include: Next Generation Development Infrastructure, Hudson Continuous Integration, Tycho Build Conversion, Discovering p2 API’s, Maven 3 and many more.

Check out the full lineup of presentations here.

We hope to see you there! But if you can’t make it, get all of the conference updates from the Sonatype team on Twitter by following the hashtag #EclipseCon.

Event Details:

• Date: March 21-24, 2011
• Location: Hyatt Regency Santa Clara, CA
• Event Website: http://www.eclipsecon.org/2011/

Join Sonatype’s Jason van Zyl, Pascal Rapicault, and Igor Fedorenko at EclipseCon 2011 for a two-hour workshop on Tycho build conversion.

This tutorial picks up where their morning tutorial Building Eclipse plugins and RCP applications with Tycho, Nexus & Hudson leaves off. If you’re planning on attending EclipseCon 2011, drop by and get hands on Tycho help from the Sonatype team!

For more on Sonatype at EclipseCon, click here.

For the latest news and updates from the Sonatype team, follow us on Twitter!

The schedule for EclipseCon 2011 has been announced, and the Sonatype team is excited to host talks and workshops throughout the week.

Sonatype’s Jason van Zyl, Pascal Rapicault, and Igor Fedorenko, along with Jan Sievers from SAP AG, are holding a three-hour workshop on building Eclipse plugins and RCP applications with Tycho, Nexus and Hudson.

Build automation and continuous integration are central to the production of quality enterprise software. Without automation it is often difficult to keep track of defects and communicate build status. One of the goals of the Maven project is to bring efficient build automation to enterprise development, and as more organizations start to develop Eclipse plugins and RCP applications, there is a greater need for Maven to interoperate with the Eclipse platform. This tutorial will provide first hand experience in how to use Tycho, Nexus & Hudson to build Eclipse plugins and RCP applications.

To learn more about Sonatype at EclipseCon 2011, click here.

For the latest news and updates follow Sonatype on Twitter!

On Wednesday night, members of the Sonatype team will be giving presentations on Tycho and Developer Onboarding at the Ottawa Eclipse DemoCamp.  We hope to see you there!

A DemoCamp is an informal event for a group of Eclipse enthusiasts to meet up and demo what they are doing with Eclipse. Eclipse DemoCamps are an opportunity to showcase all of the cool technology being built by the Eclipse community. They are also an opportunity for you to meet Eclipse enthusiasts in your city.

Location:

Clocktower Brew Pub 575 Bank St.

Date and Time:

November 17, 2010 7:00pm – 10:00pm ET

The Open Source aficionados at Red Hat are hosting an Eclipse DemoCamp in Toronto, Ontario on Tuesday June 29.  Red Hat works to bridge between the communities that create open source software and the enterprise customers who use it. They make the rapid innovation of open source technology consumable in mission-critical, enterprise environments.

Sonatype is also committed to fostering growth and innovation within the open source community.  Recently Andrew Overholt from Red Hat attended the Sonatype and Eclipse Maven Meetup in Guelph, Ontario.  And this Tuesday Sonatype’s Jason van Zyl will attend the Red Hat hosted Eclipse DemoCamp.  Jason will give a presentation on m2eclipse and Tycho.

The DemoCamp takes place on Tuesday June 29 at 6:30pm.  The event takes place at 2323 Yonge Street, Suite 300 Toronto.

To register for this event as an attendee please click here.

View Larger Map

Sonatype is hosting a Maven Meetup in downtown Philadelphia Wednesday April 7, 2010.  Presentations will cover Maven 3.0, Nexus, Hudson, Tycho, m2eclsipse, and more.  There are still a few seats left, so visit www.sonatype.com/meetup2010 to register.

And on Tuesday April 6, Sonatype’s Jason van Zyl will be the guest speaker at the Philly Java User Group meeting, discussing Maven Stack.  This talk focuses on the Maven Ecosystem and the under-pinnings of technologies that are going to shape the Next Generation Maven Development Stack.

Join us in Philadelphia at the Sheraton Society Hill, ahead of Emerging Technologies for the Enterprise April 8-9, 2010.

April 7, 2010 Sonatype is hosting a Maven Meetup in downtown Philadelphia ahead of Emerging Technology for the Enterprise.  Take part in presentations given by the developers who are building the Maven software you will be using in the future.  Registration is filling up fast, there are only a few seats left.  Learn about Apache Maven, Hudson, Nexus, Sonar, Felix, OSGi, Tycho, Selenium, and more.  Visit www.sonatype.com/meetup2010 for more information about presentations and registration.

Maven Meetup April 7, 2010 8:00 AM – 5:00 PM Sheraton Society Hill (downtown) Philadephia, PA

Choose from a range of sessions presented by the Maven developers.  Sessions will include:

• Maven in the Enterprise
• Git, JGit & EGit
• OSGi Runtimes
• OSGi Provisioning with P2
• Nexus
• Moving from Plexus to Guice
• Hudson
• Tycho: Enterprise OSGI Builds
• m2eclipse
• Selenium
• Peaberry
• Nexus & OSGi

Join us for an interactive BoF session at the end of the day, followed by a reception where you’ll get to spend time in casual discussions.

20% Discount

Register by Monday April 5th and receive a 20% discount on the the $190 standard registration rate. Visit www.sonatype.com/meetup2010 to register or for more information. Register using the code PJUG20 to receive your discount.

Bring a Colleague for Free

Register one attendee by Monday April 5th at the $190 standard registration rate, and have a colleague join you at no charge. Visit www.sonatype.com/meetup2010 to register or for more information. When you register, add “+1” after your name to receive the special promotion pricing for you and a friend.

Seating is limited

Recently, I was asked to do an interview for EclipseMagazine about the future of Maven and release of Maven 3.0.  JAXenter published part one and two of the interview over two weeks.  Below is the full interview, which covers everything from changes Maven 2 users can expect when migrating to Maven 3, Nexus repository manager, the Maven Shell, Polyglot Maven, and more.

With the switch from Maven 1.x to 2, developers had to manage some fundamental changes. What challenges can users expect when migrating from Maven 2 to Maven 3?

We are planning that, in most cases, Maven 3.0 will be a drop-in replacement for Maven 2.x. We have gone to great lengths to ensure backward compatibility while reimplementing a good portion of Maven’s internals. From the command-line perspective we are trying to be fully compatible. Maven 3.0 will not allow duplicate dependency or plugin declarations, so those problems would need to be fixed, but aside from that no changes to your POMs will be required. In all other regards we have created backward compatibility layers to protect users from the many internal API changes that we have made. I really hope that the Maven community can move forward to Maven 3.0 without grief, and use the new features as it is convenient for them.

Is there anything users should keep in mind when creating a new project, to be prepared for Maven 3?

It honestly shouldn’t be any different from Maven 2.0. That’s the intended goal. So much has changed under the covers that we didn’t want to change the POM format. The primary goal is a path forward for all Maven users, efficient embedding, increased performance, synchronizing the Maven 3.0 code base with m2eclipse, and adding extension points for tools like Tycho, Polyglot Maven, and the Maven Shell.

Will Maven 3 support the integration of dynamic languages (e.g Groovy)?

It would be more accurate to say that Maven 3.x can support dynamic languages. This will not be directly available in the Maven 3.0 release, but support for dynamic languages is available now in Sonatype’s Polyglot Maven project which you can find at http://polyglot.sonatype.org. You also have a question below specifically about Polyglot Maven below so I’ll expand on Polyglot Maven there.

Will there still be a settings.xml or can we expect another method of configuration in Maven 3?

In Maven 3.0 we are again not attempting to change the models that users are accustom to. Internally in Maven 3.1 we will expose a security manager and use the settings.xml implementation as the default implementation, but Sonatype is planning on creating an implementation that interacts with Nexus, our repository manager. In dealing with many large organizations we have found that integrating with in-house security systems and custom implementations is necessary so we will be providing an extension point for this with the security manager.

In Maven 3.1 we will also introduce POM mixins to help make configuration more maintainable and portable. One of the frequent complaints with Maven 2.0 is that sharing configuration can only be done via inheritance. This is obviously problematic as not all projects within organizations, and certainly not all projects in OSS, share lineage. POM mixins are a form of POM composition where a parameterized fragment of a POM can be injected into the current POM with a simple reference.

For me, the first mixin that I wanted to create was a mixin to encapsulate a standard release capability for Maven projects. Apache projects that use Maven inherit the Apache POM, which contains configuration for our release process.  This incorporates license attribution, PGP signing, staging and promotion with Nexus, an Apache compliant source archive containing the original project structure, and the production of the standard source and javadoc JARs. I wanted to create a very easy way for any project to incorporate this capability in their project. The release mixin consists of plugin declarations, their configuration which can be parameterized, and a specification of what POM elements are required in the target POM for the mixin to operate correctly. The POM mixins can then be deployed to a remote Maven repository to be shared via a standard Maven coordinate. In the target POM you specify the coordinate of the POM mixin along with any parameters required by the POM mixing, and Maven will retrieve the POM mixin and inject it into the target POM.

What I expect to see are projects in the community creating mixins for capabilities that require the interaction of many plugins along with the accompanying configuration. One of the biggest problems in Maven, given it’s distributed nature and there being so many plugins, is finding the right plugins that work together and figuring out how to configure a set of plugins to arrive at the desired result. The POM mixins will remove much of this pain.

Can you tell us a bit about Nexus?

I’m going to let Brian Fox, Nexus lead and Maven PMC Chair, answer this one.

Nexus is a repository manager built by the Maven experts at Sonatype. Repository managers serve a few of purposes in an organization: they act as highly configurable caching proxies for remote repositories, and they provide a centralized location to deploy, store, index and share all your internal artifacts. We use the analogy that a repository manager are to binaries what a source control management systems are to sources. In both cases you can use a flat file system but quickly learn that this isn’t scalable.

Nexus is unique among repository managers for several reasons. First, it is designed to be light on resources and heavy on performance. Second, the data is stored in the native repository layout on disk, which ensures that traditional backup and synchronization tools can be used. You don’t need to be a DBA to get access to your artifacts. Third, Nexus supports many repository formats and can convert on the fly between them: Maven 1, Maven 2, OSGI Bundle Repository (OBR), P2, RubyGems. The community is even working on RPM support.

Nexus is the preferred choice for the largest repositories in the community such as Apache, Codehaus, Jboss, Atlassian, Glassfish and many others. It is available in two flavors: an open source version http://nexus.sonatype.org and a professional version that extends the open source version http://www.sonatype.com/products/nexus with commercial add ons, to further manage the binary lifecycle in enterprise organizations.

In the Maven Repository, there are all kinds of plug-ins, ranging from early Alpha-Versions to stable plug-ins. Do you have any plans for bringing order to this “plug-in chaos”? One could imagine a similar process to Eclipse, with Incubators and a Simultaneous Release Train providing reliable, high quality plug-ins…..

This is something that Sonatype plans to tackle in the near future where we provide a higher quality set of plugins. Maven, by it’s distributed nature, makes it pretty hard for us to guarantee the quality of Maven plug-ins in every Maven repository around the world and what ultimately lands in Maven Central. But what we can do is “battle test” a smaller set of plug-ins and make sure they have integration tests, perform well, and integrate properly with m2eclipse. Once Maven 3.0, m2eclipse 1.0, and Tycho 1.0 are released we plan to start this project.

Sonatype have just released version 0.10.0 of their m2eclipse Maven Plug-in for Eclipse. What new features does 0.10.0 have to offer? And will version 1.0 bring major changes?

m2eclipse 0.10.0 is almost a complete rewrite from 0.9.8 so there are many changes and improvements. The most important aspect is that we have the m2eclipse code base synchronized with the Maven 3.x code base. When we need fixes in m2eclipse that are the result of problems in Maven, it’s only a matter of hours before we can roll a fix through the system and produce a new m2eclipse build. There have been several hundred fixes across Maven and m2eclipse in the last year. We’ve probably put in close to eight thousand man hours across Maven and m2eclipse as we approach the Maven 3.0 and m2eclipse 1.0 releases.

The performance will be the first thing users notice. Even with a standard Maven project general operation is faster, but if you leverage the new incremental Maven Plugin API and the customizable lifecycle mapping you truly have incremental behavior with Maven inside of Eclipse.

The new incremental Maven Plugin APIs allow Eclipse to communicate very precise information back to Maven. For example, if you change a single resource that needs to be filtered, Eclipse will no longer trigger Maven’s entire lifecycle, but rather communicate the information about the single file that has changed and execute Maven’s resource plugin to operate on the single file that changed. The customizable lifecycle mapping allows m2eclipse to eliminate most of Maven’s execution from within Eclipse. You can selectively choose what plugins you want to execute as part of the build within Eclipse. The end result is that if you tune your project, you can get extremely fast results. We want to make this tuning easier as we move toward the 1.0, but it’s still relatively easy to do this today.

We also have improved integration with Nexus so you can search the content of your repositories from within Eclipse, and we have simplified the configuration of repository indexes by automatically configuring them based on repositories you have configured in your settings.xml file.

There’s already an official Eclipse project for integrating Maven: IAM (formerly ‘Q4E’). What’s the difference between m2eclipse and IAM? And is a merger of the two projects conceivable?

IAM is not the official project for integrating Maven. Both m2eclipse and IAM are in incubation, so neither has official status at Eclipse. It’s unlikely there will be a merger. The IAM code base is a year behind m2eclipse at this point, and there are no active Maven 3.x committers on the IAM team. Sonatype has full-time developers and QA staff on Maven 3.x and m2eclipse. We’ve done a lot of work over the last year to make sure Maven and Eclipse work well together. m2eclipse is the de facto standard. You can see this in the community as questions on the user mailing lists are always about m2eclipse, and vendor support is already in place for m2eclipse – Genuitec, JBoss, and SpringSource all integrate m2eclipse, not IAM. Eclipse may ultimately let both projects graduate from incubation, but only one project will be official and shipped with distributions, and it very likely that will be m2eclipse. It simply boils down to manpower. We always hope for community support, but at any given time Sonatype has up to eight full-time people working on m2eclipse so users can be assured bugs will be fixed and new features will be developed.

Can you tell us a bit about the P2 project at Eclipse and how Sonatype has become involved with the P2 project.

The P2 project at Eclipse is the basis of the update manager in Eclipse, but it is also a general purpose provisioning framework. Sonatype is interested in provisioning user desktops, provisioning development infrastructures, and provisioning production run-times. P2 has become a critical technology for Sonatype, so we recently hired Pascal Rapicault who is the lead of the P2 project at Eclipse. Pascal will remain heavily involved in the community, in much the same way that Sonatype is heavily involved in the Maven community. We are also planning to invest in some research and collaborate with Daniel Le Berre through the National Centre for Scientific Research in France. Daniel is the creator of SAT4J, which is the core solver used in P2 for determining the selection of dependencies. I am interested in trying to merge the artifact resolution strategies of Maven and P2.

Maven Tycho is your new OSGi-Toolchain designed to be a drop-in replacement for the Eclipse PDE Build. What are the goals of the Tycho project? And what features are already available?

The focus of Tycho is to create an effective hybrid of Maven and Eclipse-based OSGi technologies for building, publishing, and distributing Eclipse plugins, update sites, RCP applications and OSGi bundles. Tycho is a manifest-first approach to building and leverages Eclipse’s Equinox, JDT and P2 projects. The alternate approach is a POM-first approach which is the strategy employed by the Maven Bundle Plugin which uses Peter Krien’s BND tool to generate a manifest from the classes post build.

Both of these approaches will be with us for quite a while, so another goal of Tycho is to allow these different approaches to interoperate. Both approaches produce bundles, but in order to use Tycho the bundles must be available in a P2 repository and have the accompanying P2 metadata. So with a POM-first approach we dynamically generate the required P2 metadata for bundles that do not have it. This effectively allows us to take all bundles available in Maven Central and allow them to be used within Tycho. I believe that an unmanageable rift will form if tools are not capable of interoperability between these two common forms of development. Many people use Maven only to produce bundles, and many people use standard Eclipse-based technologies to produce bundles, and if these worlds are not united there will be a massive duplication of effort. Tycho is a bridge between these two worlds.

We have also integrated Tycho with m2eclipse so that you can import a Tycho project into Eclipse as a PDE project. We have also added support to allow the resolution of POM-first bundles in the Eclipse workspace. Currently there are two major projects at Eclipse that are using Tycho to build: the Tigerstripe project driven by Cisco, and the EGit project. The EGit project is interesting because it uses the hybrid approach of using a POM-first build for JGit, we then generate a P2 repository from the Tycho build which is then consumed by the EGit build which uses a manifest-first Tycho build.

Can you tell us a bit about Polyglot Maven?

Polyglot Maven is the project for experimenting with domain specific lanaguages (DSLs) and terse markup languages (TSLs) in conjuction with Maven 3.x’s core. What is currently available today can be found http://polyglot.sonatype.org. What we have are starting points of internal DSLs for Groovy, Ruby, Scala, and Clojure. There is also an external DSL that I have developed using XText, which is a fantastic tool at Eclipse.org for creating parsers and editors for external DSLs.  We are also providing support for YAML-based POMs using the excellent SnakeYAML library.

The DSLs are meant to be more then merely different representations of the POM. The DSLs will have full access to Maven’s internals, which have been redesigned for integration and extension. What this means in practical terms is that implementors of DSLs can leverage Maven’s infrastructure but create custom ways to interact with, or extend, Maven. A DSL could change Maven’s lifecycle, decorate lifecycle phases, create new configuration mechanisms, or allow a more procedural mechanism for their users. I honestly don’t know how useful these features are for general users, and more specifically enterprise users, but I only see benefits in allowing greater leverage of Maven’s infrastructure.

What I really care about and what really concerns me is interoperability at the repository level and tooling. This is why the code lives in the Polyglot Maven project. I don’t want to misrepresent to users that this is ready for prime time. It fully works, but there needs to be more thought about how projects being constructed with possibly many DSLs can still play nicely together. What will the resultant metadata look like that is exported to Maven repositories? Currently we feel that this is likely to be a Maven 2.x POM created during the deployment process. What will the tooling look like for Maven DSLs? We are hoping that the DSLs can preserve many of Maven’s internal models so that they can leverage m2eclipse. To simply provide the infrastructure for these DSLs is not enough; repository interoperability and tooling is important.

In the last 18 months I have surveyed nearly 2000 people from the various talks and presentation I’ve given, and approximately 5% of the people surveyed are interested in DSLs for Maven or different representations of the POM. But these 5% are very important. These are the very creative hackers that want to do things in a project from one end to the other in a fully programmatic way. They want to code everything including the build. This is why I created Polyglot Maven because I believe this 5% can potentially contribute as much to Maven as the remaining 95% of the Maven user base. The folks who want the polyglot support are highly effective people. In the end it’s all good for Maven.

Can you tell us a bit about the Maven Shell?

The Maven Shell is Maven embedded in a long-lived shell process. The shell avoids the start-up costs of invoking Maven repeatedly, caches the parsed POMs, provides Maven Archetype integration, provides Nexus integration, has a built in help system, and on the OS X provides Growl support. In typical cases you’ll see your build times cut in half. We have many features planned for the 1.0, such as the integration of the make-like reactor mode so that within the shell only the modules that have changed will be built, project workflow support to help guide users do the right thing, Hudson support for creating jobs and querying statuses, and ultimately the integration of Tycho and Polyglot Maven features.

There are many different build systems to choose from. In your opinion, which is Maven’s biggest competitor? Maybe Gradle…..?

Maven’s biggest competitor in the enterprise are homegrown Maven-like solutions created with Ant. These are the systems that Maven typically replaces in enterprise settings. We honestly don’t see anyone trying things like Gradle or Buildr for large enterprise projects. I think there is a lot of hype around some of these technologies. We understand that people are constantly looking for new solutions, but we’re also convinced that the enterprise build space is full of complicating factors that don’t lend themselves to over-simplification.

In three sentences: Why should we switch to Maven 3?

Maven 3.0 will be the best version of Maven ever made. We are doing everything in our power to make it backward compatible and we have put in thousands of man hours in testing and performance tuning. Maven 3.0 is the future of Maven and the path forward for all users who wish to use new technologies like m2eclipse, Tycho, the Maven Shell, Polyglot Maven, and Nexus.

And is there a release date?

We are planning for the Maven 3.0-beta-1 around the beginning of April, and based on feedback and good weather permitting we will release Maven 3.0 at the beginning of May.

It’s not too late to register for the Sonatype Maven Meetup taking place on April 7, 2010 ahead of Emerging Technologies for the Enterprise in Philadelphia.  Meet with Maven aficionados, sit in on presentations about Maven 3, Tycho, OSGi, Peaberry, and much more.

Choose from a dozen different sessions throughout the day, presented by the developers who are building the Maven software you’ll be using in the future.  Join us for an interactive BoF session at the end of the day, followed by a reception.

Special Promotion — Bring a Friend for Free

Register one attendee at the $190 standard registration rate, and have a friend join you at no charge.

Visit www.sonatype.com/meetup2010 to register or for more information.  When you register, add “+1″ after your name to receive the special promotion pricing for you and a friend.

Seating is limited