How should eclipse be organized in the ports tree?

[Vizion]

On Tuesday 30 August 2005 08:26,  the author Herve Quiroz contributed to the 
dialogue on-
 Re: How should eclipse be organized in the ports tree?


Here is the second part
>David,
>
>I pretty much agree with all that Greg already said but still there are
>some facts I think you should be aware of if you actually wish to
>improve eclipse support in the ports tree...
>
>On Fri, Aug 26, 2005 at 05:20:38PM -0700, Vizion wrote:
>> >I'm not sure how thats an argument for creating a non-virtual eclipse
>> >category.  Would you care to explain?
>>
>> To hell with the pedantic label -- call it what you like - virtual or
>> non-virtual what matters is the reality of access and support to the
>> freebsd community that comes from the way in which we organize our files
>> and install the client rich applications and tools.
>>
>> here is what I think would work:
>> ports/eclipse/eclipse.v.x.xxx
>> .................../eclipse.v.x.nnn
>> ports/eclipse/plugins/puginlabel1
>> ports/eclipse/plugins/pluginlabel2
>> ................................/pluginlabelN
>> ports/eclipse/misc/file1
>> ports/eclipse/misc/file2
>> ............................/fileN
>>
>> Scattering eclipse modules and plugins over the whole of the ports tree
>> would, I believe, be both counterintuitive, counterproductive and
>> confusing.ports/eclipse
>
>No tool, whatever its "usefulness", deserves to have its own ports tree
>in the ports tree. That's indeed what you suggest in your message. The
>way the ports tree currently works is somewhat well defined in many
>locations (the Porter's Handbook mainly) and we, as commiters, tend to
>ensure that the current ports system provides enough flexibility so that
>no port would need some special treatment to fit in the ports tree.

Does not flexibilty mean the system being able to meet the special needs of 
any individual port -- rather than the port having to adapted to meet the 
inevitably limited preconceptions of the system at the time of its 
conception? If the system was flexible then there would be no problem!

Let see what we need and take it from there.
Eclipse is a client rich application with nearly 300 plugin modules which is 
likely to have over 600 plugin modules within a year.

Each plugin, in combination with the core, can (and often does) combine 
multiple functionalities (e.g it may   combine the functionalities of a 
database, a browser, a language development environment and a network 
service). 

Modules may be dependent upon one another.

Eclipse has its own internal mechanisms for handling those interdependencies. 

Is not the Freebsd ports hierarchy designed, from the base up, by seperating 
software on the assumption that the software can be categorized by 
functionalities?

Is not the question how do we deal with archiving ports which conceptually 
conflict with the assumptions behind the original design. Or to put it the 
other way round, my question is how can we use the existing ports hierarchy 
to meet the needs of the new generation of client rich applications which 
eclipse represents?

Eclipse represents a type of software development which did not exist at the 
time freebsd (or the ports) were being designed.

How do we store 300 -600 plugins in the short term and make them easily 
accessible?

How do we do that in a simple way?

Eclipse has an inbuilt plugin import system. If all the plugins were organized 
in one directory then it would be possible to build a generic system which 
could use eclipse to load the plugins and reduce the amount of work needed to 
keep the eclipse hierarchy up to date.

The only thing needed to make this work would be that only eclipse plugins 
should reside in the directory.

Hence my suggestion

/usr/ports/eclipse
                            This directory would hold the eclipse core 
identified by version number and possibly a freebsd specific plugin which 
manages the loading of all remaining eclipse plugins 
/usr/ports/eclipse/plugins
/usr/ports/eclipse/misc

there is no reasomn why this hierarchy should not be:
/usr/ports/xxxx/eclipse
/usr/ports/xxxx/eclipse/plugins
/usr/ports/xxxx/eclipse/misc

I see practicle reasons for keep all eclipseplugins in a single directory 
hierarchy. 

david


-- 
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
 Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after 
completing engineroom refit.