Community
Participate
Working Groups
Given an automated build that: * Generates a PAR (Say, Foo.par), and * Generates a Plan (Say, Foo.plan), and * Installs the PAR into the repository (-> repository/usr/Foo.par), and * Installs the Plan into pickup (->pickup/Foo.plan) then the installation of Foo.plan fails because Par wasn't present prior to the plan being installed. I imagine (but I don't know) that the usr/repository is scanned at startup, so any combined installation like this (the first time) will fail. A subsequent restart will fix the problem. Can the repository be re-scanned when a new plan is installed, prior to complaining that the bundles don't exist? If there are new or updated contents in the repository, perhaps sync'ing the repository contents before executing the plan would make sense.
repository/usr is a watched directory and so it is scanned at start-up and periodically thereafter. The period between scans defaults to 5 seconds and can be configured using the property repository-name.watchInterval described in the user guide. So perhaps a workaround would be to set the period to 1 second and have the automated build pause for a little over 1 second before installing the plan. I don't suppose this will help, but please note there is a mxbean for repository/usr with a forceCheck operation to force a scan. If the automated build could drive the mbean, that would be a better workaround.
The build is generated by a copy mechanism, and it copies all files over (which are in a repository/usr and pickup/ structure already) so it's the same copy mechanism. Granted, this could be worked around by doing it in 2 copy operations or by tickling the mbean, but it would be nicer if it Just Worked (TM). If the usr/ repository is periodically re-scanned anyway, and you know when a file has been picked up in the 'pickup', you could schedule a usr/repository rescan ahead of executing the pick'd up code. It would be a little slower, but it would ensure that when dropping in a plan, the state of the system is consistent.
Yes, I'm sure there is a robust solution to this bug. I was simply pointing out some workarounds for the interim.
(In reply to comment #3) > Yes, I'm sure there is a robust solution to this bug. I was simply pointing out > some workarounds for the interim. Ah, OK. I just used "The Windows Way (tm)" - if it doesn't work first time, run it again. On the second install the plan picks up the artifacts deployed from last time. It's ugly, but it works :-)
Compare https://bugs.eclipse.org/bugs/show_bug.cgi?id=327538#c2 when considering triggering a re-scan of a watched repository.
The RepositoryFactory now published all watched repos in the service registry under the WatchedRepository interface. They are all then obtained and checked before the deployer pipeline is run. PipelinedApplicationDeployerIntegrationTests have been updated to check for the calls to check watched repositories.
