Date: Wed, 31 Aug 2005 15:01:06 -0700 From: Vizion <vizion@vizion.occoxmail.com> To: Panagiotis Astithas <past@ebs.gr> Cc: Mark Linimon <linimon@lonesome.com>, Herve Quiroz <hq@freebsd.org>, freebsd-eclipse@freebsd.org Subject: Re: How should eclipse be organized in the ports tree? Message-ID: <200508311501.07026.vizion@vizion.occoxmail.com> In-Reply-To: <43160D67.6040605@ebs.gr> References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508310829.03121.vizion@vizion.occoxmail.com> <43160D67.6040605@ebs.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508311501.07026.vizion>