How should eclipse be organized in the ports tree?

[Vizion]

On Wednesday 31 August 2005 13:04,  the author Panagiotis Astithas contributed 
to the dialogue on-
 Re: How should eclipse be organized in the ports tree?: 

>Vizion wrote:
>> On Wednesday 31 August 2005 01:16,  the author Panagiotis Astithas
<snip>.
>
>Wait a minute... you mean do something like symlink
>/usr/local/eclipse/plugins to /usr/ports/eclipse/plugins? And instead of
>downloading the plugin artifacts as usual (make fetch), get
>portsnap/cvsup to do it for you? I hope you don't really mean that,
>since that would just impose the bloat of eclipse jar files on everyone,
>everywhere with a ports collection ("You want eclipse-foo-plugin? No?
>Tough, you _will_ get it anyway on your next portsnap/cvsup!")


No that would crazy -- I am suggeestuing we have a *.jar files in 
the /usr/ports/eclipseplugins that gets the files from somewhere in 
ports/fidtfiles (sorry I thought that had been made clear much earlier in 
this dialogue.
>
>>>Furthermore, you describe the need to create an eclipse plugin that
>>>lists the available plugins as FreeBSD ports and lets the user install
>>>one and register it as a regular system package. How is this better than
>>>eclipse's own plugin management method?
>>
>> Currently plugins are scattered on different internet sites. The majority
>> are open source with no restrictions on redistribution if they are
>> unmodified. By bringing them together in one place we provide not only
>>
>>>I would go even further and ask
>>>why do you need FreeBSD-specific ports for most plugins? Why not simply
>>>install it via the internal GUI and be done with it? That way you get
>>>the usual Eclipse experience you see in other platforms. I am actually
>>>doing this myself and quite like it, to be honest. The tradeoff is that
>>>you get files under $PREFIX/eclipse that are not recorded in some
>>>package, but I'm OK with that.
>>
>> That is fine for single user but where you have multiple users you need to
>> be able to have a single system to ensure the whole team are using the
>> same plugin version. Freebsd offers a huge advantage in the its ports
>> mechanism for update and control of ports. I see the pluginloader provider
>> another gui into the package system.
>>
>>>But consider this: you propose to create
>>>a new FreeBSD-specific plugin for eclipse, reorganize the ports tree,
>>
>> I see  no reason to reorganize the ports tree. The only drawback seems to
>> be a quasi-religious objection to making eclipse a category in the ports
>> tree.
>>
>>>and change every existing eclipse plugin (to fit in the new scheme)
>>
>> I have read what is available and as far as I can see there is the
>> potential to do this without changing the vast majority of plugins that
>> have not yet been incorprated in the ports tree.
>>
>>>in
>>>exchange for what? The registration in packages of every plugin _and_ a
>>>GUI plugin manager? When you could get either of those with the current
>>>system? Does the amount of effort needed, justify the gain?
>>
>> Yes we get a rapid integration into the ports tree of  all the eclipse
>> plugins.
>>
>>>Let me state this once more, there is no eclipse-supported platform
>>>currently that provides what you propose. Therefore it cannot be
>>>considered a disadvantage for FreeBSD, either. 
>>>Our forefathers said, 
>>>that you should learn to walk, before running. Let's do that, shall we?
>>>Let's bring those 300+ plugins you mentioned into the ports system and
>>>see where we go from there.
>>
>> We could do that but the amount of work needed going that route is far
>> greater than the work involved in developing a generic eclipse loader by
>> adding additonal plugin feature to eclipse's own loader... think about it.
>
>Now, this seems a bit different from the above. You seem to suggest that
>we shall modify eclipse's internals to load plugins in our own
>particular way and that this will be easier than traditional porting
>work. 

It is not so much modifying eclipse internals as writing a plugin that extends 
the functionality of existing plugins.
>Do you have any proof for that? Have you got any WIP code to 
>discuss?
>Do you even know which classes in eclipse should be modified? 
>Or is this just a "it sounds like a good idea"?
It is more than "it soundslike a good idea but not as far as WIP (Ill explain 
why).
The "How to write an Eclipse installerin the eclipse help" is as far as I have 
gone in researching a start point. 
On the face of it the concept appears to be do-able. (I am wondering about 
whether *collect.jar files could be used to update an available eclipse 
plugins database on the local computer to be used by the freebsdloader plugin 
to create a li9nk to the standard eclipse install mechanism. 

I think it is eminently doable by building on eclipse's existing assets, but 
if the collect.jarfiles were not in a single directory we would not be able 
the files to comply with eclipse system requirements for update sites - and 
we could not use those assets!.

So I suppose I have started from the premise if there is no hope in getting 
the *collect.jar in a single directory then the concept is a non-starter 
unless we were willing to undertake an awful lot of work.

>>>Panagiotis
>
>Panagiotis

-- 
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.