Home » Archived » Buckminster » Materialize a buckminster.component from a URL
| Materialize a buckminster.component from a URL [message #383190] |
Fri, 06 March 2009 17:44  |
Eclipse User |
|
|
|
Originally posted by: jdu.mikrosimage.eu
Hi,
I'm trying to materialize a buckminster component from a given URL (pointing on a cspec). For this purpose I use a url.catalog
reader. But unfortunately, when querying the component the "Problem Occured" window pops up with the following message:
An internal error occurred during: "workspace materializer".
Only file protocol is supported at this time
Although, a directory with the component's name is created in the workspace, but nothing is materialized.
I've tried various readers (url, url.zipped) to test the way buckminster behaves, but it seems url.catalog is the right one to
materialize from a URL.
Is this the right way to proceed?
Here's what my rmap looks like:
<searchPath name="arnold">
<provider readerType="url.catalog" componentTypes="buckminster" mutable="true" source="true">
<uri format="https://{0}:{1}@wiki.mikrosimage.fr/mtoa_libs/arnold/{2}">
<bc:propertyRef key="svn.login"/>
<bc:propertyRef key="svn.passwd"/>
<bc:replace pattern="^arnold-(.*)$" replacement="$1">
<bc:propertyRef key="buckminster.component" />
</bc:replace>
</uri>
</provider>
</searchPath>
<locator pattern="^arnold-.*$" searchPathRef="arnold" />
Kind regards,
Julien
|
|
| | |
| Re: Materialize a buckminster.component from a URL [message #383200 is a reply to message #383198] |
Sun, 08 March 2009 23:30  |
|
Hi Guillaume,
I think you should look into using a "url" reader in combination with a
matcher element. The RMAP Matcher is specifically targeted to scan a web
page where many components are listed. It is capable of recognizing
advanced patterns and turn them into things understood by Buckminster
(component name and version in particular but other criteria like
revision, timestamp, os, ws, arch, and nl are also supported). This is
in fact the "more complex reader that could parse HTML form of web
folders" that you look for. More info here:
http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_(Reference)_-_LATEST#Provider_Matcher_component
Here's an example:
<provider readerType="eclipse.import" componentTypes="osgi.bundle">
<matcher base="http://example.org/some/folder/with/jars/">
<group name="MATCH">
<name pattern="([a-zA-Z0-9]+\.)*[a-zA-Z0-9_]+"
prefix="http://example.org/some/folder/with/jars/" suffix="_"/>
<version pattern="[0-9]+(\.[0-9]+){0,2}(\.[a-zA-Z0-9-_]+)?"
suffix=".jar"/>
</group>
</matcher>
<uri format="${MATCH}"/>
</provider>
This example will scan a web page for strings starting with
"http://example.org/some/folder/with/jars/<the name pattern>_<the
version pattern>.jar". For each entry found, the name and version will
be considered by the resolver. If a match is found, then the full match
(denoted by ${MATCH} is used as the URI.
Regards,
Thomas Hallgren
Guillaume Chatelet wrote:
> Hi all,
>
> I'm Julien's team mate and I'd like to add a few explanations about why it is so important to us to materialize components from URL.
> Maybe you'll have workarounds or advices.
>
> Until recently all our components were stored in a Subversion repository.
> While this is ok with "under development code" with source files this is a bad practice to store third party libraries into it.
> One should not place archives or libraries in an SCM because those components are simply not to be versioned.
>
> So we have libraries, say component ThirdPartyLibrary with versions ( 2.5, 2.6, 2.7 ...)
> Our source code components refers to one of these versions closing the gap between our versions and the library versions. Fine.
>
> Those third party libraries are to be accessible from several teams across the planet with access restrictions so the best option seems to put them in a web or webdav server.
> However for the moment it is not feasible to materialize component's from an URL. So we found a trick but this is very cumbersome and error prone.
> We are creating projects in Subversion which are basically dummy folders with a single buckminster.cspec, these are our components.
> The *buckminster.cspec* possess a *buckminster.prebind* action that uses fetcher executor to actually download and unzip the archive into the freshly materialized component. While this works it is actually quite complex as we have several location to maintain. Moreover, this pingpong between svn and web server is very unintuitive.
>
> Solutions I see are :
> + implement a simple URLCatalogReader which simply downloads http://mysite/mycomponent/buckminster.cspec and nothing else ( thats what we are actually using but with the subversion trick ). This would at least keep the component at a single location.
> + implement a more complex reader that could parse HTML form of web folders ( eg: http://repo1.maven..org/maven2/ ) and then grab files webcrawler-like to materialize the tree in the workspace - but what to do if the server doesn't provide such a view ? Fallback to option 1 ? And what about performance ? Or atomicity of the materialization ?
> + implement a webdav reader : builtin folder list/navigation capabilities in the protocol.
>
> I actually started coding the second option and this seems feasible but I would like to know what you think about that before going further.
>
> It would also be very helpful to have a property "buckminster.component.version" during the RMAP stage so we could switch branches according to the component's versionDesignator as it is for svn ( option moduleAfterTag/moduleBeforeTag ).
>
> Any feedback would be greatly appreciated.
>
> Best regards,
> Guillaume
>
>
> Nick Veys wrote :
>> A quick glance at the code shows that it's being truthful, only file://
>> urls are supported in url.catalog.
>>
>> Julien Dubuisson wrote:
>>
>>> An internal error occurred during: "workspace materializer".
>>> Only file protocol is supported at this time
>>
|
|
|
| Re: Materialize a buckminster.component from a URL [message #383202 is a reply to message #383200] |
Mon, 09 March 2009 08:03 |
 Guillaume Chatelet
Messages: 146
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
Thank you for the quick response. I played a bit with this reader, here is what I noticed :
* the matched url have to be in the page pointed by the base attribute of the matcher tag.
You cannot refer to something like <version pattern=... suffix="/buckminster.cspec"/> because this url is not in the downloaded page.
* you cannot chain matchers to browse the folders as the matching goes, something like :
> <matcher base="http://afolder/">
> <group name="BASE">
> <name pattern="[a-zA-Z]+" prefix="http://afolder/" suffix="/"/>
> </group>
> </matcher>
> <matcher base="${BASE}">
> <group name="BASE-VERSION">
> <version pattern="[0-9]+(\.[0-9]+){0,3}" prefix="${BASE}" suffix="/"/>
> </group>
> </matcher>
because ${BASE} seems not to be expanded in the next matcher.
However I think we can put all the components in the same folder. I will investigate further to see if it can fit our needs without far fetched tweaks.
Thx again,
Best regards,
Guillaume
Thomas Hallgren wrote :
> Hi Guillaume,
> I think you should look into using a "url" reader in combination with a
> matcher element. The RMAP Matcher is specifically targeted to scan a web
> page where many components are listed. It is capable of recognizing
> advanced patterns and turn them into things understood by Buckminster
> (component name and version in particular but other criteria like
> revision, timestamp, os, ws, arch, and nl are also supported). This is
> in fact the "more complex reader that could parse HTML form of web
> folders" that you look for. More info here:
>
> http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_(Reference)_-_LATEST#Provider_Matcher_component
>
>
> Here's an example:
>
> <provider readerType="eclipse.import" componentTypes="osgi.bundle">
> <matcher base="http://example.org/some/folder/with/jars/">
> <group name="MATCH">
> <name pattern="([a-zA-Z0-9]+\.)*[a-zA-Z0-9_]+"
> prefix="http://example.org/some/folder/with/jars/" suffix="_"/>
> <version pattern="[0-9]+(\.[0-9]+){0,2}(\.[a-zA-Z0-9-_]+)?"
> suffix=".jar"/>
> </group>
> </matcher>
> <uri format="${MATCH}"/>
> </provider>
>
> This example will scan a web page for strings starting with
> "http://example.org/some/folder/with/jars/<the name pattern>_<the
> version pattern>.jar". For each entry found, the name and version will
> be considered by the resolver. If a match is found, then the full match
> (denoted by ${MATCH} is used as the URI.
>
>
> Regards,
> Thomas Hallgren
>
>
>
> Guillaume Chatelet wrote:
>> Hi all,
>>
>> I'm Julien's team mate and I'd like to add a few explanations about
>> why it is so important to us to materialize components from URL.
>> Maybe you'll have workarounds or advices.
>>
>> Until recently all our components were stored in a Subversion repository.
>> While this is ok with "under development code" with source files this
>> is a bad practice to store third party libraries into it.
>> One should not place archives or libraries in an SCM because those
>> components are simply not to be versioned.
>>
>> So we have libraries, say component ThirdPartyLibrary with versions (
>> 2.5, 2.6, 2.7 ...)
>> Our source code components refers to one of these versions closing the
>> gap between our versions and the library versions. Fine.
>>
>> Those third party libraries are to be accessible from several teams
>> across the planet with access restrictions so the best option seems to
>> put them in a web or webdav server.
>> However for the moment it is not feasible to materialize component's
>> from an URL. So we found a trick but this is very cumbersome and error
>> prone.
>> We are creating projects in Subversion which are basically dummy
>> folders with a single buckminster.cspec, these are our components.
>> The *buckminster.cspec* possess a *buckminster.prebind* action that
>> uses fetcher executor to actually download and unzip the archive into
>> the freshly materialized component. While this works it is actually
>> quite complex as we have several location to maintain. Moreover, this
>> pingpong between svn and web server is very unintuitive.
>>
>> Solutions I see are :
>> + implement a simple URLCatalogReader which simply downloads
>> http://mysite/mycomponent/buckminster.cspec and nothing else ( thats
>> what we are actually using but with the subversion trick ). This would
>> at least keep the component at a single location.
>> + implement a more complex reader that could parse HTML form of web
>> folders ( eg: http://repo1.maven..org/maven2/ ) and then grab files
>> webcrawler-like to materialize the tree in the workspace - but what to
>> do if the server doesn't provide such a view ? Fallback to option 1 ?
>> And what about performance ? Or atomicity of the materialization ?
>> + implement a webdav reader : builtin folder list/navigation
>> capabilities in the protocol.
>>
>> I actually started coding the second option and this seems feasible
>> but I would like to know what you think about that before going further.
>>
>> It would also be very helpful to have a property
>> "buckminster.component.version" during the RMAP stage so we could
>> switch branches according to the component's versionDesignator as it
>> is for svn ( option moduleAfterTag/moduleBeforeTag ).
>>
>> Any feedback would be greatly appreciated.
>>
>> Best regards,
>> Guillaume
>>
>>
>> Nick Veys wrote :
>>> A quick glance at the code shows that it's being truthful, only file://
>>> urls are supported in url.catalog.
>>>
>>> Julien Dubuisson wrote:
>>>
>>>> An internal error occurred during: "workspace materializer".
>>>> Only file protocol is supported at this time
>>>
|
|
|
| Re: Materialize a buckminster.component from a URL [message #383205 is a reply to message #383202] |
Mon, 09 March 2009 15:22 |
|
Hi Guillaume,
If you want a nested folder structure where you store your binaries,
then I suggest you adopt some well known format for that. Maven for
instance ;-)
Regards,
Thomas Hallgren
Guillaume Chatelet wrote:
> Hi Thomas,
>
> Thank you for the quick response. I played a bit with this reader, here is what I noticed :
> * the matched url have to be in the page pointed by the base attribute of the matcher tag.
> You cannot refer to something like <version pattern=... suffix="/buckminster.cspec"/> because this url is not in the downloaded page.
> * you cannot chain matchers to browse the folders as the matching goes, something like :
>> <matcher base="http://afolder/">
>> <group name="BASE">
>> <name pattern="[a-zA-Z]+" prefix="http://afolder/" suffix="/"/>
>> </group>
>> </matcher>
>> <matcher base="${BASE}">
>> <group name="BASE-VERSION">
>> <version pattern="[0-9]+(\.[0-9]+){0,3}" prefix="${BASE}" suffix="/"/>
>> </group>
>> </matcher>
>
> because ${BASE} seems not to be expanded in the next matcher.
>
> However I think we can put all the components in the same folder. I will investigate further to see if it can fit our needs without far fetched tweaks.
>
> Thx again,
> Best regards,
> Guillaume
>
>
> Thomas Hallgren wrote :
>> Hi Guillaume,
>> I think you should look into using a "url" reader in combination with a
>> matcher element. The RMAP Matcher is specifically targeted to scan a web
>> page where many components are listed. It is capable of recognizing
>> advanced patterns and turn them into things understood by Buckminster
>> (component name and version in particular but other criteria like
>> revision, timestamp, os, ws, arch, and nl are also supported). This is
>> in fact the "more complex reader that could parse HTML form of web
>> folders" that you look for. More info here:
>>
>> http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_(Reference)_-_LATEST#Provider_Matcher_component
>>
>>
>> Here's an example:
>>
>> <provider readerType="eclipse.import" componentTypes="osgi.bundle">
>> <matcher base="http://example.org/some/folder/with/jars/">
>> <group name="MATCH">
>> <name pattern="([a-zA-Z0-9]+\.)*[a-zA-Z0-9_]+"
>> prefix="http://example.org/some/folder/with/jars/" suffix="_"/>
>> <version pattern="[0-9]+(\.[0-9]+){0,2}(\.[a-zA-Z0-9-_]+)?"
>> suffix=".jar"/>
>> </group>
>> </matcher>
>> <uri format="${MATCH}"/>
>> </provider>
>>
>> This example will scan a web page for strings starting with
>> "http://example.org/some/folder/with/jars/<the name pattern>_<the
>> version pattern>.jar". For each entry found, the name and version will
>> be considered by the resolver. If a match is found, then the full match
>> (denoted by ${MATCH} is used as the URI.
>>
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>>
>> Guillaume Chatelet wrote:
>>> Hi all,
>>>
>>> I'm Julien's team mate and I'd like to add a few explanations about
>>> why it is so important to us to materialize components from URL.
>>> Maybe you'll have workarounds or advices.
>>>
>>> Until recently all our components were stored in a Subversion repository.
>>> While this is ok with "under development code" with source files this
>>> is a bad practice to store third party libraries into it.
>>> One should not place archives or libraries in an SCM because those
>>> components are simply not to be versioned.
>>>
>>> So we have libraries, say component ThirdPartyLibrary with versions (
>>> 2.5, 2.6, 2.7 ...)
>>> Our source code components refers to one of these versions closing the
>>> gap between our versions and the library versions. Fine.
>>>
>>> Those third party libraries are to be accessible from several teams
>>> across the planet with access restrictions so the best option seems to
>>> put them in a web or webdav server.
>>> However for the moment it is not feasible to materialize component's
>>> from an URL. So we found a trick but this is very cumbersome and error
>>> prone.
>>> We are creating projects in Subversion which are basically dummy
>>> folders with a single buckminster.cspec, these are our components.
>>> The *buckminster.cspec* possess a *buckminster.prebind* action that
>>> uses fetcher executor to actually download and unzip the archive into
>>> the freshly materialized component. While this works it is actually
>>> quite complex as we have several location to maintain. Moreover, this
>>> pingpong between svn and web server is very unintuitive.
>>>
>>> Solutions I see are :
>>> + implement a simple URLCatalogReader which simply downloads
>>> http://mysite/mycomponent/buckminster.cspec and nothing else ( thats
>>> what we are actually using but with the subversion trick ). This would
>>> at least keep the component at a single location.
>>> + implement a more complex reader that could parse HTML form of web
>>> folders ( eg: http://repo1.maven..org/maven2/ ) and then grab files
>>> webcrawler-like to materialize the tree in the workspace - but what to
>>> do if the server doesn't provide such a view ? Fallback to option 1 ?
>>> And what about performance ? Or atomicity of the materialization ?
>>> + implement a webdav reader : builtin folder list/navigation
>>> capabilities in the protocol.
>>>
>>> I actually started coding the second option and this seems feasible
>>> but I would like to know what you think about that before going further.
>>>
>>> It would also be very helpful to have a property
>>> "buckminster.component.version" during the RMAP stage so we could
>>> switch branches according to the component's versionDesignator as it
>>> is for svn ( option moduleAfterTag/moduleBeforeTag ).
>>>
>>> Any feedback would be greatly appreciated.
>>>
>>> Best regards,
>>> Guillaume
>>>
>>>
>>> Nick Veys wrote :
>>>> A quick glance at the code shows that it's being truthful, only file://
>>>> urls are supported in url.catalog.
>>>>
>>>> Julien Dubuisson wrote:
>>>>
>>>>> An internal error occurred during: "workspace materializer".
>>>>> Only file protocol is supported at this time
|
|
|
| Re: Materialize a buckminster.component from a URL [message #383211 is a reply to message #383205] |
Tue, 10 March 2009 17:30 |
| Eclipse User |
|
|
|
Originally posted by: jdu.mikrosimage.eu
Hi Thomas,
Have we mentioned we are trying to materialize C++ component ?
In order to materialize them from a URL, I've followed your suggestion of using an URL reader and a Provider Matcher component.
It almost worked but this solution is not as neat and efficient as we want it to be.
First a quick reminder of the situation.
We are trying to materialize a C++ application from our svn repos. This application has dependencies, mostly binaries (
libraries or include file ) or other revision controlled C++ projects.
There are two scenario we would like to accomplish :
o the component is defined in a single cspec, in which there are actions to fetch the archived libs with a "fetcher" actor.
The materialization process only fetches the cspec in the workspace and lets us play with the various actions. Great for
team members accustomed with buckminster.
o the component is a cspec in a folder-tree, and the materialization downloads the tree structure directly in the workspace
( cvs or svn like )
A simple way to test libraries, and allow temporary developpers to join the project, without bumping in the Buckminster
complexity ( cspec, ant, xml .. )
Now, here's the problem we faced while trying to use URL reader/matcher.
During the process of resolving a match, the matcher tries to identify a name and a version number in the URL that is passed but
it seems the version number that is found is automatically cast into an OSGi version, even if "string" version is requested. We
had no choice but modifying the version number of all the dependencies of our project to match OSGi specification. This is
unintuitive for people in the project when the version goes from 2.33.5.3 to 2.33.5.r3.
When a component is materialized, say the cspec of the openexr lib version 1.5, the buckminster.home property is set to the name
of the cspec, which in this case is openexr_1.5.0.r0.cpsec (uh!).
Thus the action(s) that really fetch the library files tries to use the buckminster.home property as a basedir, and therefore
fetch the files in a openexr_1.5.0.r0.cpsecMyDir directory (assuming MyDir is the name of the directory to fetch in). So we had
to modify the "dir" actor property of the fetchers if we want something a "little" more readable. Not as clean as the
openexr_1.5.0/MyDir folder structure we had before.
Moreover, using the url reader materializes the component in the .buckminster folder of the workspace ( no more one folder per
component in the workspace ), thus the component are no more accessible as a project in eclipse. This makes modifications rather
a daunting task - no modification available within Eclipse.
To sum up a reader that could materialize svn-like a component in the workspace would be IMO a great tool for us - other
protocols like scp, webdav could be the solution.
If you see any other way to handle that situation let us know.
Best regards
Julien
Thomas Hallgren a écrit :
> Hi Guillaume,
> If you want a nested folder structure where you store your binaries,
> then I suggest you adopt some well known format for that. Maven for
> instance ;-)
>
> Regards,
> Thomas Hallgren
>
> Guillaume Chatelet wrote:
>> Hi Thomas,
>>
>> Thank you for the quick response. I played a bit with this reader,
>> here is what I noticed :
>> * the matched url have to be in the page pointed by the base attribute
>> of the matcher tag.
>> You cannot refer to something like <version pattern=...
>> suffix="/buckminster.cspec"/> because this url is not in the
>> downloaded page.
>> * you cannot chain matchers to browse the folders as the matching
>> goes, something like :
>>> <matcher base="http://afolder/">
>>> <group name="BASE">
>>> <name pattern="[a-zA-Z]+" prefix="http://afolder/" suffix="/"/>
>>> </group>
>>> </matcher>
>>> <matcher base="${BASE}">
>>> <group name="BASE-VERSION">
>>> <version pattern="[0-9]+(\.[0-9]+){0,3}" prefix="${BASE}"
>>> suffix="/"/>
>>> </group>
>>> </matcher>
>>
>> because ${BASE} seems not to be expanded in the next matcher.
>>
>> However I think we can put all the components in the same folder. I
>> will investigate further to see if it can fit our needs without far
>> fetched tweaks.
>>
>> Thx again,
>> Best regards,
>> Guillaume
>>
>>
>> Thomas Hallgren wrote :
>>> Hi Guillaume,
>>> I think you should look into using a "url" reader in combination with a
>>> matcher element. The RMAP Matcher is specifically targeted to scan a web
>>> page where many components are listed. It is capable of recognizing
>>> advanced patterns and turn them into things understood by Buckminster
>>> (component name and version in particular but other criteria like
>>> revision, timestamp, os, ws, arch, and nl are also supported). This is
>>> in fact the "more complex reader that could parse HTML form of web
>>> folders" that you look for. More info here:
>>>
>>> http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_(Reference)_-_LATEST#Provider_Matcher_component
>>>
>>>
>>>
>>> Here's an example:
>>>
>>> <provider readerType="eclipse.import" componentTypes="osgi.bundle">
>>> <matcher base="http://example.org/some/folder/with/jars/">
>>> <group name="MATCH">
>>> <name pattern="([a-zA-Z0-9]+\.)*[a-zA-Z0-9_]+"
>>> prefix="http://example.org/some/folder/with/jars/" suffix="_"/>
>>> <version pattern="[0-9]+(\.[0-9]+){0,2}(\.[a-zA-Z0-9-_]+)?"
>>> suffix=".jar"/>
>>> </group>
>>> </matcher>
>>> <uri format="${MATCH}"/>
>>> </provider>
>>>
>>> This example will scan a web page for strings starting with
>>> "http://example.org/some/folder/with/jars/<the name pattern>_<the
>>> version pattern>.jar". For each entry found, the name and version will
>>> be considered by the resolver. If a match is found, then the full match
>>> (denoted by ${MATCH} is used as the URI.
>>>
>>>
>>> Regards,
>>> Thomas Hallgren
>>>
>>>
>>>
>>> Guillaume Chatelet wrote:
>>>> Hi all,
>>>>
>>>> I'm Julien's team mate and I'd like to add a few explanations about
>>>> why it is so important to us to materialize components from URL.
>>>> Maybe you'll have workarounds or advices.
>>>>
>>>> Until recently all our components were stored in a Subversion
>>>> repository.
>>>> While this is ok with "under development code" with source files this
>>>> is a bad practice to store third party libraries into it.
>>>> One should not place archives or libraries in an SCM because those
>>>> components are simply not to be versioned.
>>>>
>>>> So we have libraries, say component ThirdPartyLibrary with versions (
>>>> 2.5, 2.6, 2.7 ...)
>>>> Our source code components refers to one of these versions closing the
>>>> gap between our versions and the library versions. Fine.
>>>>
>>>> Those third party libraries are to be accessible from several teams
>>>> across the planet with access restrictions so the best option seems to
>>>> put them in a web or webdav server.
>>>> However for the moment it is not feasible to materialize component's
>>>> from an URL. So we found a trick but this is very cumbersome and error
>>>> prone.
>>>> We are creating projects in Subversion which are basically dummy
>>>> folders with a single buckminster.cspec, these are our components.
>>>> The *buckminster.cspec* possess a *buckminster.prebind* action that
>>>> uses fetcher executor to actually download and unzip the archive into
>>>> the freshly materialized component. While this works it is actually
>>>> quite complex as we have several location to maintain. Moreover, this
>>>> pingpong between svn and web server is very unintuitive.
>>>>
>>>> Solutions I see are :
>>>> + implement a simple URLCatalogReader which simply downloads
>>>> http://mysite/mycomponent/buckminster.cspec and nothing else ( thats
>>>> what we are actually using but with the subversion trick ). This would
>>>> at least keep the component at a single location.
>>>> + implement a more complex reader that could parse HTML form of web
>>>> folders ( eg: http://repo1.maven..org/maven2/ ) and then grab files
>>>> webcrawler-like to materialize the tree in the workspace - but what to
>>>> do if the server doesn't provide such a view ? Fallback to option 1 ?
>>>> And what about performance ? Or atomicity of the materialization ?
>>>> + implement a webdav reader : builtin folder list/navigation
>>>> capabilities in the protocol.
>>>>
>>>> I actually started coding the second option and this seems feasible
>>>> but I would like to know what you think about that before going
>>>> further.
>>>>
>>>> It would also be very helpful to have a property
>>>> "buckminster.component.version" during the RMAP stage so we could
>>>> switch branches according to the component's versionDesignator as it
>>>> is for svn ( option moduleAfterTag/moduleBeforeTag ).
>>>>
>>>> Any feedback would be greatly appreciated.
>>>>
>>>> Best regards,
>>>> Guillaume
>>>>
>>>>
>>>> Nick Veys wrote :
>>>>> A quick glance at the code shows that it's being truthful, only
>>>>> file://
>>>>> urls are supported in url.catalog.
>>>>>
>>>>> Julien Dubuisson wrote:
>>>>>
>>>>>> An internal error occurred during: "workspace materializer".
>>>>>> Only file protocol is supported at this time
|
|
|
| Re: Materialize a buckminster.component from a URL [message #383212 is a reply to message #383211] |
Tue, 10 March 2009 22:30 |
|
Hi Julien,
Some answers inline.
Julien Dubuisson wrote:
> Hi Thomas,
>
> Have we mentioned we are trying to materialize C++ component ?
> In order to materialize them from a URL, I've followed your suggestion
> of using an URL reader and a Provider Matcher component.
> It almost worked but this solution is not as neat and efficient as we
> want it to be.
>
> First a quick reminder of the situation.
> We are trying to materialize a C++ application from our svn repos. This
> application has dependencies, mostly binaries ( libraries or include
> file ) or other revision controlled C++ projects.
>
> There are two scenario we would like to accomplish :
> o the component is defined in a single cspec, in which there are
> actions to fetch the archived libs with a "fetcher" actor.
> The materialization process only fetches the cspec in the
> workspace and lets us play with the various actions. Great for team
> members accustomed with buckminster.
Not sure I understand the benefits of this. Why don't you declare the
archived libs as components that this cspec is dependent on?
> o the component is a cspec in a folder-tree, and the materialization
> downloads the tree structure directly in the workspace ( cvs or svn like )
Please explain 'cvs or svn like'. Are you saying that it is not cvs or
svn but you simulate that behavior somehow? Or is this something that
you would like to do?
> A simple way to test libraries, and allow temporary developpers to
> join the project, without bumping in the Buckminster complexity ( cspec,
> ant, xml .. )
>
> Now, here's the problem we faced while trying to use URL reader/matcher.
>
> During the process of resolving a match, the matcher tries to identify a
> name and a version number in the URL that is passed but it seems the
> version number that is found is automatically cast into an OSGi version,
> even if "string" version is requested. We had no choice but modifying
> the version number of all the dependencies of our project to match OSGi
> specification. This is unintuitive for people in the project when the
> version goes from 2.33.5.3 to 2.33.5.r3.
>
The <matcher> element takes an attribute 'versionType'. It should be
possible to write <matcher versionType="String">. This was a fairly
recent addition and I noticed it had not made it to the wiki docs yet.
It's added now.
A much more advanced version type system is under way. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=266227
> When a component is materialized, say the cspec of the openexr lib
> version 1.5, the buckminster.home property is set to the name of the
> cspec, which in this case is openexr_1.5.0.r0.cpsec (uh!).
>
> Thus the action(s) that really fetch the library files tries to use the
> buckminster.home property as a basedir, and therefore fetch the files in
> a openexr_1.5.0.r0.cpsecMyDir directory (assuming MyDir is the name of
> the directory to fetch in). So we had to modify the "dir" actor property
> of the fetchers if we want something a "little" more readable. Not as
> clean as the openexr_1.5.0/MyDir folder structure we had before.
>
I'm a little confused here. Perhaps it would be more clear if you could
explain what behavior you would expect. I'm not sure what it is you are
materializing and what you are using fetchers to fetch or why you have
the split between materializer and fetcher actors.
> Moreover, using the url reader materializes the component in the
> .buckminster folder of the workspace ( no more one folder per component
> in the workspace ), thus the component are no more accessible as a
> project in eclipse. This makes modifications rather a daunting task - no
> modification available within Eclipse.
>
Materializing into .buckminster is the default behavior. You alter that
behavior with an MSPEC. It lets you control the overall defaults
(folder, materializer) and also explicit per component if you so wish.
> To sum up a reader that could materialize svn-like a component in the
> workspace would be IMO a great tool for us - other protocols like scp,
> webdav could be the solution.
>
Any submissions in that direction are more then welcome.
> If you see any other way to handle that situation let us know.
>
I still think it might be a good idea for your to investigate how
feasible it would be to use a maven repository to store your artifacts.
AFAIK, it should be possible to store binaries there and you would get a
fairly advanced Buckminster reader for free.
Regards,
Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Sat Apr 20 14:51:48 GMT 2024
Powered by FUDForum. Page generated in 0.03661 seconds |
] 
Search
Help
Register
Login
Home
