Date: Wed, 31 Aug 2005 23:04:55 +0300 From: Panagiotis Astithas <past@ebs.gr> To: Vizion <vizion@vizion.occoxmail.com> 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: <43160D67.6040605@ebs.gr> In-Reply-To: <200508310829.03121.vizion@vizion.occoxmail.com> References: <200508251303.59453.vizion@vizion.occoxmail.com> <200508301927.31549.vizion@vizion.occoxmail.com> <43156772.7070808@ebs.gr> <200508310829.03121.vizion@vizion.occoxmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Vizion wrote:
> 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.
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!")
>>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. 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"?
>>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
Panagiotis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43160D67.6040605>