Home » Archived » Buckminster » How to materialize different versions of one component from CVS?
| How to materialize different versions of one component from CVS? [message #378546] |
Wed, 16 July 2008 12:33  |
 Michael Pfeiffer
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi!
I would like to use Buckminster to build different versions of one
component (=plugin) stored in a CVS repository. Only one version will be
checked out at any given time.
The CVS tree looks like this:
On HEAD are two versions of the component:
Version 1.0.0 tagged with v1_0_0
Version 2.0.0 tagged with v2_0_0
On another branch TEST is the third version of the component:
Version 3.0.0 tagged with v3_0_0
The start of branch TEST is also tagged with ROOT_TEST.
When I try to resolve any version of the component with the RMAP shown at
the end of the post, the following error is shown:
Syntax error in version string ROOT.TEST at position 0: Not a valid OSGi
version
Obviously Buckminster tries to get a version for tag ROOT_TEST and
versionConverter fails to convert it to an OSGi version.
In this scenario I would like to build either version 1.0.0, 2.0.0 or
3.0.0. The version associated with ROOT_TEST is of no interest.
Removing the tag ROOT_TEST is not an option. If necessary a version could
be assigned to that tag, however I would like to avoid that (and I don't
know how to do that too), because then that would be required for any tag
that might be added in the future.
I am not 100% sure if this is a bug ;-) or if I am doing something wrong.
Please advice.
If I replace the version type OSGi with type String in the CQUERY and
RMAP. I can materialize version 1.0.0. Doing the same for version 2.0.0 or
3.0.0 fails however with this error:
[0001] : Rejecting provider
cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match was
found
I guess that is a bug, shall I file a bug report?
The versionConverter allows to specify a bidirectional mapping from
version number to tag, where the information for the mapping is derived
from the version number or the tag.
What I really would like to do is to assign an arbitrary mapping between
version number and tag.
Like:
Version 1.0.0 has tag v20080101
Version 2.0.0 has tag v20080201
Version 3.0.0 has tag v20080301
Can this be achieved in the RMAP? I think it could be done with a CQUERY
and AdvisoryNodes, however I think doing it in the RMAP is more flexible
and I would prefer it that way.
Kind Regards,
Michael
<?xml version="1.0" encoding="UTF-8"?>
<rmap
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.eclipse.org/buckminster/RMap-1.0"
xmlns:bc="http://www.eclipse.org/buckminster/Common-1.0"
xmlns:mp="http://www.eclipse.org/buckminster/MavenProvider-1.0"
xmlns:pp="http://www.eclipse.org/buckminster/PDEMapProvider-1.0">
<searchPath name="versionTest">
<provider
readerType="cvs"
componentTypes="osgi.bundle"
source="true">
<uri
format=":pserver:lusaka.scch.at:/buckminstertest,{0}">
<bc:propertyRef key="buckminster.component" />
</uri>
<versionConverter
type="tag"
versionType="OSGi">
<transform
fromPattern="^(.+)$"
fromReplacement="v$1"
toPattern="^v(.+)$"
toReplacement="$1"
/>
<transform
fromPattern="\."
fromReplacement="_"
toPattern="_"
toReplacement="."
/>
</versionConverter>
</provider>
</searchPath>
<locator searchPathRef="versionTest" pattern="^at.scch.version.test$" />
</rmap>
|
|
|
| Re: How to materialize different versions of one component from CVS? [message #378548 is a reply to message #378546] |
Wed, 16 July 2008 16:30  |
|
Michael Pfeiffer wrote:
> Hi!
>
> I would like to use Buckminster to build different versions of one
> component (=plugin) stored in a CVS repository. Only one version will be
> checked out at any given time.
>
> The CVS tree looks like this:
> On HEAD are two versions of the component:
> Version 1.0.0 tagged with v1_0_0
> Version 2.0.0 tagged with v2_0_0
> On another branch TEST is the third version of the component:
> Version 3.0.0 tagged with v3_0_0
> The start of branch TEST is also tagged with ROOT_TEST.
>
> When I try to resolve any version of the component with the RMAP shown
> at the end of the post, the following error is shown:
> Syntax error in version string ROOT.TEST at position 0: Not a valid
> OSGi version
>
> Obviously Buckminster tries to get a version for tag ROOT_TEST and
> versionConverter fails to convert it to an OSGi version. In this
> scenario I would like to build either version 1.0.0, 2.0.0 or 3.0.0. The
> version associated with ROOT_TEST is of no interest.
> Removing the tag ROOT_TEST is not an option. If necessary a version
> could be assigned to that tag, however I would like to avoid that (and I
> don't know how to do that too), because then that would be required for
> any tag that might be added in the future.
>
> I am not 100% sure if this is a bug ;-) or if I am doing something
> wrong. Please advice.
>
The transformer will apply each pattern in succession. If more then one
pattern succeeds, the transformation is considered successful. Looking
at your pattern, you will recognize ROOT_TEST with the second toPattern
and hence produce an illegal version.
Try defining a more explicit pattern such as "^v(\d+)_(\d+)_(\d+)$" ->
"$1.$2.$3"
> I guess that is a bug, shall I file a bug report?
>
I don't think it's a bug but the behavior could be clearer. I think that
the version converter should be changed into behaving in one of two ways:
1. Match all transformers in succession, substituting the pattern for
each transformation and require that ALL transformations take place
(this is the behavior you probably thought it had). The tag would be
skipped as soon as one of the transformations fail.
2. Attempt to match each pattern in turn until one transformation takes
place and then stop. The tag would be skipped if no transformation takes
place.
What do you think about that?
> The versionConverter allows to specify a bidirectional mapping from
> version number to tag, where the information for the mapping is derived
> from the version number or the tag.
> What I really would like to do is to assign an arbitrary mapping between
> version number and tag. Like:
> Version 1.0.0 has tag v20080101
> Version 2.0.0 has tag v20080201
> Version 3.0.0 has tag v20080301
>
> Can this be achieved in the RMAP?
Certainly. Define a pattern like:
"^v20080(\d)01$" -> "$1.0.0"
and it's opposite:
"^(\d)\.0.0$" -> "v20080$101"
Regards,
Thomas Hallgren
|
|
|
| Re: How to materialize different versions of one component from CVS? [message #378551 is a reply to message #378548] |
Thu, 17 July 2008 06:38 |
Michael Pfeiffer
Messages: 34
Registered: July 2009 |
Member |
|
|
Hi Thomas!
Thomas Hallgren wrote:
> Michael Pfeiffer wrote:
> Try defining a more explicit pattern such as "^v(d+)_(d+)_(d+)$" ->
> "$1.$2.$3"
Thank you, that does the trick. It solves the "not valid OSGi version
problem".
To my excuse I used the example from WIKI and hoped it would just work,
without any further thinking :-)
You skipped that part of my previous post:
> If I replace the version type OSGi with type String in the CQUERY and RMAP.
I can materialize version 1.0.0. Doing the same for version 2.0.0 or 3.0.0
fails however with this error:
>
> [0001] : Rejecting provider
cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match was found
Fot this I asked if I should file a bug report.
After the pattern change from above, I am getting the same error with
version type OSGi too.
Here is a more detailed error log:
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using resolver rmap
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Rejecting provider
eclipse.platform(plugin/${buckminster.component}): No component match was
found
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using resource map
file:/C:/Work/BS/ws-buckminster-3.4/build/versiontest/versio n-test.rmap
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using search path
versionTest
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Trying provider
cvs(:pserver:lusaka.scch.at:/buckminstertest,{0})
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using version
converter tag. trunk/head will not be considered
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: tags will be searched
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Version null
rejected: versionSelector cannot make sense of it
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Version 1.0.0
rejected: not designated by [2.0.0,2.0.0]
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Rejecting provider
cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match was
found
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: No provider was found
that could resolve the request
ERROR [0001] : No suitable provider for component
at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi was found in
searchPath versionTest
ERROR [0001] : Rejecting provider
cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match was
found
>> I guess that is a bug, shall I file a bug report?
>>
> I don't think it's a bug but the behavior could be clearer. I think that
> the version converter should be changed into behaving in one of two ways:
> 1. Match all transformers in succession, substituting the pattern for
> each transformation and require that ALL transformations take place
> (this is the behavior you probably thought it had). The tag would be
> skipped as soon as one of the transformations fail.
> 2. Attempt to match each pattern in turn until one transformation takes
> place and then stop. The tag would be skipped if no transformation takes
> place.
> What do you think about that?
Can 2 already be achieved with the current behavior by using only
exclusive-or patterns (= no two patterns can match the same string)?
If that's the case then current behavior would be just fine for me.
>> The versionConverter allows to specify a bidirectional mapping from
>> version number to tag, where the information for the mapping is derived
>> from the version number or the tag.
>> What I really would like to do is to assign an arbitrary mapping between
>> version number and tag. Like:
>> Version 1.0.0 has tag v20080101
>> Version 2.0.0 has tag v20080201
>> Version 3.0.0 has tag v20080301
>>
>> Can this be achieved in the RMAP?
> Certainly. Define a pattern like:
> "^v20080(d)01$" -> "$1.0.0"
> and it's opposite:
> "^(d).0.0$" -> "v20080$101"
Sorry I provided a bad example. Here is a new one:
Version 1.0.0 has tag v20080216
Version 2.0.0 has tag v20080412
Version 3.0.0 has tag v20080617
The tags denote dates. So there is no way to derive the version from date
and vice versa.
I hope to understand the transformation behavior better now. Within the
versionConverter there would then be three transform elements with
patterns:
"^1.0.0$" -> "v20080216" and the opposite "^v20080216$" -> "1.0.0"
"^2.0.0$" -> "v20080412" and "^v20080412$" -> "2.0.0"
"^3.0.0$" -> "v20080617" and "^v20080617$" -> "3.0.0"
Is that right?
Kind Regards,
Michael
|
|
|
| Re: How to materialize different versions of one component from CVS? [message #378552 is a reply to message #378551] |
Thu, 17 July 2008 07:17 |
|
Michael Pfeiffer wrote:
> Hi Thomas!
>
> You skipped that part of my previous post:
>> If I replace the version type OSGi with type String in the CQUERY and
>> RMAP.
> I can materialize version 1.0.0. Doing the same for version 2.0.0 or
> 3.0.0 fails however with this error:
In order for a version to match, two criterias must be fulfilled.
1. The version type of the version designator is compatible with the
version type of the found component.
2. The version range of the designator designates the found version.
If you can materialize 1.0.0 but not the other versions, what did the
version designator of you original CQUERY look like?
> Fot this I asked if I should file a bug report. After the pattern change
> from above, I am getting the same error with version type OSGi too.
>
From the log that you provide here I can conclude that you search
explicitly for version 2.0.0 but only version 1.0.0 is found. It looks
like the other tags are not considered at all. If that's the case, then
yes, that's certainly a bug.
> Here is a more detailed error log:
>
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using resolver rmap
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Rejecting provider
> eclipse.platform(plugin/${buckminster.component}): No component match
> was found
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using resource map
> file:/C:/Work/BS/ws-buckminster-3.4/build/versiontest/versio n-test.rmap
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using search path
> versionTest
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Trying provider
> cvs(:pserver:lusaka.scch.at:/buckminstertest,{0})
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Using version
> converter tag. trunk/head will not be considered
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: tags will be searched
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Version null
> rejected: versionSelector cannot make sense of it
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Version 1.0.0
> rejected: not designated by [2.0.0,2.0.0]
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: Rejecting provider
> cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match
> was found
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi: No provider was
> found that could resolve the request
> ERROR [0001] : No suitable provider for component
> at.scch.version.test:osgi.bundle/[2.0.0,2.0.0]#OSGi was found in
> searchPath versionTest
> ERROR [0001] : Rejecting provider
> cvs(:pserver:lusaka.scch.at:/buckminstertest,{0}): No component match
> was found
> I hope to understand the transformation behavior better now. Within the
> versionConverter there would then be three transform elements with
> patterns:
> "^1.0.0$" -> "v20080216" and the opposite "^v20080216$" -> "1.0.0"
> "^2.0.0$" -> "v20080412" and "^v20080412$" -> "2.0.0"
> "^3.0.0$" -> "v20080617" and "^v20080617$" -> "3.0.0"
>
> Is that right?
>
Yes that sounds right. You need to escape the dots though, i.e. "^1\.0\.0$"
Regards,
Thomas Hallgren
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 14:30:52 GMT 2024
Powered by FUDForum. Page generated in 0.04110 seconds |
] 
Search
Help
Register
Login
Home
