Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4313A33A.5050604@apache.org>
Date: Tue, 30 Aug 2005 01:07:22 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: locationmap mounting [was: Re: [jira]
 Commented:	(FOR-573)	Provide
 locationmap mounting capability
References: <1443204181.1121072529609.JavaMail.jira@ajax.apache.org>
	 <1938709604.1125343864780.JavaMail.jira@ajax.apache.org>
	 <4998884405082912393a642077@mail.gmail.com>
	 <1125350918.20045.11.camel@localhost.localdomain>
	 <43138076.6050709@apache.org>
 <1125354158.20045.43.camel@localhost.localdomain>
In-Reply-To: <1125354158.20045.43.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thorsten Scherler wrote:
> On Mon, 2005-08-29 at 22:39 +0100, Ross Gardler wrote:
> 
>>Thorsten Scherler wrote:
>>
>>
>>>I wonder how the daisy plugin is working from a new seed.
>>
>>The daisy plugin does not provide a locationmap, it is up to the user to 
>>do this in their project. This is Ok since the URL of the repository is 
>>dependant on the project rather than the plugin.
>>
> 
> 
> Actually that is really bad for views and a showstopper to use the lm
> within views. Right now you have to do so much preparation that another
> step is just overkill. The activation of views already needs more time
> then building forrest.

I have suggested, many times, that views should go into core in order to 
remove the multiple dependencies between your plugins. It is precisely 
because of this kind of complication that plugins are not supposed to 
have dependencies as argued by Nicola and myself in, for example, 
http://marc.theaimsgroup.com/?l=forrest-dev&m=111900690921015&w=2


>>I'd like to make it a config value and provide a plugin locationmap, but 
>>that is for the future.
>>
> 
> 
> Please, no offense, 

[Hmmm...  I'm bracing myself... I've written a reply and come back to 
remove the "reaction" parts... ]

> but when you knew this, how could you suggest that I
> should refactor the view resolver code with the locationmap? 

Please, do not get upset that someone does not have the foresight to 
anticipate every potential hiccup in the development of the project. The 
reality is that my not forseeing this particular hiccup is no worse than 
you not foreseeing it - I don't know every detail of the project, just 
as you do not.

> If I check in my local version of views that means every project has to
> copy and paste the internal.view locationmap. Not really copyless.

I don't understand what the problem is. Forrest:views are going in core 
(eventually), therefore the locationmap settings for views should end up 
in the core Forrest locationmap not some plugin locationmap. What am I 
missing?

In the meantime we have a number of potential solutions:

Start a branch and move internal-views into core. This will remove all 
the dependencies between your plugins as we have always insisted must 
happen.

If you don't want to move it to core yet then we can rely on users 
copying the locationmap into the project since the plugin is still in 
the whiteboard and so is not in a finished state.

If this is too much for views to be enabled and you still insist on 
working with the internal plugin model then I'd recomend that we enhance 
the plugin loading code and, if necessary, the locationmap to mount a lm 
provided by a plugin.

Tell us what you need, we will help you achieve it.

Ross