Date: Wed, 31 Aug 2005 08:29:02 -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: <200508310829.03121.vizion@vizion.occoxmail.com> In-Reply-To: <43156772.7070808@ebs.gr> References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508301927.31549.vizion@vizion.occoxmail.com> <43156772.7070808@ebs.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 31 August 2005 01:16, the author Panagiotis Astithas contributed to the dialogue on- Re: How should eclipse be organized in the ports tree?: >Vizion wrote: >> On Tuesday 30 August 2005 16:15, the author Vizion contributed to the >> dialogue on- >> >> Re: How should eclipse be organized in the ports tree?: >>>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]: >>>>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 >> >> Just for sake of clarity the above are intended to be straight forward >> ports >> >>>/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 > >I see various problems with your approach, let me try to identify a few. > >First of all, a plugin's jar file is essentially its distfile, currently >downloaded by the ports system in ports/distfiles or its subdirectories. >Storing it in the ports CVS repository (in ports/eclipse/plugins), as >you seem to imply, would in some cases be problematic because of >licensing/redistribution issues (not to mention bloat). > >Another thing is that many eclipse plugins have to be traditional ports >since they require the ports infrastructure for their dependencies (see >java/eclipseme for an example). Therefore they do not fit in the >ports/eclipse/plugins case. Also, what is the point of treating plugins >differently, with ports/eclipse/plugins and ports/eclipse/miscX? What do >you gain by losing uniformity? The ability dramatically reduce the amount of work necessary to bring ALL available opensource eclipse plugins into the ports tree. By getting the plugins into their own directory we can take advantage of eclipse's inbuilt mechanism for importing plugins. By taking this approach all necessary moodifications can be contained within a pluginloader module and the *.jarcould, in the majority of cases, be the standard eclipse .jar file with little modification. > >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. >Let's get our system officially supported by >eclipse.org so that FreeBSD gets more visibility and credibility. Let's >work out the swt dependencies of various applications and be the first >eclipse platform that does not contain swt libraries all over the place. > >What do you say? > > >Cheers, > >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?200508310829.03121.vizion>