Looking forward to getting my hands dirty.
Alex
On Wed, Aug 20, 2008 at 3:44 PM, Igor Fedorenko <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello, Alexandre and others.
First of all, I have to apologize for keeping Tycho development
plans and progress to myself. I would like to thank you for bringing
this up and will try to both explain our grand vision and what we
already have or will have implemented in the near future.
The big picture. Ultimately, we want tycho to be one-stop solution
for doing Eclipse and OSGi development with Maven 2 (actually, 3,
more on this later). We believe there are two distinct development
workflows, when developer explicitly creates and maintains OSGi
manifest and other Eclipse/OSGi metadata (we call it
"manifest-first") and when OSGi metadata is generated by the build
based on information available from pom.xml ("pom-first",
naturally). We plan to support both development workflows.
In manifest-first mode, tycho will use Eclipse/OSGi metadata and
OSGi rules to calculate project dependencies dynamically, at build
time. It will support all attributes supported by Eclipse OSGi
resolver (Require-Bundle, Import-Package, Eclipse-GenericRequire,
etc). It will use proper classpath access rules during compilation.
It will support all projects supported by PDE and will use PDE/JDT
project metadata where applicable. One important design goal is to
make sure there is no duplication of metadata between pom.xml files
and Eclipse/OSGi config files. In fact, tycho will support
"pom-less" projects, where all required build metadata is derived
from Eclipse/OSGi config files.
In pom-first mode current plan is to provide similar set of features
as in felix/bnd plugin, although I do not know if we'll be able to
share any of the code. Additionally, Tycho will support
Eclipse-friendlier Require-Bundle and will provide better support
for developing multiple related OSGi bundles (I have not checked
recently, so felix/bnd may already support these).
In both modes tycho will support remote repositories both as source
and sink for artifacts. We plan to support maven repositories, p2
and update sites, although level of support will likely vary. There
will also be integration between m2e, tycho and pde to make the
three work nicely together.
So these are the plans... Disclaimer: plans do change! ;-)
Now to what tycho is already able to do. Our first goal was to
enable m2e continues build, so we started with manifest-first mode
and I believe covered most of manifest-first features described
above. Tycho already uses Eclipse/OSGi metadata to resolve project
dependencies by OSGi rules and injects these dependencies into maven
project model dynamically, at build time. It supports bundle,
fragment, feature and update site projects (shame on me, but no RCP
application yet). It knows how to run junit test plugins using OSGi
runtime. Two big features that are still missing, are support for
pom-less projects and work with artifact repositories, although
there is prototype of target platform materialization from p2
repository already. There is also some rudimentary implementation of
pom-first mode, but its usability outside of m2e build context is
probably limited. Many smaller features are still missing and I am
certain there are quite a few bugs too, but I think overall tycho
code is in reasonably good shape already.
Few words about relationship between maven and tycho. Tycho is not
morphing into maven, but it provides maven extensions and plugins
that enable maven to work with Eclipse/OSGi projects. Some of tycho
functionality, especially OSGi dependency injection, relies on maven
features only available in maven 3.0 which was very recently renamed
from 2.1. Since there is no maven 3.0 release yet, current tycho
distribution includes complete copy of maven 3.0-SNAPSHOT.
As for contributing to the project... well, this would be really
awesome . I think the best way to start is to try tycho and see what
is missing to support your projects and development workflow. Then
we can work together to implement missing features, fix bugs, etc. I
have simple demo that shows how to use tycho to build set of simple
projects and some user-level documentation. I will try to make this
available later today. I will also provide tycho dev env setup
steps, so you can start looking at the code if you want to. And
tycho distribution is already available from [1] (looks for the
latest .zip file)
I hope it answers your questions, but feel free to ask more,
especially if something is not clear or does not make sense.
--
Regards,
Igor Fedorenko
[1]
http://repository.sonatype.org/service/local/repositories/eclipse-snapshots/content/org/codehaus/tycho/tycho-distribution/0.3.0-SNAPSHOT/
Alexandre Sauvé wrote:
Hi,
My company has been using Maven 1 for a couple of years now and
we are looking to make the transition over to the Maven 2 world
(waiting for the best opportunity)! The UI for most of our
applications are RCP based. The build process for the UI is
using the PDE and is completely autonomous from our middle tier
build with Maven. We are hoping that with the transition to
Maven 2 there would be some new functionality to allow for
RCP/OSGi development. Unfortunately we have found that we may
not have waited long enough! There have been several options
that we have looked at to obtain bridge Maven and our Eclipse
Development:
* *Building Eclipse Plugins with Maven 2
(http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html)*
<http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-Maven2/index.html%29*>
In this articles the authors describe in detail how they
integrated Maven2 and Eclipse. One aspect of their
approach that
I did like was how they made use of the manifest file to
define
the dependencies for the project (similar to how Eclipse
works);
however they need to use the 'Required-Bundle' tags rather
than
the improved 'Import-Packages'. Though well documented this
approach wasn't favoured as it did not offer the Mojos
re-built in
a repo (they just offer the code for the Mojos but they
don't make
their Mojos available) and the article was written in 2006.
The
company, Princeton software, was bought by IBM so it is hard
to
get a hold of the developers for the project.
* *CodeHaus Maven PDE plugin
(http://mojo.codehaus.org/pde-maven-plugin)*
<http://mojo.codehaus.org/pde-maven-plugin%29*> This Mojo
triggers
the PDE build from Maven. Though this approach would be
fairly
straight forward in that the regular PDE mechanism can be
used for
building the RCP application there are several drawbacks we
see
related to the build occuring in 2 seperate build
technologies:
PDE doesn't offer any way to easily integrate Maven 2 report
tooling into its build process (checkstyle, code coverage,
ect.)
PDE is another technology for our developers to learn (more
Ant
based build cycle)
* *Felix Bundle Plugin for Maven
(http://felix.apache.org/site/mavem-bundle-plugin-bnd.html)*
<http://felix.apache.org/site/mavem-bundle-plugin-bnd.html%29*>
This
Mojo is based on the BND tooling. In this approach all the
dependencies are specified in the POM and manifest is
generated
during the package lifecycle in Maven. There are specific
commands to provide the 'Export-Package',
'Private-Package', etc. However the BND tooling will
analyze the byte code to determine
some information such as the 'Import-Packages'. Though this
tooling works well for generating OSGi bundles it does not
leverage the tooling available in Eclipse. Once you have
your
plugin working with its dependencies in Eclipse you then
need to
rework your POM to ensure that the manifest that is
generated is
equivalent to that which you now have in Eclipse. This is
not
always a trivial process. Given that limitation this is the
process that is favoured at the moment. Some pros about
this
methodology:
+ What is nice about this approach is that everything is
done in
Maven allowing you to now hook all the Maven reporting
plugins.
+ Leverage Maven 2 Repo for your dependent bundles (note
that your
bundles cannot be of the format of a jar within the bundle
- they
have to be more like regular jars to be used by Maven)
+ Generate target platform in Maven
However after reading the article 'Jason Van Zyl Discusses
Sonatype, The Eclipse Foundation and Maven'
(http://www.infoq.com/news/2008/08/van-zyl-eclipse-sonatype-maven)
we believe that Tycho seems to be the up and coming solution to
bridging the world of OSGi and Maven. So I have done some
research into Tycho and have some questions:
* At the beginning of the Tycho development it was a set of
plugins
to provide building with the PDE compiler (as it
understands the
whole OSGi dependency/class loading issues), 'osgi-bundle'
lifecycle, generation of POM, etc. Now it seems to have
morphed
into Maven 2.1? Is Tycho and M2Eclipse the basis of the
development for Maven 2.1?
* Will the new version be able to do everything with the
manifest
that Maven 2.0 does with the POM? Through the manifest be
able to
tell what dependencies are required? What if those
dependencies
are only through Import-Packages (with a version to make
life
easier)? Will the integration with the p2 enable M2Eclipse
to
determine which bundles supply a given package and add the
required dependencie between the projects?
* Will the p2 integration be on top of the existing Maven
repo or a
seperate repo to get bundles from?
* What is the timeline/gameplan for Tycho development at this
point?
So as you can see we are really just starting out down this
path. We would be willing to help with development if we find
an area that we can contribute effectively into the project.
However as of right now we just want a starting point to start
getting our projects configured to using Tycho. Could you point
us in the right direction? The ReadMe file in the release now
is the one for the Apache Maven, so it doesn't really help with
the configuration of a project using Tycho. Is it the same
configuration as before? Should we be using a different version
(previous version than 0.3.0)?
Thanks, Any help you can give would be appreciated!
Alex
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
