From owner-freebsd-eclipse@FreeBSD.ORG Wed Aug 31 22:05:11 2005 Return-Path: X-Original-To: freebsd-eclipse@freebsd.org Delivered-To: freebsd-eclipse@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1AC216A422; Wed, 31 Aug 2005 22:05:11 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from lakecmmtao06.coxmail.com (lakecmmtao06.coxmail.com [68.99.120.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0838A43D48; Wed, 31 Aug 2005 22:05:10 +0000 (GMT) (envelope-from vizion@vizion.occoxmail.com) Received: from dns1 ([64.58.171.82]) by lakecmmtao06.coxmail.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20050831220510.SHHW24491.lakecmmtao06.coxmail.com@dns1>; Wed, 31 Aug 2005 18:05:10 -0400 From: Vizion To: Panagiotis Astithas Date: Wed, 31 Aug 2005 15:01:06 -0700 User-Agent: KMail/1.8 References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508310829.03121.vizion@vizion.occoxmail.com> <43160D67.6040605@ebs.gr> In-Reply-To: <43160D67.6040605@ebs.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508311501.07026.vizion@vizion.occoxmail.com> Cc: Mark Linimon , Herve Quiroz , freebsd-eclipse@freebsd.org Subject: Re: How should eclipse be organized in the ports tree? X-BeenThere: freebsd-eclipse@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD users of eclipse EDI, tools, rich client apps & ports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 22:05:13 -0000 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 . > >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.