geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [discuss] Eclipse as a Geronimo sub-project
Date Tue, 23 Aug 2005 19:08:39 GMT
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.


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