Community
Participate
Working Groups
Repo2Runnable indirectly calls SimpleArtifactRepo.getArtifacts() to populate the destination repo. By default this results in a repo save() being done after each artifact is added. That writes out the artifacts.xml and, if the repo is compressed, proceeds to JAR it. SimpleArtifactRepo supports then notion of batch operation using #executeBatch but Repo2Runnable (and more generally AbstractApplication) do not use it. The win is not huge but the effort to use batching is minimal. I'm working on a patch for this and will attach soon.
I'm broadening this a little as more investigation is done. Turns out that the executeBatch mechanism is synchronous. The net result is that you can't use it during a provisioning operation because the download manager spawns multiple jobs each of which uses things like contains() which is also synchronous. Deadlock. Given that there is some sync code we seem to be interested in having the in memory version of the repo be threadsafe. If so, why not allow the executeBatch to work with/for multiple threads? Related, it also seems that running the engine does not allow for batching. The collect phase can result in any number of download requests being made and each could be to a different repo. Perhaps the answer is to have the download manager "start a batch" on each *destination* (if it is IBatchable whatever) and then when it starts and then "stop batch" when it ends?
*** Bug 335454 has been marked as a duplicate of this bug. ***
Another simple use case (covered by bug 335454) is when you call the mirror application to mirror an artifact repository. The repository index file is written for each artifact that you are mirroring.
Marking as 3.7 so we don't lose track of it.
This can't be addressed until bug#338987 is fixed. I'm moving this out.
Move all 3.8 bugs to Juno.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
