Our current approach of having third party dependencies as OSGi bundles is to make them into an orbit project. The release of them happen with the kernel or platform release.
Because of this, currently when building carbon from source, we first have to build orbit. But this is not needed if we maintain orbit as an external project (may be in git-hub) and use one of the following. 1. Use SNAPSHOT repo approach. The developer who creates a new orbit project will have to deploy the snapshot version of it to the repo. The official release of those will happen on its own way. It can align either with a kernel release or platform release (major or patch releases). 2. Releasing the newly created orbit project immediately after creating it. This is possible because we don't normally do any changes to it (pom) afterwards. This also has to be done by the developer (after all the testing). The downside of this is we may end up with multiple versions for a projects. But this will be minimal. In both cases above, the components requiring those orbit dependencies will have to update to those released/snapshot versions. The orbit projects for forked dependencies will follow the same approach as earlier. Suggestions and thoughts are welcome. Thanks, Kishanthan. -- *Kishanthan Thangarajah* Senior Software Engineer, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
