Bug on cave:repository-update?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug on cave:repository-update?

Massimo Bono
Hi,

I was tweaking with apache:cave and i stumble across an interesting behavior.

1) I've created a repository and populate it with some artifacts (via cave:repository-create -l);
2) I then created new artifacts and I have manually copied them within the repository.
3) I then run cave:repository-update <repository_name> to refresh the repository.xml file

To my surprise, lots of resources have been duplicated: while before the "repository-update" the resources were accessible through one http URI, after the update the resources were accessible through one http URI and via one file URI.
If I try to deploy a bundle with multiple URI within the repository.xml the obr:deploy command does not deploy anything. If I try to access to the bundle via web browser with the http URI I obtain Error 500 Resource not found.

I found a workaround to this "interesting feature" as well:

1) Open the repository associated file repository.xml and annotate the attributes of "repository" tag;
2) Delete the repository.xml file;
3) Create the file again;
4) Add in such file the string "<repository name="REPOSITORY_NAME" increment="INCREMENT"></repository>" where "REPOSITORY_NAME" and "INCREMENT" are the values you have look at in the first step;
5) run cave:repository-update REPOSITORY_NAME

Everything should run smoothly now.

Now, maybe it's feature, I don't know, but I think it's not obvious that cave:repository-update can lead to duplicate entries in the repository.xml file.

Another note while I was digging into this behaviour: I found that the "repository-update" command hides a call of CaveReposiitory.scan(): here the javadoc of this interface method is, at least in my opinion, wrong: it says: "Scan the whole repository, reading bundle MANIFEST, ect to update or generate the repository.xml" (enphasis mine).
However, cave:repository-update will fail if the file is deleted from the filesystem, hence the workaround.

Finally, my setup:

OBR SERVER:
Operating system: Raspian buster 10
Apache karaf hosting cave: 4.2.6
Apache cave: 4.1.2

OBR CLIENT:
Apache karaf where bundles will be deployed: 4.2.6
Operating system: Ubuntu 18.04

Best Regards,

--
Ing. Massimo Bono
Reply | Threaded
Open this post in threaded view
|

Re: Bug on cave:repository-update?

jbonofre
Hi Massimo,

I would recommend to wait Cave 4.2.0 where Cave has completely changed
with a full refactoring:

https://github.com/apache/karaf-cave/pull/27

I plan to merge the PR later today and cut Cave 4.2.0 soon (probably
during the weekend).

Cave will be simpler, first Maven focus, and the repository.xml
generation will only use local artifacts.

Regards
JB

On 17/10/2019 23:04, Massimo Bono wrote:

> Hi,
>
> I was tweaking with apache:cave and i stumble across an interesting
> behavior.
>
> 1) I've created a repository and populate it with some artifacts (via
> cave:repository-create -l);
> 2) I then created new artifacts and I have manually copied them within
> the repository.
> 3) I then run cave:repository-update <repository_name> to refresh the
> repository.xml file
>
> To my surprise, lots of resources have been duplicated: while before the
> "repository-update" the resources were accessible through one http URI,
> after the update the resources were accessible through one http URI and
> via one file URI.
> If I try to deploy a bundle with multiple URI within the repository.xml
> the obr:deploy command does not deploy anything. If I try to access to
> the bundle via web browser with the http URI I obtain Error 500 Resource
> not found.
>
> I found a workaround to this "interesting feature" as well:
>
> 1) Open the repository associated file repository.xml and annotate the
> attributes of "repository" tag;
> 2) Delete the repository.xml file;
> 3) Create the file again;
> 4) Add in such file the string "<repository name="REPOSITORY_NAME"
> increment="INCREMENT"></repository>" where "REPOSITORY_NAME" and
> "INCREMENT" are the values you have look at in the first step;
> 5) run cave:repository-update REPOSITORY_NAME
>
> Everything should run smoothly now.
>
> Now, maybe it's feature, I don't know, but I think it's not obvious that
> cave:repository-update can lead to duplicate entries in the
> repository.xml file.
>
> Another note while I was digging into this behaviour: I found that the
> "repository-update" command hides a call of CaveReposiitory.scan(): here
> the javadoc of this interface method is, at least in my opinion, wrong:
> it says: "Scan the whole repository, reading bundle MANIFEST, ect to
> update *or generate* the repository.xml"(enphasis mine).
> However, cave:repository-update will fail if the file is deleted from
> the filesystem, hence the workaround.
>
> Finally, my setup:
>
> OBR SERVER:
> Operating system: Raspian buster 10
> Apache karaf hosting cave: 4.2.6
> Apache cave: 4.1.2
>
> OBR CLIENT:
> Apache karaf where bundles will be deployed: 4.2.6
> Operating system: Ubuntu 18.04
>
> Best Regards,
>
> --
> *Ing. Massimo Bono*

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Bug on cave:repository-update?

