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 19:53:25 GMT
And here is an developer works article on building eclipse plugins with 
Maven....

https://www6.software.ibm.com/developerworks/education/os-mavenecl/index.html

At the end they note the issue of non-jar dependencies.

Sachin Patel wrote:
> 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.
>
> http://www.eclipse.org/articles/Article-PDE-Automation/automation.html
>
> 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>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