geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: [discuss] Eclipse as a Geronimo sub-project
Date Tue, 23 Aug 2005 19:35:35 GMT
Actually the many of the ant scripts are automatically created for you 
and shouldn't require any tweaking...

Here is a good eclipse article on the recommended way to set up a build 
enviornment using the PDE builder.

By using maven, we're just respecifying all the info thats contained in 
the plugin.xml for a given plugin, plus all the other goals to be able 
to package the plugin as a deployable feature.  So esentially more work 
will go into building with Maven, then using PDE. So my big concern is 
that we're wanting to use maven, just because everything else is using 
maven.  If we're respecifying all these things, like dependences, new 
goals, etc.... plus you still have to manually download Eclipse, WTP, 
EMF and point to an Eclipse install to build, what is the advantage of 
using Maven?  One of the big advantages is how maven can automatically 
pull down dependencies, and this feature cannot be exploited.

Dain Sundstrom wrote:
> Wow!  I can't believe Eclipse got this so wrong.  Requiring a  
> generated ant script to build is a red flag to me.  Anyway, I'm going  
> to try to get the maven guys to comment.
> -dain
> On Aug 23, 2005, at 11:24 AM, Sachin Patel wrote:
>> So as far as building is concerned, you're right, I took a quick  
>> glance at the mevenide plugin scripts and they are building purely  
>> with Maven.  I'm still trying to understand the Maven build process  
>> but looking at these project.xml' files it doesn't look like their  
>> dependent on the Eclipse PDE builder, and they have the ability to  
>> not only compile, but to package and create both plugins and their  
>> features, as well as the jars for an update site.
>> But....
>> One of my original concerns was that plugin dependencies from  
>> Eclipse cannot be downloaded individually.  Eclipse packages and  
>> makes available for download only full bundles of plugins/features,  
>> such as the Eclipse platform itself, WTP (comes in two parts), EMF,  
>> etc... The mavenide plugin doesn't have a solution for this, as  they 
>> require you to point to a full Eclipse install that contains  all 
>> your required plugins.
>> maven -Declipse.home=<path_to_eclipse> mevenide-eclipse:build
>> The second issue that Mevenide doesn't have an issue with, but the  
>> Geronimo plugins do is the type of dependencies that are needed. In  
>> Eclipse 3.1 plugins can be packaged as jars.  So as long as your  
>> dependencies are on plugins that have been packaged as jars,  
>> dependencies can easily be defined like below... and this is so the  
>> case for Mevenide it looks like.
>> dependency>
>>            <groupId>eclipse</groupId>
>>            <artifactId>eclipse-jdt</artifactId>
>>            <version>3.1.0</version>
>>            <type>jar</type>
>>            <url></url>
>>            <jar>org.eclipse.jdt.ui_3.1.0.jar</jar>
>>        </dependency>
>> The problem is that not all of the Eclipse projects have fully  
>> converted their plugins to jars and they remain exploded  directories 
>> containing "N" number of runtime jars.  This is  problematic since 
>> plugins have dependencies on other plugins, not  their individual 
>> jars.  So for those plugins that we depend on that  are not jars, we 
>> have then have to be fully aware of their runtime  jars and the paths 
>> and names of those jars, and have them hard  coded in the dependency 
>> list.  Where all you have to define in your  plugin.xml file for the 
>> PDE builder is the plugin, not which jars  it contains.
>> So it looks like they've created quite of bit of infrastructure  that 
>> has been created for including some jelly files as well.  Alot  of 
>> this may be reusable, but we definateley would need some kind of  way 
>> for taking care of dependencies that are exploded plugins.  I'm  
>> gonna dig in some more and see what I can get started, but I may  
>> need some help on getting this going.   I can provide you with  
>> answers to Eclipse questions and you guys can help with my Maven  
>> questions and togather hopefully we can get this thing building  from 
>> the command line.
>> QUESTION: So this will take some amount of work, do you all feel  
>> that building purely with Maven is the best approach or should we  
>> just take advantage of the eclipse PDE builder since Eclipse has to  
>> be downloaded regardless and launch the headless PDE builder within  
>> Maven????
>> Dain Sundstrom wrote:
>>> I created an eclipse-plugin component is jira.
>>> -dain
>>> On Aug 23, 2005, at 6:59 AM, Sachin Patel wrote:
>>>> As far as what users want, let me make a generic statement.  The   
>>>> server tooling area is already an established area, especially  in  
>>>> commercial tools such as WebSphere Application Toolkit and  
>>>> Rational  Application Developer.  Now IBM, BEA, and many other  
>>>> participants  are actively involved  in the WTP effort in which  
>>>> the goal is to  provide tooling support for J2EE and other  
>>>> application servers that  not only provides a strong set of J2EE  
>>>> functionality but is also a  completely extendable framework.  We  
>>>> need to avoid two parallel  efforts here in our tooling support  
>>>> for Geronimo but rather build  and leverage these frameworks and  
>>>> projects that have been accepted  and established already in the  
>>>> open source community, and use this  as our starting blueprint.  If 
>>>> and when this is an Apache  subproject, its critical that the  
>>>> Eclipse and Apache communities  communicate and work together.   So 
>>>> my opinion is that we don't need  to be re-inventing the wheel  
>>>> here, but keep our roadmap and  requirements focused on providing  
>>>> the Geronimo specific pieces that  integrate nicely with WTP.  So  
>>>> what the community wants for J2EE  and server tooling is  
>>>> constantly being discussed in the Eclipse  community, we just  need 
>>>> to start getting involved in those  discussions and bring  forth 
>>>> feature requests to them.
>>>> Sachin.

View raw message