|
| Re: Wildcard in local provider [message #503184 is a reply to message #503174] |
Fri, 11 December 2009 10:15   |
|
Hi Markus,
The problem with that approach is that in order to resolve the wildcards, you need to know the full layout of the
targeted repository. The repository might be huge so it take some time to figure that out.
For a local repository it might make sense, but for a remote repository it is much more difficult.
For you particular case, you can actually split things up in two providers. One with componentTypes="eclipse.feature"
and another with componentType="osgi.bundle". That will probably speed things up a bit since only the relevant provider
will be searched.
But I do understand that you mean this in a more generic sense.
I guess the answer is both yes and no. We could improve the local provider to understand this syntax, but as a global
thing I don't think it's feasible.
Regards,
Thomas Hallgren
On 2009-12-11 10:33, Markus Alexander Kuppe wrote:
> Hi,
>
> due to the fact that repos aren't usually flat but structured along
> projects, e.g.
>
> projectA/bundles/bundle1
> projectA/bundles/bundle2
> projectA/bundles/bundle3
> projectB/bundle
> projectC/features/bundle4
> projectC/bundles/bundle4
>
> it would be handy to support wildcards in the file uri of the local
> reader, e.g.
>
> <provider
> readerType="local"
> [...]
> <uri format="file:///{0}/**/{1}/">
> <bc:propertyRef key="workspace.root" />
> <bc:propertyRef key="buckminster.component" />
> </uri>
> </provider>
>
> Does this make sense to be implemented in Bucky?
>
> Markus
|
|
|
|
| Re: Wildcard in local provider [message #503363 is a reply to message #503229] |
Sat, 12 December 2009 10:55 |
|
Hi Markus,
I think it would be valuable to support automatic discovery in a way similar to what you mention on resources that are
local. It would be easy to do that on the 'local' reader type. In fact, it could be done on the 'url' reader as well for
cases where the protocol is 'file' or even 'platform'.
At present, I'm working on the 'git' reader type. That's another candidate for this type of discovery since the
repository it uses must be a local clone (if it isn't, it starts by creating such a clone).
Could you please enter a bugzilla for this?
Regards,
Thomas Hallgren
On 2009-12-11 14:25, Markus Alexander Kuppe wrote:
> On 12/11/2009 11:15 AM, Thomas Hallgren wrote:
>> Hi Markus,
>> The problem with that approach is that in order to resolve the
>> wildcards, you need to know the full layout of the targeted repository.
>> The repository might be huge so it take some time to figure that out.
>>
>> For a local repository it might make sense, but for a remote repository
>> it is much more difficult.
>>
>> For you particular case, you can actually split things up in two
>> providers. One with componentTypes="eclipse.feature" and another with
>> componentType="osgi.bundle". That will probably speed things up a bit
>> since only the relevant provider will be searched.
>>
>> But I do understand that you mean this in a more generic sense.
>>
>> I guess the answer is both yes and no. We could improve the local
>> provider to understand this syntax, but as a global thing I don't think
>> it's feasible.
>
> For the record, for the moment we use
>
> mkdir projects/
> find . -type f -iname '.project' -printf %h\\n | xargs -i cp -rf {}
> projects/
>
> to flatten the repo substructure layout in a pre bucky step.
>
> Markus
|
|
|
|
Powered by
FUDForum. Page generated in 0.03319 seconds
] 
Search
Help
Register
Login
Home