Massimo Bono
Oh perfect! I'll wait for cave next release then.

Thank you very much

Il giorno ven 18 ott 2019 alle ore 06:14 Jean-Baptiste Onofré <[hidden email]> ha scritto:
Hi Massimo,

I would recommend to wait Cave 4.2.0 where Cave has completely changed
with a full refactoring:

https://github.com/apache/karaf-cave/pull/27

I plan to merge the PR later today and cut Cave 4.2.0 soon (probably
during the weekend).

Cave will be simpler, first Maven focus, and the repository.xml
generation will only use local artifacts.

Regards
JB

On 17/10/2019 23:04, Massimo Bono wrote:
> Hi,
>
> I was tweaking with apache:cave and i stumble across an interesting
> behavior.
>
> 1) I've created a repository and populate it with some artifacts (via
> cave:repository-create -l);
> 2) I then created new artifacts and I have manually copied them within
> the repository.
> 3) I then run cave:repository-update <repository_name> to refresh the
> repository.xml file
>
> To my surprise, lots of resources have been duplicated: while before the
> "repository-update" the resources were accessible through one http URI,
> after the update the resources were accessible through one http URI and
> via one file URI.
> If I try to deploy a bundle with multiple URI within the repository.xml
> the obr:deploy command does not deploy anything. If I try to access to
> the bundle via web browser with the http URI I obtain Error 500 Resource
> not found.
>
> I found a workaround to this "interesting feature" as well:
>
> 1) Open the repository associated file repository.xml and annotate the
> attributes of "repository" tag;
> 2) Delete the repository.xml file;
> 3) Create the file again;
> 4) Add in such file the string "<repository name="REPOSITORY_NAME"
> increment="INCREMENT"></repository>" where "REPOSITORY_NAME" and
> "INCREMENT" are the values you have look at in the first step;
> 5) run cave:repository-update REPOSITORY_NAME
>
> Everything should run smoothly now.
>
> Now, maybe it's feature, I don't know, but I think it's not obvious that
> cave:repository-update can lead to duplicate entries in the
> repository.xml file.
>
> Another note while I was digging into this behaviour: I found that the
> "repository-update" command hides a call of CaveReposiitory.scan(): here
> the javadoc of this interface method is, at least in my opinion, wrong:
> it says: "Scan the whole repository, reading bundle MANIFEST, ect to
> update *or generate* the repository.xml"(enphasis mine).
> However, cave:repository-update will fail if the file is deleted from
> the filesystem, hence the workaround.
>
> Finally, my setup:
>
> OBR SERVER:
> Operating system: Raspian buster 10
> Apache karaf hosting cave: 4.2.6
> Apache cave: 4.1.2
>
> OBR CLIENT:
> Apache karaf where bundles will be deployed: 4.2.6
> Operating system: Ubuntu 18.04
>
> Best Regards,
>
> --
> *Ing. Massimo Bono*

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com


--
Ing. Massimo Bono