geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: [discuss] Eclipse as a Geronimo sub-project
Date Tue, 23 Aug 2005 18:24:22 GMT
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>http://eclipse.org/</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.
>

Mime
View raw message