I am going to be a bit of a broken record here.  I would tend to agree
strongly with James.  The workflow that I would like to see come out of the
Tycho/M2Eclipse project is that I start building my plugins in Eclipse.  The
M2Eclipse tooling may offer some benefits in adding dependencies from a
repository that are not already in my target platform; however I would
leverage a lot of the PDE tooling to manage dependencies and other OSGi
concerns.  I make my necessary modifications to the manifest file and plugin
file.  It now works in my Eclipse IDE.  *Working in the IDE = it will work
off the command line with Maven!*  All other PDE automation solutions
available today require a lot of configuration.

How all this will work is the question of the day... :-)

On Tue, Aug 19, 2008 at 3:40 PM, James Ervin <[EMAIL PROTECTED]> wrote:

> Alex,
> I would love to hear the reply myself.  You have outlined the issues with
> using Maven for PDE very well.  I think the issue is how well do you want to
> integrate with the PDE?  I know you could easily throw the Maven Classpath
> container into a plugin project and the JDT will respect it, the issue is
> the PDE tooling.  Are packages in the maven cp container allowed to be
> exported?  What about the runtime classpath entries in the manifest.mf?  How
> about when self-hosting, are those classes also used?  I mean outside of the
> build automation issues, you really really don't want to be writing code
> without self hosting or PDE tooling.
>
> I know I don't have any answers for your questions, only am expressing
> interest in the issue.  One thing I will say, building Eclipse plugins from
> the UI is easy peasy, trying to get the batch or headless mode build working
> is a bit of a nightmare.  If Maven could simplify this, this would be a
> killer app that would perhaps force alot of Eclipse plugin developers into
> Maven.
>
> James
>
>
> On Tue, Aug 19, 2008 at 12:51 PM, Alexandre Sauvé <[EMAIL PROTECTED]>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
>>    )*  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)*  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)* 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
>>
>>
>
>
> --
> James E. Ervin, IV
>
> A human being should be able to change a diaper, plan an invasion, butcher
> a hog, conn a ship, design a building, write a sonnet, balance accounts,
> build a wall, set a bone, comfort the dying, take orders, give orders,
> cooperate, act alone, solve equations, analyze a new problem, pitch manure,
> program a computer, cook a tasty meal, fight efficiently, die gallantly.
> Specialization is for insects.
> -Robert A. Heinlein
>
> Blog: http://iacobus.blogspot.com
>

Reply via email to