How should eclipse be organized in the ports tree?

[Vizion]

On Tuesday 30 August 2005 14:23,  the author Mark Linimon contributed to the 
dialogue on-
 Re: Eclipse as part of the ports/java tree? [Was freebsd eclipse plugins & 
mailing list]: 
BTW I have switched subject to the thread for the freebsd-eclipse maillist and 
cc'd  you and Herve. I want to respect those who are on the official 
freebsd-eclipse mailing list. I could also cc the text to freebsd-java if you 
want.

>On Tue, Aug 30, 2005 at 10:10:26AM -0700, Vizion wrote:
>> I am now faced with the question is the ports tree as inflexible as some
>> people suggest or are some members of our meritocracy more inflexible than
>> the freebsd assets?
>
>This is a complete oversimplification of the situation.
>
>There are some hard-coded assumptions in the ports tree -- one of which is
>that there are two levels, categories and ports -- and these assumptions
>are mirrored in the repositories of tens of thousands if not hundreds of
>thousands of users, and thousands of lines of shell scripts and database
>programs that create the binary packages and monitor the results of those
>build processes.
>
>So when you suggest that the only way that Eclipse can be supported is
>to have a multilevel ports tree -- as you are seeming to -- you are clearly
>totally misunderestimating the amount of effort involved.
>
>In your most recent email I think you are finally getting a lot closer to
>what I consider 'real' problem.  IMHO the interesting problems you want to
>solve are the 'search' and 'browse' problems.  Directory names controlled
>by CVS structures in an unbranched tree, which are then mirrored all around
>the world, are really poor paradigms for these problems.  Herve has
>suggested some better tools for these which are better ways to think
>about these problems and you should look at those.  We certainly need more.
>
>The meta-plugin idea is also worth considering.
>
>But restructuring the entire tree, even to add a few hundred ports, is
>simply not feasible with the level of volunteer effort we have and the
>number of people that depend on the current structure worldwide.
>
>mcl

Ok - building on your comments would my original suggestion, as modified 
below, and leaving aside for one moment the arguments as to whether or not 
committers might desire it,be capable of implementation without a 
restructuring of code?

This proposal mean that /usr/ports/plugins/*.jar is a repository for files 
which are accessed solely via the meta-eclipsevx.xxx ports.

I think this might shoehorn the necessary structure into the existing system. 
What do you think?

/usr/ports/eclipse/eclipsemainv[x.xxx]     Holds the main eclipse ports
/usr/ports/eclipse/meta-eclipse[v.xxx]     Holds eclipse plugins loader
/usr/ports/eclipse/plugins/                        Holds the *.jar files
/usr/ports/eclipse/misc1                          self contained eclipse ports
/usr/ports/eclipse/misc2
/usr/ports/eclipse/miscN 

/usr/ports/eclipse/plugins would, in effect, be a set of files which would be 
downloaded under control of the meta-eclipse  loader                                                                                                                
 
 If so why not use it - that would make eclipse a category which could enclose 
a number of ports for eclipse versions, a number 
of   /usr/ports/eclipse/meta_eclipseplugin ports  and each plugin would then 
(in  effect) be a *.jar file file held within the /usr/eclipse/plugins 
directory. 
The meta_eclipse plugin could build the library of available plugins on the 
fly and use the standard system for registering the plugins on the local 
machine. In that way could the need be integrated into the existing system?

Whatis your reaction?

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.