Home » Eclipse Projects » Buckminster dev » [buckminster-dev] Making Buckminster understand SVN branching
| [buckminster-dev] Making Buckminster understand SVN branching [message #17010] |
Thu, 22 May 2008 15:05  |
 Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_5547_24205777.1211468739081
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi.
Let me describe the situation I have.
1) I've installed SVN repo on svn://localhost/repo/
2) In repository I've created such structure:
-- plA
-- branches
-- tags
-- trunk (here will be my plugin plA code)
-- plB
-- branches
-- tags
-- trunk (here will be my plugin plB code)
3) Then I create plugins in Eclipse and commit them to repository. I also
set that plB depends on plA with version range [1,0,0; 2,0,0] (default
versions for plugins on creation are 1.0.0)
4) I create RMAP:
<?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="default">
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/repo/{0}/trunk/">
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
</searchPath>
<locator searchPathRef="default" pattern="^.*" />
</rmap>
5) I create CQUERY:
<?xml version="1.0" encoding="UTF-8"?>
<cq:componentQuery
xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0"
resourceMap="<PATH TO MY RMAP>">
<cq:rootRequest name="plB" componentType="osgi.bundle"/>
</cq:componentQuery>
6) When I execute this query, everything is OK, I get plA and plB in my
workspace.
7) I decide to make some major changes in plA, so I follow Eclipse
versioning conceptions:
a) I create new branch under svn://localhost/repo/plA/branches/ with name
"R1.0.x"
b) Copy all plA trunk to this new branch
c) Change plA in trunk and modify it's version to 2.0.0
So the situations for now - I have two working copies of plA, one is R1.0.x
branch, other is trunk. Branch is 1.0.0 version, trunk is 2.0.0 version.
===== And now the problem occurs! =====
When i try to execute my CQUERY, I have an error (it's dumb SAX parser
error, but I understand it is because of not all dependencies can be
resolved - by the way, can anybody fix this issue to show READABLE
error-string? :) ). I understand the case of this error - my bundle plB
requieres plA of versions [1.0.0, 2.0.0), but only available plA in trunk is
2.0.0 version, which is not acceptable. So I understand, that Buckminster
cannot automatically search branches to seek for appropriate version?
I have found two workarounds for this issue:
1) I can create advisor node in my CQUERY named "plA" and set it's
"Selection Criteria -> Branch/Tag path" to "R1.0.x". This will make
Buckminster look for plA component only in this branch. This will fix the
issue, but I think is not proper solution for the problem.
2) I can add additional provider to my RMAP for each branch I want
Buckminster to include in component search:
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/repo/{0}/branches/R1.0.x/">
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
This works fine, and I think this is even logically fine (I tell Buckminster
what branches to search, and what to ignore), but it requires some handwork
to put this provider in RMAP after each release of plugin (assuming release
involves creating branch). This also has a problem: let's assume I've added
this provider to RMAP, knowing that plA has branch "R1.0.x". But this
provider will also work for all other components, trying to look at their's
branch "R1.0.x", which can even not exist. Of course I can fix this by
replacing "{0}" in URI with "plA" but... isn't it the same as listing all
available pairs component/branch in provider? Which I think is not a very
good practice.
So I wanted to know, is there any naming convention for branches to make
Buckminster automatically search components inside them without handwriting
them in RMAP?
Thanks.
------=_Part_5547_24205777.1211468739081
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
Content-Disposition: inline
SGkuPGJyPjxicj5MZXQgbWUgZGVzY3JpYmUgdGhlIHNpdHVhdGlvbiBJIGhh dmUuPGJyPjxicj4x
KSBJJiMzOTt2ZSBpbnN0YWxsZWQgU1ZOIHJlcG8gb24gc3ZuOi8vbG9jYWxo b3N0L3JlcG8vPGJy
Pjxicj4yKSBJbiByZXBvc2l0b3J5IEkmIzM5O3ZlIGNyZWF0ZWQgc3VjaCBz dHJ1Y3R1cmU6PGJy
Pjxicj4tLSBwbEE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gYnJh bmNoZXM8YnI+ICZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tIHRhZ3M8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7
LS0gdHJ1bmsgKGhlcmUgd2lsbCBiZSBteSBwbHVnaW4gcGxBIGNvZGUpPGJy PgotLSBwbEI8YnI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0gYnJhbmNoZXM8YnI+ICZuYnNw OyZuYnNwOyZuYnNw
OyZuYnNwOy0tIHRhZ3M8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS0g dHJ1bmsgKGhlcmUg
IHdpbGwgYmUgbXkgcGx1Z2luIHBsQiBjb2RlKTxicj48YnI+MykgVGhlbiBJ IGNyZWF0ZSBwbHVn
aW5zIGluIEVjbGlwc2UgYW5kIGNvbW1pdCB0aGVtIHRvIHJlcG9zaXRvcnku IEkgYWxzbyBzZXQg
dGhhdCBwbEIgZGVwZW5kcyBvbiBwbEEgd2l0aCB2ZXJzaW9uIHJhbmdlIFsx LDAsMDsgMiwwLDBd
IChkZWZhdWx0IHZlcnNpb25zIGZvciBwbHVnaW5zIG9uIGNyZWF0aW9uIGFy ZSAxLjAuMCk8YnI+
Cjxicj40KSBJIGNyZWF0ZSBSTUFQOjxicj48YnI+Jmx0Oz94bWwgdmVyc2lv bj0mcXVvdDsxLjAm
cXVvdDsgZW5jb2Rpbmc9JnF1b3Q7VVRGLTgmcXVvdDs/Jmd0Ozxicj4mbHQ7 cm1hcDxicj4JeG1s
bnM6eHNpPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEv WE1MU2NoZW1hLWlu
c3RhbmNlIj5odHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0 YW5jZTwvYT4mcXVv
dDs8YnI+Cgl4bWxucz0mcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3LmVjbGlw c2Uub3JnL2J1Y2tt
aW5zdGVyL1JNYXAtMS4wIj5odHRwOi8vd3d3LmVjbGlwc2Uub3JnL2J1Y2tt aW5zdGVyL1JNYXAt
MS4wPC9hPiZxdW90Ozxicj4JeG1sbnM6YmM9JnF1b3Q7PGEgaHJlZj0iaHR0 cDovL3d3dy5lY2xp
cHNlLm9yZy9idWNrbWluc3Rlci9Db21tb24tMS4wIj5odHRwOi8vd3d3LmVj bGlwc2Uub3JnL2J1
Y2ttaW5zdGVyL0NvbW1vbi0xLjA8L2E+JnF1b3Q7PGJyPgoJeG1sbnM6bXA9 JnF1b3Q7PGEgaHJl
Zj0iaHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9NYXZlblBy b3ZpZGVyLTEuMCI+
aHR0cDovL3d3dy5lY2xpcHNlLm9yZy9idWNrbWluc3Rlci9NYXZlblByb3Zp ZGVyLTEuMDwvYT4m
cXVvdDs8YnI+CXhtbG5zOnBwPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cu ZWNsaXBzZS5vcmcv
YnVja21pbnN0ZXIvUERFTWFwUHJvdmlkZXItMS4wIj5odHRwOi8vd3d3LmVj bGlwc2Uub3JnL2J1
Y2ttaW5zdGVyL1BERU1hcFByb3ZpZGVyLTEuMDwvYT4mcXVvdDsmZ3Q7PGJy Pgo8YnI+CSZsdDtz
ZWFyY2hQYXRoIG5hbWU9JnF1b3Q7ZGVmYXVsdCZxdW90OyZndDs8YnI+CQkm bmJzcDsmbmJzcDsm
bHQ7cHJvdmlkZXIgcmVhZGVyVHlwZT0mcXVvdDtzdm4mcXVvdDsgY29tcG9u ZW50VHlwZXM9JnF1
b3Q7ZWNsaXBzZS5mZWF0dXJlLG9zZ2kuYnVuZGxlLGJ1Y2ttaW5zdGVyJnF1 b3Q7Jmd0Ozxicj4J
CQkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7dXJpIGZvcm1hdD0mcXVv dDtzdm46Ly9sb2Nh
bGhvc3QvcmVwby97MH0vdHJ1bmsvJnF1b3Q7Jmd0Ozxicj4KCQkJCSZuYnNw OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtiYzpwcm9wZXJ0eVJlZiBrZXk9JnF1 b3Q7YnVja21pbnN0
ZXIuY29tcG9uZW50JnF1b3Q7IC8mZ3Q7PGJyPgkJCSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZs
dDsvdXJpJmd0Ozxicj4JCSZuYnNwOyZuYnNwOyZsdDsvcHJvdmlkZXImZ3Q7 PGJyPgkJJmx0Oy9z
ZWFyY2hQYXRoJmd0Ozxicj48YnI+CSZsdDtsb2NhdG9yIHNlYXJjaFBhdGhS ZWY9JnF1b3Q7ZGVm
YXVsdCZxdW90OyBwYXR0ZXJuPSZxdW90O14uKiZxdW90OyAvJmd0Ozxicj4K PGJyPiZsdDsvcm1h
cCZndDs8YnI+PGJyPjUpIEkgY3JlYXRlIENRVUVSWTo8YnI+PGJyPiZsdDs/ eG1sIHZlcnNpb249
JnF1b3Q7MS4wJnF1b3Q7IGVuY29kaW5nPSZxdW90O1VURi04JnF1b3Q7PyZn dDs8YnI+Jmx0O2Nx
OmNvbXBvbmVudFF1ZXJ5PGJyPnhtbG5zOmNxPSZxdW90OzxhIGhyZWY9Imh0 dHA6Ly93d3cuZWNs
aXBzZS5vcmcvYnVja21pbnN0ZXIvQ1F1ZXJ5LTEuMCI+aHR0cDovL3d3dy5l Y2xpcHNlLm9yZy9i
dWNrbWluc3Rlci9DUXVlcnktMS4wPC9hPiZxdW90Ozxicj4KcmVzb3VyY2VN YXA9JnF1b3Q7Jmx0
O1BBVEggVE8gTVkgUk1BUCZndDsmcXVvdDsmZ3Q7PGJyPiAgICAmbmJzcDsm bmJzcDsmbHQ7Y3E6
cm9vdFJlcXVlc3QgbmFtZT0mcXVvdDtwbEImcXVvdDsgY29tcG9uZW50VHlw ZT0mcXVvdDtvc2dp
LmJ1bmRsZSZxdW90Oy8mZ3Q7PGJyPiAgICAmbHQ7L2NxOmNvbXBvbmVudFF1 ZXJ5Jmd0Ozxicj48
YnI+NikgV2hlbiBJIGV4ZWN1dGUgdGhpcyBxdWVyeSwgZXZlcnl0aGluZyBp cyBPSywgSSBnZXQg
cGxBIGFuZCBwbEIgaW4gbXkgd29ya3NwYWNlLjxicj4KPGJyPjcpIEkgZGVj aWRlIHRvIG1ha2Ug
c29tZSBtYWpvciBjaGFuZ2VzIGluIHBsQSwgc28gSSBmb2xsb3cgRWNsaXBz ZSB2ZXJzaW9uaW5n
IGNvbmNlcHRpb25zOjxicj4mbmJzcDsmbmJzcDthKSBJIGNyZWF0ZSBuZXcg YnJhbmNoIHVuZGVy
Jm5ic3A7c3ZuOi8vbG9jYWxob3N0L3JlcG8vcGxBL2JyYW5jaGVzLyB3aXRo IG5hbWUgJnF1b3Q7
UjEuMC54JnF1b3Q7PGJyPiAmbmJzcDsmbmJzcDtiKSBDb3B5IGFsbCBwbEEg dHJ1bmsgdG8gdGhp
cyBuZXcgYnJhbmNoPGJyPgombmJzcDsmbmJzcDtjKSBDaGFuZ2UgcGxBIGlu IHRydW5rIGFuZCBt
b2RpZnkgaXQmIzM5O3MgdmVyc2lvbiB0byAyLjAuMDxicj48YnI+PGJyPlNv IHRoZSBzaXR1YXRp
b25zIGZvciBub3cgLSBJIGhhdmUgdHdvIHdvcmtpbmcgY29waWVzIG9mIHBs QSwgb25lIGlzIFIx
LjAueCBicmFuY2gsIG90aGVyIGlzIHRydW5rLiBCcmFuY2ggaXMgMS4wLjAg dmVyc2lvbiwgdHJ1
bmsgaXMgMi4wLjAgdmVyc2lvbi48YnI+Cjxicj49PT09PSBBbmQgbm93IHRo ZSBwcm9ibGVtIG9j
Y3VycyEgPT09PT08YnI+PGJyPldoZW4gaSB0cnkgdG8gZXhlY3V0ZSBteSBD UVVFUlksIEkgaGF2
ZSBhbiBlcnJvciAoaXQmIzM5O3MgZHVtYiBTQVggcGFyc2VyIGVycm9yLCBi dXQgSSB1bmRlcnN0
YW5kIGl0IGlzIGJlY2F1c2Ugb2Ygbm90IGFsbCBkZXBlbmRlbmNpZXMgY2Fu IGJlIHJlc29sdmVk
IC0gYnkgdGhlIHdheSwgY2FuIGFueWJvZHkgZml4IHRoaXMgaXNzdWUgdG8g c2hvdyBSRUFEQUJM
RSBlcnJvci1zdHJpbmc/IDopICkuIEkgdW5kZXJzdGFuZCB0aGUgY2FzZSBv ZiB0aGlzIGVycm9y
IC0gbXkgYnVuZGxlIHBsQiByZXF1aWVyZXMgcGxBIG9mIHZlcnNpb25zIFsx LjAuMCwgMi4wLjAp
LCBidXQgb25seSBhdmFpbGFibGUgcGxBIGluIHRydW5rIGlzIDIuMC4wIHZl cnNpb24sIHdoaWNo
IGlzIG5vdCBhY2NlcHRhYmxlLiBTbyBJIHVuZGVyc3RhbmQsIHRoYXQgQnVj a21pbnN0ZXIgY2Fu
bm90IGF1dG9tYXRpY2FsbHkgc2VhcmNoIGJyYW5jaGVzIHRvIHNlZWsgZm9y IGFwcHJvcHJpYXRl
IHZlcnNpb24/PGJyPgo8YnI+PGJyPkkgaGF2ZSBmb3VuZCB0d28gd29ya2Fy b3VuZHMgZm9yIHRo
aXMgaXNzdWU6PGJyPjxicj4xKSBJJm5ic3A7Y2FuIGNyZWF0ZSBhZHZpc29y IG5vZGUgaW4gbXkg
Q1FVRVJZIG5hbWVkICZxdW90O3BsQSZxdW90OyBhbmQgc2V0IGl0JiMzOTtz ICZxdW90O1NlbGVj
dGlvbiBDcml0ZXJpYSAtJmd0OyBCcmFuY2gvVGFnIHBhdGgmcXVvdDsgdG8g JnF1b3Q7UjEuMC54
JnF1b3Q7LiBUaGlzIHdpbGwgbWFrZSBCdWNrbWluc3RlciBsb29rIGZvciBw bEEgY29tcG9uZW50
IG9ubHkgaW4gdGhpcyBicmFuY2guIFRoaXMgd2lsbCBmaXggdGhlIGlzc3Vl LCBidXQgSSB0aGlu
ayBpcyBub3QgcHJvcGVyIHNvbHV0aW9uIGZvciB0aGUgcHJvYmxlbS4gPGJy Pgo8YnI+MikgSSBj
YW4gYWRkIGFkZGl0aW9uYWwgcHJvdmlkZXIgdG8gbXkgUk1BUCBmb3IgZWFj aCBicmFuY2ggSSB3
YW50IEJ1Y2ttaW5zdGVyIHRvIGluY2x1ZGUgaW4gY29tcG9uZW50IHNlYXJj aDo8YnI+PGJyPgkJ
Jmx0O3Byb3ZpZGVyIHJlYWRlclR5cGU9JnF1b3Q7c3ZuJnF1b3Q7IGNvbXBv bmVudFR5cGVzPSZx
dW90O2VjbGlwc2UuZmVhdHVyZSxvc2dpLmJ1bmRsZSxidWNrbWluc3RlciZx dW90OyZndDs8YnI+
CgkJCSZuYnNwOyZuYnNwOyZsdDt1cmkgZm9ybWF0PSZxdW90O3N2bjovL2xv Y2FsaG9zdC9yZXBv
L3swfS9icmFuY2hlcy9SMS4wLngvJnF1b3Q7Jmd0Ozxicj4JCQkJJm5ic3A7 Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jmx0O2JjOnByb3BlcnR5UmVmIGtleT0mcXVvdDtidWNrbWluc3Rl ci5jb21wb25lbnQm
cXVvdDsgLyZndDs8YnI+CQkJJm5ic3A7Jm5ic3A7Jmx0Oy91cmkmZ3Q7PGJy PgkJJmx0Oy9wcm92
aWRlciZndDs8YnI+PGJyPlRoaXMgd29ya3MgZmluZSwgYW5kIEkgdGhpbmsg dGhpcyBpcyBldmVu
IGxvZ2ljYWxseSBmaW5lIChJIHRlbGwgQnVja21pbnN0ZXIgd2hhdCBicmFu Y2hlcyB0byBzZWFy
Y2gsIGFuZCB3aGF0IHRvIGlnbm9yZSksIGJ1dCBpdCByZXF1aXJlcyBzb21l IGhhbmR3b3JrIHRv
IHB1dCB0aGlzIHByb3ZpZGVyIGluIFJNQVAgYWZ0ZXIgZWFjaCByZWxlYXNl IG9mIHBsdWdpbiAo
YXNzdW1pbmcgcmVsZWFzZSAgIGludm9sdmVzIGNyZWF0aW5nIGJyYW5jaCku IFRoaXMgYWxzbyBo
YXMgYSAgcHJvYmxlbTogbGV0JiMzOTtzIGFzc3VtZSBJJiMzOTt2ZSBhZGRl ZCB0aGlzIHByb3Zp
ZGVyIHRvIFJNQVAsIGtub3dpbmcgdGhhdCBwbEEgaGFzIGJyYW5jaCAmcXVv dDtSMS4wLngmcXVv
dDsuIEJ1dCB0aGlzIHByb3ZpZGVyIHdpbGwgYWxzbyB3b3JrIGZvciBhbGwg b3RoZXIgY29tcG9u
ZW50cywgdHJ5aW5nIHRvIGxvb2sgYXQgdGhlaXImIzM5O3MgYnJhbmNoICZx dW90O1IxLjAueCZx
dW90Oywgd2hpY2ggY2FuIGV2ZW4gbm90IGV4aXN0LiBPZiBjb3Vyc2UgSSBj YW4gZml4IHRoaXMg
YnkgcmVwbGFjaW5nICZxdW90O3swfSZxdW90OyBpbiBVUkkgd2l0aCAmcXVv dDtwbEEmcXVvdDsg
YnV0Li4uIGlzbiYjMzk7dCBpdCB0aGUgc2FtZSAgYXMgIGxpc3RpbmcgYWxs IGF2YWlsYWJsZSBw
YWlycyBjb21wb25lbnQvYnJhbmNoJm5ic3A7aW4gcHJvdmlkZXI/IFdoaWNo IEkgdGhpbmsgaXMg
bm90Jm5ic3A7YSB2ZXJ5IGdvb2QgcHJhY3RpY2UuIDxicj4KICA8YnI+U28g SSB3YW50ZWQgdG8g
a25vdywgaXMgdGhlcmUgYW55IG5hbWluZyBjb252ZW50aW9uIGZvciBicmFu Y2hlcyB0byBtYWtl
IEJ1Y2ttaW5zdGVyIGF1dG9tYXRpY2FsbHkgc2VhcmNoIGNvbXBvbmVudHMg aW5zaWRlIHRoZW0g
d2l0aG91dCBoYW5kd3JpdGluZyB0aGVtIGluIFJNQVA/PGJyPjxicj5UaGFu a3MuPGJyPgo=
------=_Part_5547_24205777.1211468739081--
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17070 is a reply to message #17010] |
Thu, 22 May 2008 18:04  |
|
Hi Mikhail,
You need to use the URI properties moduleBeforeBranch/moduleAfterBranch.
Consider this URI declaration:
<uri
format="svn://localhost/repo/{0}/trunk/{0}?moduleAfterTag&moduleAfterBranch">
<bc:propertyRef key="buckminster.component"/>
</uri>
Buckminster will treat everything after 'trunk' in the URI as the module
name so it will map your component name to it's notion of the module
name. When searching branches it will expand the above URI to:
svn://localhost/repo/{0}/branches/<your branch>/{0}
The branches should not be visible in your rmap. Instead, you use an
advisory node in the CQUERY that has a branch/tag path. This is a
comma-separated path of tokens. A token starting with a '/' is a tag and
all other tokens are branches.
There's a special token 'main' that translates to the trunk so if you
want Buckminster to search your R1.0.x branch first and then, if it
doesn't find the component there, continue with trunk, you can use a
branch/tag path like 'R1.0.x,main'
Regards,
Thomas Hallgren
Mikhail Kadan wrote:
> Hi.
>
> Let me describe the situation I have.
>
> 1) I've installed SVN repo on svn://localhost/repo/
>
> 2) In repository I've created such structure:
>
> -- plA
> -- branches
> -- tags
> -- trunk (here will be my plugin plA code)
> -- plB
> -- branches
> -- tags
> -- trunk (here will be my plugin plB code)
>
> 3) Then I create plugins in Eclipse and commit them to repository. I
> also set that plB depends on plA with version range [1,0,0; 2,0,0]
> (default versions for plugins on creation are 1.0.0)
>
> 4) I create RMAP:
>
> <?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="default">
> <provider readerType="svn"
> componentTypes="eclipse.feature,osgi.bundle,buckminster">
> <uri format="svn://localhost/repo/{0}/trunk/">
> <bc:propertyRef key="buckminster.component" />
> </uri>
> </provider>
> </searchPath>
>
> <locator searchPathRef="default" pattern="^.*" />
>
> </rmap>
>
> 5) I create CQUERY:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <cq:componentQuery
> xmlns:cq="http://www.eclipse.org/buckminster/CQuery-1.0"
> resourceMap="<PATH TO MY RMAP>">
> <cq:rootRequest name="plB" componentType="osgi.bundle"/>
> </cq:componentQuery>
>
> 6) When I execute this query, everything is OK, I get plA and plB in my
> workspace.
>
> 7) I decide to make some major changes in plA, so I follow Eclipse
> versioning conceptions:
> a) I create new branch under svn://localhost/repo/plA/branches/ with
> name "R1.0.x"
> b) Copy all plA trunk to this new branch
> c) Change plA in trunk and modify it's version to 2.0.0
>
>
> So the situations for now - I have two working copies of plA, one is
> R1.0.x branch, other is trunk. Branch is 1.0.0 version, trunk is 2.0.0
> version.
>
> ===== And now the problem occurs! =====
>
> When i try to execute my CQUERY, I have an error (it's dumb SAX parser
> error, but I understand it is because of not all dependencies can be
> resolved - by the way, can anybody fix this issue to show READABLE
> error-string? :) ). I understand the case of this error - my bundle plB
> requieres plA of versions [1.0.0, 2.0.0), but only available plA in
> trunk is 2.0.0 version, which is not acceptable. So I understand, that
> Buckminster cannot automatically search branches to seek for appropriate
> version?
>
>
> I have found two workarounds for this issue:
>
> 1) I can create advisor node in my CQUERY named "plA" and set it's
> "Selection Criteria -> Branch/Tag path" to "R1.0.x". This will make
> Buckminster look for plA component only in this branch. This will fix
> the issue, but I think is not proper solution for the problem.
>
> 2) I can add additional provider to my RMAP for each branch I want
> Buckminster to include in component search:
>
> <provider readerType="svn"
> componentTypes="eclipse.feature,osgi.bundle,buckminster">
> <uri format="svn://localhost/repo/{0}/branches/R1.0.x/">
> <bc:propertyRef key="buckminster.component" />
> </uri>
> </provider>
>
> This works fine, and I think this is even logically fine (I tell
> Buckminster what branches to search, and what to ignore), but it
> requires some handwork to put this provider in RMAP after each release
> of plugin (assuming release involves creating branch). This also has a
> problem: let's assume I've added this provider to RMAP, knowing that plA
> has branch "R1.0.x". But this provider will also work for all other
> components, trying to look at their's branch "R1.0.x", which can even
> not exist. Of course I can fix this by replacing "{0}" in URI with "plA"
> but... isn't it the same as listing all available pairs
> component/branch in provider? Which I think is not a very good practice.
>
> So I wanted to know, is there any naming convention for branches to make
> Buckminster automatically search components inside them without
> handwriting them in RMAP?
>
> Thanks.
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17157 is a reply to message #17010] |
Fri, 23 May 2008 07:07 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_7606_30985845.1211526447072
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi.
Thanks for quick answer.
As I understood, I have to provide list of branch names in advisor nodes to
make Buckminster search in this branches.
For example, let's see such repo structure:
-- plA
-- branches
-- R1.0.x (<1.0 code here>)
-- tags
-- trunk (<2.0 code here>)
So to make Buckminster search for code in trunk AND in R1.0.x branch, I can
create advisor node named "plA" with "branch/tag" set to "main,R1.0.x".
Another thing I want to know: is there some naming convention for this
branches, to make Buckminster AUTOMATICALLY search code in them, without
creating advisor node for this purpose?
Thanks.
------=_Part_7606_30985845.1211526447072
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi.<br>Thanks for quick answer.<br><br>As I understood, I have to provide list of branch names in advisor nodes to make Buckminster search in this branches.<br><br>For example, let's see such repo structure:<br><br>-- plA<br>
-- branches<br> -- R1.0.x (<1.0 code here>)<br> -- tags<br> -- trunk (<2.0 code here>)<br><br>So to make Buckminster search for code in trunk AND in R1.0.x branch, I can create advisor node named "plA" with "branch/tag" set to "main,R1.0.x".<br>
<br>Another thing I want to know: is there some naming convention for this branches, to make Buckminster AUTOMATICALLY search code in them, without creating advisor node for this purpose?<br> <br>Thanks.<br>
------=_Part_7606_30985845.1211526447072--
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17183 is a reply to message #17010] |
Fri, 23 May 2008 08:03 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_7675_3589747.1211529799521
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi.
Not sure what you mean by automatically here. Buckminster cannot guess what
> branches you have in mind and in what order they should be searched. You
> must specify this somewhere. You don't need to do it once for each component
> of course. You can create an advisory node that matches all components using
> the pattern '.*'.
>
By "automatically" I mean that it may be some naming convention for branches
to "mark" them for Buckminster to search.
For example, let's assume I have three branches for plA:
R1.0.x
R1.1.x
testNewAPI
If there is a naming convention saying "all branches that apply to pattern
RX.Y.x, where X and Y are numbers, must be included automatically into
search path", so the branches "R1.0.x" and "R1.1.x" (as they follow this
naming convention) will be included in search automatically, and branch
"testNewAPI" must be included manually.
As I understand, Buckminster has no such naming convention, so all branches
must be included manually. Is there a chance that such feature will be
implemented in future releases of Buckminster?
Thanks.
------=_Part_7675_3589747.1211529799521
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div><div>Hi.<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Not sure what you mean by automatically here. Buckminster cannot guess what branches you have in mind and in what order they should be searched. You must specify this somewhere. You don't need to do it once for each component of course. You can create an advisory node that matches all components using the pattern '.*'.<br>
</blockquote></div><br>By "automatically" I mean that it may be some naming convention for branches to "mark" them for Buckminster to search.<br><br>For example, let's assume I have three branches for plA:<br>
<br>R1.0.x<br>R1.1.x<br>testNewAPI<br><br>If there is a naming convention saying "all branches that apply to pattern RX.Y.x, where X and Y are numbers, must be included automatically into search path", so the branches "R1.0.x" and "R1.1.x" (as they follow this naming convention) will be included in search automatically, and branch "testNewAPI" must be included manually.<br>
<br>As I understand, Buckminster has no such naming convention, so all branches must be included manually. Is there a chance that such feature will be implemented in future releases of Buckminster?<br><br>Thanks.<br>
------=_Part_7675_3589747.1211529799521--
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17211 is a reply to message #17010] |
Fri, 23 May 2008 08:42 |
|
Mikhail Kadan wrote:
> Hi.
>
> Not sure what you mean by automatically here. Buckminster cannot
> guess what branches you have in mind and in what order they should
> be searched. You must specify this somewhere. You don't need to do
> it once for each component of course. You can create an advisory
> node that matches all components using the pattern '.*'.
>
>
> By "automatically" I mean that it may be some naming convention for
> branches to "mark" them for Buckminster to search.
>
> For example, let's assume I have three branches for plA:
>
> R1.0.x
> R1.1.x
> testNewAPI
>
> If there is a naming convention saying "all branches that apply to
> pattern RX.Y.x, where X and Y are numbers, must be included
> automatically into search path", so the branches "R1.0.x" and "R1.1.x"
> (as they follow this naming convention) will be included in search
> automatically, and branch "testNewAPI" must be included manually.
>
Aha, yes. Buckminster can do branch/tag name to version conversion. I.e.
it can extract the component version from a branch or tag name rather
then from the meta-data of the component. You can create a provider that
uses a <versionConverter> element. It uses two regexp substitutions, one
to translate the branch to a version and one to do the opposite.
Buckminster will then make an attempt to find the highest version. When
this scheme is used, you don't use the branch/tag path and you don't use
the trunk.
You can find more information here:
http://wiki.eclipse.org/Buckminster_component_meta-data_lang uage_%28Reference%29_-_LATEST#VersionConverter_component
Regards,
Thomas Hallgren
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17270 is a reply to message #17010] |
Fri, 23 May 2008 10:02 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_7911_27172455.1211536936469
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
>
> Aha, yes. Buckminster can do branch/tag name to version conversion. I.e. it
> can extract the component version from a branch or tag name rather then from
> the meta-data of the component. You can create a provider that uses a
> <versionConverter> element. It uses two regexp substitutions, one to
> translate the branch to a version and one to do the opposite. Buckminster
> will then make an attempt to find the highest version. When this scheme is
> used, you don't use the branch/tag path and you don't use the trunk.
>
I've played a bit with this stuff, and made something like:
<searchPath name="default">
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/test/{0}/trunk/">
<bc:propertyRef key="buckminster.component" />
</uri>
<versionConverter type="branch">
<transform
fromPattern="^(\d)+\.(\d)+\..*$"
fromReplacement="R$1\.$2\.x"
toPattern="^R(\d)+\.(\d)+\.x$"
toReplacement="$1\.$2\.0" />
</versionConverter>
</provider>
</searchPath>
This, I think, correctly maps component version "X.Y.Z" to branch name
"RX.Y.x" (f.e. "3.2.7" to "R3.2.x") and vice versa (the third number in
version string is assumed to be 0).
And now it completely ignores my "trunk", so I have to do head development
in a branch named according to my current version (something like "R2.7.x")
:) Is there some way to teach Buckminster to look into my "trunk" also?
------=_Part_7911_27172455.1211536936469
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Aha, yes. Buckminster can do branch/tag name to version conversion. I.e. it can extract the component version from a branch or tag name rather then from the meta-data of the component. You can create a provider that uses a <versionConverter> element. It uses two regexp substitutions, one to translate the branch to a version and one to do the opposite. Buckminster will then make an attempt to find the highest version. When this scheme is used, you don't use the branch/tag path and you don't use the trunk.<br>
</blockquote></div><br>I've played a bit with this stuff, and made something like:<br><br> <searchPath name="default"><br> <provider readerType="svn" componentTypes="eclipse.feature,osgi.bundle,buckmin ster"> <br>
<uri format="svn://localhost/test/{0}/trunk/"><br> <bc:propertyRef key="buckminster.component" /><br> </uri> <br> <versionConve rter type="branch"><br>
<transform <br> fromPattern="^(\d)+\.(\d)+\..*$ " <br> fromReplacement="R$1\.$2\.x& ;quot; <br> toPattern="^R(\d)+\.(\d)+\.x$&a mp;quot; <br> toReplacement="$1\.$2\.0&qu ot; /><br>
</versionConv erter> <br> </provider><br> </searchPath><br><br>This, I think, correctly maps component version "X.Y.Z" to branch name "RX.Y.x" (f.e. "3.2.7" to "R3.2.x") and vice versa (the third number in version string is assumed to be 0).<br>
<br>And now it completely ignores my "trunk", so I have to do head development in a branch named according to my current version (something like "R2.7.x") :) Is there some way to teach Buckminster to look into my "trunk" also?<br>
------=_Part_7911_27172455.1211536936469--
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17297 is a reply to message #17010] |
Fri, 23 May 2008 10:37 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_7971_9943747.1211539079145
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sorry, I was to fast to write previous letter.
1) I've solved a promlem with "trunk" - I've just added another provider on
top of my SearchPath with "trunk" resolution, so now it is:
<searchPath name="default">
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/test/{0}/trunk/">
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/test/{0}/trunk/">
<bc:propertyRef key="buckminster.component" />
</uri>
<versionConverter type="branch">
<transform
fromPattern="^(\d)+\.(\d)+\..*$" fromReplacement="R$1\.$2\.x"
toPattern="^R(\d)+\.(\d)+\.x$" toReplacement="$1\.$2\.0" />
</versionConverter>
</provider>
</searchPath>
2) But I've found another problem. When I try to execute CQUERY without
specifying exact version of component, it resolves well. But when I specify
version of component, it failes.
For example:
My SearchPath:
<searchPath name="default">
<provider readerType="svn"
componentTypes="eclipse.feature,osgi.bundle,buckminster">
<uri format="svn://localhost/test/{0}/trunk/">
<bc:propertyRef key="buckminster.component" />
</uri>
<versionConverter type="branch">
<transform
fromPattern="^(\d)+\.(\d)+\..*$" fromReplacement="R$1\.$2\.x"
toPattern="^R(\d)+\.(\d)+\.x$" toReplacement="$1\.$2\.0" />
</versionConverter>
</provider>
</searchPath>
My CQUERY:
<cq:componentQuery>
<cq:rootRequest name="plA" componentType="osgi.bundle"/>
</cq:componentQuery>
It resolves perfectly to R1.0.x branch, which contains 1.0.0 version of
component.
But when I specify in my CQUERY that I need version 1.0.0 EXPLICITLY,
resolution failes:
<cq:componentQuery>
<cq:rootRequest name="plA" componentType="osgi.bundle"
versionDesignator="[1.0.0,1.0.0]" versionType="OSGi"/>
</cq:componentQuery>
I've tried to provide "versionDesignator" in different forms, but none of it
worked. I've also tried to make simple version->branch replacion (w/o any
regexps, just 1.0.0 version transforms to 1.0.0 branch), I thought maybe I
have some mistake in regexps, but it didn't help. Can you help me to solve
this matter?
Thanks.
------=_Part_7971_9943747.1211539079145
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sorry, I was to fast to write previous letter.<br><br>1) I've solved a promlem with "trunk" - I've just added another provider on top of my SearchPath with "trunk" resolution, so now it is: <br>
<br> <searchPath name="default"><br><br> <provider readerType="svn" componentTypes="eclipse.feature,osgi.bundle,buckmin ster"> <br> <uri format="svn://localhost/test/{0}/trunk/"><br>
<bc:propertyR ef key="buckminster.component" /><br> </uri><br> </provider><br><br> <provider readerType="svn" componentTypes="eclipse.feature,osgi.bundle,buckmin ster"> <br>
<uri format="svn://localhost/test/{0}/trunk/"><br> <bc:propertyR ef key="buckminster.component" /><br> </uri><br> <versionConverter type="branch"><br>
<transform<br > fromPattern="^(\d)+\.(\d)+\..*$" fromReplacement="R$1\.$2\.x"<br> toPattern="^R(\d)+\.(\d)+\.x$" toReplacement="$1\.$2\.0" /><br> </versionConv erter> <br>
</provider><br><br></searchPath> <br><br><br>2) But I've found another problem. When I try to execute CQUERY without specifying exact version of component, it resolves well. But when I specify version of component, it failes.<br>
<br>For example:<br><br>My SearchPath:<br><br><searchPath name="default"><br><br><provider readerType="svn" componentTypes="eclipse.feature,osgi.bundle,buckmin ster"> <br> <uri format="svn://localhost/test/{0}/trunk/"><br>
<bc:propertyR ef key="buckminster.component" /><br> </uri><br> <versionConverter type="branch"><br> <transform<br > fromPattern="^(\d)+\.(\d)+\..*$" fromReplacement="R$1\.$2\.x"<br>
toPattern="^R(\d)+\.(\d)+\.x$" toReplacement="$1\.$2\.0" /><br> </versionConv erter> <br> </provider><br><br></searchPath> <br><br>My CQUERY:<br><br><cq:componentQuery><br>
<cq:rootRequest name="plA" componentType="osgi.bundle"/><br></cq:componentQuery> <br><br>It resolves perfectly to R1.0.x branch, which contains 1.0.0 version of component.<br><br>But when I specify in my CQUERY that I need version 1.0.0 EXPLICITLY, resolution failes:<br>
<br><cq:componentQuery><br> <cq:rootRequest name="plA" componentType="osgi.bundle" versionDesignator="[1.0.0,1.0.0]" versionType="OSGi"/><br></cq:componentQuery> <br>
<br>I've tried to provide "versionDesignator" in different forms, but none of it worked. I've also tried to make simple version->branch replacion (w/o any regexps, just 1.0.0 version transforms to 1.0.0 branch), I thought maybe I have some mistake in regexps, but it didn't help. Can you help me to solve this matter?<br>
<br>Thanks.<br><br> <br>
------=_Part_7971_9943747.1211539079145--
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17346 is a reply to message #17270] |
Fri, 23 May 2008 11:01 |
|
Mikhail Kadan wrote:
> I've played a bit with this stuff, and made something like:
>
> <searchPath name="default">
> <provider readerType="svn"
> componentTypes="eclipse.feature,osgi.bundle,buckminster">
> <uri format="svn://localhost/test/{0}/trunk/">
> <bc:propertyRef key="buckminster.component" />
> </uri>
> <versionConverter type="branch">
> <transform
> fromPattern="^(\d)+\.(\d)+\..*$"
> fromReplacement="R$1\.$2\.x"
> toPattern="^R(\d)+\.(\d)+\.x$"
> toReplacement="$1\.$2\.0" />
> </versionConverter>
> </provider>
> </searchPath>
>
> This, I think, correctly maps component version "X.Y.Z" to branch name
> "RX.Y.x" (f.e. "3.2.7" to "R3.2.x") and vice versa (the third number in
> version string is assumed to be 0).
>
Yes, this looks OK to me too.
> And now it completely ignores my "trunk", so I have to do head
> development in a branch named according to my current version (something
> like "R2.7.x") :) Is there some way to teach Buckminster to look into my
> "trunk" also?
Not at the same time, no. Version converters will always exclude the
trunk since it cannot be said to represent any particular version.
- thomas
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17373 is a reply to message #17297] |
Fri, 23 May 2008 11:43 |
|
Mikhail Kadan wrote:
> Sorry, I was to fast to write previous letter.
>
> 1) I've solved a promlem with "trunk" - I've just added another provider
> on top of my SearchPath with "trunk" resolution, so now it is:
>
Of course. Why didn't I think of that :-)
> 2) But I've found another problem. When I try to execute CQUERY without
> specifying exact version of component, it resolves well. But when I
> specify version of component, it failes.
>
> For example:
>
> My SearchPath:
>
> <searchPath name="default">
>
> <provider readerType="svn"
> componentTypes="eclipse.feature,osgi.bundle,buckminster">
> <uri format="svn://localhost/test/{0}/trunk/">
> <bc:propertyRef key="buckminster.component" />
> </uri>
> <versionConverter type="branch">
> <transform
> fromPattern="^(\d)+\.(\d)+\..*$" fromReplacement="R$1\.$2\.x"
> toPattern="^R(\d)+\.(\d)+\.x$" toReplacement="$1\.$2\.0" />
> </versionConverter>
> </provider>
>
> </searchPath>
>
> My CQUERY:
>
> <cq:componentQuery>
> <cq:rootRequest name="plA" componentType="osgi.bundle"/>
> </cq:componentQuery>
>
> It resolves perfectly to R1.0.x branch, which contains 1.0.0 version of
> component.
>
> But when I specify in my CQUERY that I need version 1.0.0 EXPLICITLY,
> resolution failes:
>
> <cq:componentQuery>
> <cq:rootRequest name="plA" componentType="osgi.bundle"
> versionDesignator="[1.0.0,1.0.0]" versionType="OSGi"/>
> </cq:componentQuery>
>
> I've tried to provide "versionDesignator" in different forms, but none
> of it worked. I've also tried to make simple version->branch replacion
> (w/o any regexps, just 1.0.0 version transforms to 1.0.0 branch), I
> thought maybe I have some mistake in regexps, but it didn't help. Can
> you help me to solve this matter?
>
I can't see anything wrong with what you're doing. Can you please set
the Buckminster preferences:
"Console logger level" >= DEBUG
"Maximum number of resolver threads" >= 1
and then run and let me have a look at the output? Feel free to send it
to my private email if you don't want to expose it here.
- thomas
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #17390 is a reply to message #17297] |
Fri, 23 May 2008 12:33 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_8097_7546373.1211546028324
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Here it is:
registered serializer org.jabsorb.serializer.impl.RawJSONArraySerializer
registered serializer org.jabsorb.serializer.impl.RawJSONObjectSerializer
registered serializer org.jabsorb.serializer.impl.BeanSerializer
registered serializer org.jabsorb.serializer.impl.ArraySerializer
registered serializer org.jabsorb.serializer.impl.DictionarySerializer
registered serializer org.jabsorb.serializer.impl.MapSerializer
registered serializer org.jabsorb.serializer.impl.SetSerializer
registered serializer org.jabsorb.serializer.impl.ListSerializer
registered serializer org.jabsorb.serializer.impl.DateSerializer
registered serializer org.jabsorb.serializer.impl.StringSerializer
registered serializer org.jabsorb.serializer.impl.NumberSerializer
registered serializer org.jabsorb.serializer.impl.BooleanSerializer
registered serializer org.jabsorb.serializer.impl.PrimitiveSerializer
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using
resolver rmap
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Rejecting provider eclipse.platform(plugin/${buckminster.component}): No
component match was found
blocked(class org.eclipse.core.internal.events.AutoBuildJob[Building
workspace])
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using
resource map file:/C:/Work/workspaces/bm-test/bm/default.rmap
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using
search path default
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Trying provider svn(svn://192.168.93.3/GO3/test/{0}/trunk/)
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
trunk/head will be searched
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /trunk#HEAD
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Version 2.0.0 rejected: not designated by [1.0.0,1.0.0]
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Rejecting provider svn(svn://192.168.93.3/GO3/test/{0}/trunk/): No component
match was found
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Trying provider svn(svn://192.168.93.3/GO3/test/{0}/trunk/)
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using
version converter branch. trunk/head will not be considered
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
branches will be searched
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches#HEAD
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/1.0.0#8295
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/teamwork#8295
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Version teamwork rejected: not designated by [1.0.0,1.0.0]
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Rejecting provider svn(svn://192.168.93.3/GO3/test/{0}/trunk/): No component
match was found
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: No
provider was found that could resolve the request
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using
resolver cloudsmith
Starting query...
marshall class [B
looking for serializer - java:[B json:null
direct match serializer org.jabsorb.serializer.impl.StringSerializer
Sending: {
"params":
[" H4sIAAAAAAAAAMWTT2+bQBDFvwri2i6LIRiDQnJw1KoHN2rrqoeqh9llwCvv H7y7xPG37wZbUdz44Fs5LBLMj/fmzXB7/6xk9ITWCaObeJakcYSam1bovol/ rj+RRXx/d6vamgkpH7sVeLQCpIsCp12t2ibeeD/UlO73+wS5FIPDxNiespFv ldAuAHSFHh7AA5kEvBm+mha/BPam66qCdTOymHVA8m6OBMoFkC6DgrU55imb xxE3ajAatf82oj28cGVepGXFkNxknJG8ZBWBoqxIycuqKxibI0AQEgqdBzU0 cZamC5IWJMvXs6zOqrrIkrzMP6ThiqcGRbu3MAxoI3GtwMSdmzvlwndX5bKc mGMqFp0ZLccVBLudkFjTZU1/Gbul+3C4ATg6yhTxoadwpy12MEqfWAVDsMJ3 tTXGf8fdGAoiDQqbOJhLepPgcwhBYvJGO2EWNN8k3Fh8k/D6MATMuF6EYt3K 8O60HQ/oRK/BG9vEv4PjJP04nX9eK47s44/PIqaTn8GakKc/RFs8NPHSaGck RtL0fUhZ4hPKwIIcAzW7iKzgWahRRXpULCCmm1KSQS/yG4vQuvMP0HfzOD57 ne2FSV+1ghM36pN6+7K+58P//3nTCw7/6Z2+/4/v/gI8CmqMAgQAAA== "],
"id": 1,
"method": "resolutionService.fireBomResolution"
}
Query started, waiting for reply...
Sending: {
"params": [],
"id": 1,
"method": "resolutionService.getProgressInfo"
}
looking for serializer - java:org.eclipse.buckminster.remote.ProgressInfo
json:org.json.JSONObject
search found serializer org.jabsorb.serializer.impl.BeanSerializer
instantiating org.eclipse.buckminster.remote.ProgressInfo
invoking setMessage(null)
looking for serializer - java:boolean json:java.lang.Boolean
direct match serializer org.jabsorb.serializer.impl.BooleanSerializer
invoking setDone(true)
looking for serializer - java:int json:java.lang.Integer
direct match serializer org.jabsorb.serializer.impl.PrimitiveSerializer
invoking setWorked(0)
Getting query result...
Sending: {
"params": [],
"id": 1,
"method": "resolutionService.getResolutionResult"
}
Sending: {
"params": [],
"id": 1,
"method": "resolutionService.logout"
}
I see such lines in it:
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches#HEAD
Listing remote folder svn://
192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/1.0.0#8295
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi:
Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]
I guess it's the place where my 1.0.0 branch is rejected, because "Version
1.0.0 rejected: not designated by [1.0.0,1.0.0]". Interesting :)
------=_Part_8097_7546373.1211546028324
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Here it is:<br><br>registered serializer org.jabsorb.serializer.impl.RawJSONArraySerializer<br>registered serializer org.jabsorb.serializer.impl.RawJSONObjectSerializer<br>registered serializer org.jabsorb.serializer.impl.BeanSerializer<br>
registered serializer org.jabsorb.serializer.impl.ArraySerializer<br>registered serializer org.jabsorb.serializer.impl.DictionarySerializer<br>registered serializer org.jabsorb.serializer.impl.MapSerializer<br>registered serializer org.jabsorb.serializer.impl.SetSerializer<br>
registered serializer org.jabsorb.serializer.impl.ListSerializer<br>registered serializer org.jabsorb.serializer.impl.DateSerializer<br>registered serializer org.jabsorb.serializer.impl.StringSerializer<br>registered serializer org.jabsorb.serializer.impl.NumberSerializer<br>
registered serializer org.jabsorb.serializer.impl.BooleanSerializer<br>registered serializer org.jabsorb.serializer.impl.PrimitiveSerializer<br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using resolver rmap<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Rejecting provider eclipse.platform(plugin/${buckminster.component}): No component match was found<br>blocked(class org.eclipse.core.internal.events.AutoBuildJob[Building workspace])<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using resource map file:/C:/Work/workspaces/bm-test/bm/default.rmap<br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using search path default<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Trying provider svn(svn://<a href="http://192.168.93.3/GO3/test/{0}/trunk/">192.168.93.3/GO3/test/{0}/trunk/</a>)<br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: trunk/head will be searched<br>
Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/trunk#HEAD"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /trunk#HEAD </a><br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Version 2.0.0 rejected: not designated by [1.0.0,1.0.0]<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Rejecting provider svn(svn://<a href="http://192.168.93.3/GO3/test/{0}/trunk/">192.168.93.3/GO3/test/{0}/trunk/</a>): No component match was found<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Trying provider svn(svn://<a href="http://192.168.93.3/GO3/test/{0}/trunk/">192.168.93.3/GO3/test/{0}/trunk/</a>)<br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using version converter branch. trunk/head will not be considered<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: branches will be searched<br>Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/branches#HEAD"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches#HEAD </a><br>
Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/branches/1.0.0#8295"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/1.0.0#8295 </a><br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]<br>
Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/branches/teamwork#8295"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/teamwork#8295 </a><br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Version teamwork rejected: not designated by [1.0.0,1.0.0]<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Rejecting provider svn(svn://<a href="http://192.168.93.3/GO3/test/{0}/trunk/">192.168.93.3/GO3/test/{0}/trunk/</a>): No component match was found<br>
com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: No provider was found that could resolve the request<br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Using resolver cloudsmith<br>
Starting query...<br>marshall class [B<br>looking for serializer - java:[B json:null<br>direct match serializer org.jabsorb.serializer.impl.StringSerializer<br>Sending: {<br> "params": ["H4sIAAAAAAAAAMWTT2+bQBDFvwri2i6LIRiDQnJw1KoHN2rrq oeqh9llwCvvH7y7xPG37wZbUdz44Fs5LBLMj/fmzXB7/6xk9ITWCaObeJakc YSam1bovol/rj+RRXx/d6vamgkpH7sVeLQCpIsCp12t2ibeeD/UlO73+wS5F IPDxNiespFvldAuAHSFHh7AA5kEvBm+mha/BPam66qCdTOymHVA8m6OBMoFk C6DgrU55imbxxE3ajAatf82oj28cGVepGXFkNxknJG8ZBWBoqxIycuqKxibI 0AQEgqdBzU0cZamC5IWJMvXs6zOqrrIkrzMP6ThiqcGRbu3MAxoI3GtwMSdm zvlwndX5bKcmGMqFp0ZLccVBLudkFjTZU1/Gbul+3C4ATg6yhTxoadwpy12M EqfWAVDsMJ3tTXGf8fdGAoiDQqbOJhLepPgcwhBYvJGO2EWNN8k3Fh8k/D6M ATMuF6EYt3K8O60HQ/oRK/BG9vEv4PjJP04nX9eK47s44/PIqaTn8GakKc/R Fs8NPHSaGckRtL0fUhZ4hPKwIIcAzW7iKzgWahRRXpULCCmm1KSQS/yG4vQu vMP0HfzOD57ne2FSV+1ghM36pN6+7K+58P//3nTCw7/6Z2+/4/v/gI8CmqMA gQAAA=="], <br>
"id": 1,<br> "method": "resolutionService.fireBomResolution"<br>} <br>Query started, waiting for reply...<br>Sending: {<br> "params": [],<br> "id": 1,<br> "method": "resolutionService.getProgressInfo"<br>
}<br>looking for serializer - java:org.eclipse.buckminster.remote.ProgressInfo json:org.json.JSONObject<br>search found serializer org.jabsorb.serializer.impl.BeanSerializer<br>instantiating org.eclipse.buckminster.remote.ProgressInfo<br>
invoking setMessage(null)<br>looking for serializer - java:boolean json:java.lang.Boolean<br>direct match serializer org.jabsorb.serializer.impl.BooleanSerializer<br>invoking setDone(true)<br>looking for serializer - java:int json:java.lang.Integer<br>
direct match serializer org.jabsorb.serializer.impl.PrimitiveSerializer<br>invoking setWorked(0)<br>Getting query result...<br>Sending: {<br> "params": [],<br> "id": 1,<br> "method": "resolutionService.getResolutionResult"<br >
}<br>Sending: {<br> "params": [],<br> "id": 1,<br> "method": "resolutionService.logout"<br>}<br><br ><br><br>I see such lines in it:<br><br>Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/branches#HEAD"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches#HEAD </a><br>
Listing remote folder svn://<a href=" http://192.168.93.3/GO3/test/com.go.example.buckminster.bran ch.core/branches/1.0.0#8295"> 192.168.93.3/GO3/test/com.go.example.buckminster.branch.core /branches/1.0.0#8295 </a><br> com.go.example.buckminster.branch.core:osgi.bundle/[1.0.0,1. 0.0]#OSGi: Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]<br>
<br>I guess it's the place where my 1.0.0 branch is rejected, because "Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]". Interesting :) <br>
------=_Part_8097_7546373.1211546028324--
|
|
| |
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #18656 is a reply to message #18634] |
Fri, 23 May 2008 14:20 |
|
Hi Mikhail,
The bug is in the documentation. Please try and add versionType="OSGi"
to your <versionConverter> element. The type defaults to "String" and
that type is not comparable with an OSGi version.
Regards,
Thomas Hallgren
Thomas Hallgren wrote:
> Mikhail Kadan wrote:
>>
>> I guess it's the place where my 1.0.0 branch is rejected, because
>> "Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]". Interesting :)
>>
> Very. I'll have to look into that. My guess is that there's some
> confusion with version types. Would you mind entering a bugzilla on this
> please?
>
> - thomas
>
|
|
|
| Re: [buckminster-dev] Making Buckminster understand SVN branching [message #18679 is a reply to message #18656] |
Fri, 23 May 2008 14:35 |
Mikhail Kadan
Messages: 61
Registered: July 2009 |
Member |
|
|
------=_Part_8484_1146734.1211553300605
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Thank you very much, this worked just fine.
ps I've almost reported a bug, if you would answered minute or two later...
:-)
2008/5/23, Thomas Hallgren <thomas@tada.se>:
>
> Hi Mikhail,
> The bug is in the documentation. Please try and add versionType="OSGi" to
> your <versionConverter> element. The type defaults to "String" and that type
> is not comparable with an OSGi version.
>
> Regards,
> Thomas Hallgren
>
> Thomas Hallgren wrote:
>
>> Mikhail Kadan wrote:
>>
>>>
>>> I guess it's the place where my 1.0.0 branch is rejected, because
>>> "Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]". Interesting :)
>>>
>>>
>> Very. I'll have to look into that. My guess is that there's some confusion
>> with version types. Would you mind entering a bugzilla on this please?
>>
>> - thomas
>>
>>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
------=_Part_8484_1146734.1211553300605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>Thank you very much, this worked just fine.</div>
<div> </div>
<div>ps I've almost reported a bug, if you would answered minute or two later... :-)<br><br> </div>
<div><span class="gmail_quote">2008/5/23, Thomas Hallgren <<a href="mailto:thomas@tada.se">thomas@tada.se</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Mikhail,<br>The bug is in the documentation. Please try and add versionType="OSGi" to your <versionConverter> element. The type defaults to "String" and that type is not comparable with an OSGi version.<br>
<br>Regards,<br>Thomas Hallgren<br><br>Thomas Hallgren wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span class="q">Mikhail Kadan wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>I guess it's the place where my 1.0.0 branch is rejected, because "Version 1.0.0 rejected: not designated by [1.0.0,1.0.0]". Interesting :)<br>
<br></blockquote></span>Very. I'll have to look into that. My guess is that there's some confusion with version types. Would you mind entering a bugzilla on this please?<br><br>- thomas<br><br></blockquote>
<div><span class="e" id="q_11a1626c722da71d_3"><br>_______________________________________________ <br>buckminster-dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:buckminster-dev@eclipse.org" target="_blank">buckminster-dev@eclipse.org</a><br>
<a onclick="return top.js.OpenExtLink(window,event,this)" href="https://dev.eclipse.org/mailman/listinfo/buckminster-dev" target="_blank">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a><br></span></div></blockquote>
</div><br>
------=_Part_8484_1146734.1211553300605--
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 02:12:26 GMT 2024
Powered by FUDForum. Page generated in 0.03489 seconds |
] 
Search
Help
Register
Login
Home
