[SUGGEST] Reform eclipse and eclipse related ports

[Panagiotis Astithas]

Vizion wrote:
> On Tuesday 18 October 2005 07:30,  the author Vizion contributed to the 
> dialogue on-
>  Re: [SUGGEST] Reform eclipse and eclipse related ports: 
> 
> 
>>On Tuesday 18 October 2005 04:42,  the author Panagiotis Astithas
>>contributed to the dialogue on-
>>
>>Re: [SUGGEST] Reform eclipse and eclipse related ports:
>>
>>>Vizion wrote:
>>>
>>>>On Monday 17 October 2005 15:05,  the author Scot Hetzel contributed to
>>>>the dialogue on-
>>>>
>>>> Re: [SUGGEST] Reform eclipse and eclipse related ports:
>>>>
>>>>>On 10/17/05, Roman Neuhauser <neuhauser at sigpipe.cz> wrote:
>>>>>
>>>>>>  Wes said: "I have to resort to 'make search'" which presumably means
>>>>>>  he'd prefer to just ls /usr/ports/$emacs_category; while 'make
>>>>>>  search' is a bearable interface (FMPOV), you can't beat a ls.
>>>>>>
>>>>>>  Hey, what about materialized virtual categories? A bunch of
>>>>>>  symlinks, and everyone's happy. Or is that too much for CVS?
>>>>>
>>>>>It would probably be too much for CVS to handle, instead someone could
>>>>>modify bsd.port.mk to create the virtual category directories and then
>>>>>symbolicly link the ports into these categories.
>>>>>
>>>>>The following could be added to bsd.port.mk
>>>>>
>>>>>virtualport:
>>>>>.for CATEGORY in ${CATEGORIES}
>>>>>.if not exist ${PORTSDIR}/${CATEGORY}
>>>>>  mkdir ${PORTSDIR}/${CATEGORY}
>>>>>.endif
>>>>>.if not exist ${PORTSDIR}/${CATEGORY}/${PORTNAME}
>>>>> ln -s ${.CURDIR} ${PORTSDIR}/${CATEGORY}/${PORTNAME}
>>>>>.endif
>>>>>.endfor
>>>>>
>>>>>which would add the link for a specific port.  The we would need to
>>>>>add a virtualports target (bsd.subdir.mk?) that would decend thru all
>>>>>the ports creating all the symbolic links (similar to the "make
>>>>>readmes" target used in /usr/ports/ ).
>>>>>
>>>>>Also there would need to be another target that would remove all the
>>>>>symbolic links, that way you could re-create them without worrying
>>>>>about removed symbolic links pointing to non-existant ports.
>>>>>
>>>>>NOTE: Non of this code has been tested. If you want this feature, work
>>>>>on improving the code and submitting it as a patch to the PR database
>>>>>for Ports Managers to accept/reject.
>>>>>
>>>>>Scot
>>>>
>>>>Would this provide an opportunity to have for example:
>>>>/usr/ports/eclipse
>>>>/usr/ports/eclipse/plugins/
>>>>
>>>>so that the plugins could be selected for installation from make  config
>>>>in /usr/ports and manage the installation of the plugins (rather similar
>>>>to what happens for php)?
>>>
>>>This can be done today, with an eclipse-plugins meta-port, similar to
>>>the php5-extensions one. I may even find some time to work on it.
>>
>>Wow
>>
>>That is great
>>
>>That is what I have been arguing for for three months!!
>>
>>david
> 
> 
> BTW
> 
> If you get time would there be any chance you could set up the localized 
> plugin archive so that it conforms with Eclipse's expectation for plugin 
> installation.
> 
> Up until now, on a multi-user system, each user has to bring  plugins into 
> their individual work directories. This has led to different users 
> inadvertently working with different plugin versions. One of the reasons I 
> want to get the /usr/ports/eclipse/ and /usrports/eclipse/plugins hierarchies 
> working is to have a systenatic method of ensuring devellopers are working 
> with identical plugin versions. The ports tree system provides an ideal 
> method of monitoring the plugins.

I'm not sure I understand what you are saying here. Eclipse plugins are 
stored in the 'features' and 'plugins' subdirectories. They are also 
cached in the .eclipse folder in the user's home directory. If a user 
somehow ends up with a corrupted cache, there is always the -clean 
invocation of eclipse that recreates it. If the problem you encountered 
stems from the default permissions on the eclipse directory, you could 
always change them to fit your needs (I know I do).

Cheers,

Panagiotis