| [skalli-dev] Reduce number of thirdparty dependencies to be copied manually |
Hi, Currently one needs to copy many third party dependencies manually into Skalli to enable it to build since they are not approved yet. The latter one does not apply to all though. Some dependencies are already approved now. The question is how to get them into the build. I want to get your opinion on the following points: 1. Obviously there is an Orbit project [1] at Eclipse, which could be used to store the libraries. Does anybody have knowledge how to contribute there and have our libraries wrapped and made available? Since getting the libraries in there might take a while we also have alternatives in the meantime. The description is a little lengthy but might be an option and gives some insight into the orbit considerations. Not all issues are solved yet but I wanted to take this intermediate step to the mailing list. My personal proposal is to speed up getting our libraries into the Eclipse orbit. 2. We provide our own orbit which already contains the approved libraries. I created bug 346411 which has two attachments. One contains a new orbit project. The other one references this new orbit from Skalli. The orbit project should be put next to the Skalli root folder, not inside of it. The decision to have it as a separate git project came from the fact, that git will store the history for all times. Having jars checked in there will blow up the size of our Skalli repository even if we delete them in some months. Now, this change has some neat effects IMHO. Since the target file now uses a variable Skalli will (if the remaining libraries are approved as well) instantly build from the IDE as well as from Maven (Tycho will simply show a warning that the variable cannot be resolved which does not matter). Also, I provide the poms to recreate the P2 repository on the fly, so new libraries and components can be added and wrapped easily. The complicated part is a central build. One needs to ensure that the referenced repository is indeed available on the Hudson. The build would not be self contained anymore. I see this as a rather big problem. It would not be a problem if the orbit is part of the Skalli project but then we have the repository size problem again. So currently, I am stuck along this line of thought and hope for input J What is your take on this? Ideas? Maybe getting libraries into the central orbit is really easy and fast, then I would strongly recommend to go for option 1. [1] http://www.eclipse.org/orbit/ Greetings, Robert |