Hi Rupert On Thu, Apr 24, 2014 at 9:24 AM, Rupert Westenthaler < rupert.westentha...@gmail.com> wrote:
> Hi Reto, > > On Wed, Apr 23, 2014 at 4:38 PM, Reto Gmür <r...@wymiwyg.com> wrote: > > Hu Rupert, > > > > IMO before the first 1.0 release we need to address all major changes > >> that will break backward compatibility. From my side this would > >> include > >> > >> * Changes to the Enhancer API as suggested by STANBOL-1326 (see also > >> my mail from yesterday [1]) > >> * Review/Change the Stanbol Enhancement Structure > >> * with a look at standards like Open Annotation and NIF > >> * and especially considering typical use cases > >> > > > > I'm very much welcome these changes but I think they can as well be part > of > > a future release. The SNAPSHOT version has been there for a while and so > I > > think it is justified to have a release that is actually compatible with > > what was built against this snapshot version. In an earlier discussion > [2] > > I argued that it's an exaggeration to guarantee that no > > matter at which time you take a trunk snapshot version you will have a > > compatible release at some point, but in this case the trunk has been > there > > for quite a while and software has been built against it. So we should > imho > > follow the Release early, release often" mantra. > > > > Is there actually a difference between 0.12 and 1.0.0? IMO every > application based on the 1.0.0-SNAPSHOT will run just fine with the > 0.12 release. This is at least true for everyone using the RESTfull > services and for components implemented for the Enhancer (e.g. > EnhancementEngines) and the Entityhub (e.g. a Yard Implementation). > While for application that only use the HTTP API this is true. But for applications that integrate stanbol bundles or that integrate into stanbol this is not true > > AFAIK the main difference between 0.12 and 1.0 is in the "REST layer" > (*.web and *.jersey modules). Exactly those changes where discussed in > [2], the creation of STANBOL-1094, implementation in a branch that > finally become the new trunk. The "compatible release" as mentions in > [2] was done based on on the old trunk (now the release-0.12 branch) > and the compatible release was 0.12.0 with 0.12.1 on the horizon (next > few weeks). > > So when evaluating a release based on the trunk (1.0.0-SNAPSHOT) one > needs to focus on the progress of STANBOL-1094. > I see there are quite some open subissues which I believe to be resolved. For instance the entityhub is clearly in trunk. On the other hand I doubt that not havng thing like the webvie demo ported is a blocker for release. > > Even that all remaining Stanbol components to pass all tests since > some time there are still a lot of open things. Most important the > REST layer modules of all Stanbol components heavily depend on > deprecated APIs such as WebFragment, Viewable, LinkResource and > ScriptResource. Honestly I do not even know how to change those > components to avoid using those APIs. > > Just to give an example: Yesterday I tried to fix STANBOL-1329 by > registering the the SparqlMenuItem as OSGI service (Whiteboard pattern > as mentioned by STANBOL-1094) but it had not the expected effect of > the link being shown in the horizontal menu nor in the Stanbol main > page. Next I tried to find an example in one of the other components > defining menu Items but all of them where using the old way via the > WebFragment#getNavigationLinks(...). > It was about adding the @Component and @Service annotation. The white board pattern has been there for more than one year (even in the 0.12 branch) and is exemplified by the two maven archetypes, it is not a novelty of 1.0. > > What I am missing is a "migration guide" for STANBOL-1094. Maybe doing > all those changes would only require some days. But without knowing > how to do it I am not even able to start. > What is no longer supported in 1.0.0: - Accessing services via the servlet context - Using the jersey multi part classes - per request life-span of root resources The archetypes show how to access services via OSGi and how to handle multipart requests. I think this is more development support than was ever available for the old approach. Using fields to pass value from one methods to the other as this was possible with the singl-request life span of the root resources seems to me like a broken design in the first place, also the per-request lifespan was never guaranteed by the specification. > > To be clear: I am fine with the API changes of using singleton > instances JAX-RS resources registered via the OSGI Whiteboard pattern > with the JAX-RS 2.0 implementation. I am just not convinced that > STANBOL-1094 and therefore 1.0.0 is ready to be release anytime soon. > I will not vote with +1 for a release based on the trunk as long as > the major part of the Stanbol components depend on the use of > deprecated APIs. > Why? The APIs where marked as deprecated to indicate to the developer that there is an easier and more elegant way to do things. Nevertheless the old APIs are working just fine and so I see no need to change code that is not undergoing maintenance anyway. After all that's why the deprecated APIs are left there. There are projects that depend on 1.0 bundles and these bundles provide possibilities that are not provided by the 0.12 branch (JAX-RS 2.0, easier integration with other OSGI applications), why forcing them to use SNAPSHOT versions for such a long time? Cheers, Reto > > On Wed, Apr 23, 2014 at 4:38 PM, Reto Gmür <r...@wymiwyg.com> wrote: > >> > >> If we want to have an early release of the trunk version we could > >> consider to define milestone releases and assign the JIRA issues > >> accordingly. Not sure how such releases would play together with the > >> semantic versioning rules of OSGI. > >> > > > > We can choose version numbers as they fit. Even having a 2.0 release in > the > > foreseable future wouldn't be a fundamental problem. > > Making a 1.0 release that is mainly about STANBOL-1094 is fine for me. > Doing the Enhancer API changes (STANBOL-1326) and updates to the > Enhancement Structure in 2.0 is also fine with me. Maybe it is even > easier to grasp for users if 1.0 is still compatible with all the 0.* > releases and major changes are done with 2.0. > > To go forward I would suggest: > > * Reto, can you provide a migration guide - best in the description of > STANBOL-1094. > * Reto can you port the Enhancer as an Example Component > * I will make the necessary changes to the Entityhub > * Lets add a version 2.0.0 in JIRA and assign STANBOL-1326 as first issue > to it. > * I will also port the partial implementation of STANBOL-488 to > the trunk (as the complete one will only be available with 2.0.0) > * I also changed STANBOL-351 to be part of STANBOL-1326 - > meaning that the updates to the Enhancement Structure will be also > part of 2.0.0 > * Adapt the release date for 1.0.0 to be much earlier (end of May?) > * We should also create a 1.1 release so that we can assign issue > that we still want to do in 1.* but not for 1.0 > * We will need to go through all the issue and assign them to > 1.0.0, 1.1.0 or 2.0.0 > > With this in place we should very fast an good overview what is needed > for a 1.0.0 release > > WDYT > Rupert > > > > > >> > >> In addition there is still an open discussion about the Contenthub and > >> the CMS Adapter component. AFAIK @Rafa was investigating this. Could > >> someone provide more information on that. > >> > > > > There are always things than can be added and that can be improved, I > don't > > see why this should be a blocker for releasing what we have. > > > > > >> > >> If we want to have an early release of the trunk version we could > >> consider to define milestone releases and assign the JIRA issues > >> accordingly. Not sure how such releases would play together with the > >> semantic versioning rules of OSGI. > >> > > > > We can choose version numbers as they fit. Even having a 2.0 release in > the > > foreseable future wouldn't be a fundamental problem. > > > > > >> > >> BTW: I am currently working on the 0.12.1 release. As part of that I > >> have updated most of the OSGI, Sling and commonly used dependencies > >> (both for 0.12 and in trunk). > >> > >> As part of this work I also noticed the huge number of dependencies of > >> Jersey 2 in the trunk. With the update from 2.2 to 2.7 three > >> additional one where added (including a repacked version of Google > >> Guava with several MByte). @Reto: Does we still depend on using > >> jersey, or could we also consider other options for JAX-RS with 1.0 > >> > > It should work with any JAX-RS 2.0 compatible implementation. > > > > Cheers, > > Reto > > > > > >> > >> best > >> Rupert > >> > >> [1] http://stanbol.markmail.org/thread/beexsyf2t62lavqz > >> > > > > 2. > > > http://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3ccalvhueuwvebtxgzj1q51-q6rx490s4antf8g15eykvpdh0t...@mail.gmail.com%3E > > > >> > >> > > >> > WDYT? > >> > > >> > Cheers, > >> > Reto > >> > > >> > > >> > 1. https://github.com/fusepool > >> > >> > >> > >> -- > >> | Rupert Westenthaler rupert.westentha...@gmail.com > >> | Bodenlehenstraße 11 ++43-699-11108907 > >> | A-5500 Bischofshofen > >> | > REDLINK.CO.......................................................................... > >> | http://redlink.co/ > >> > > > > -- > | Rupert Westenthaler rupert.westentha...@gmail.com > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen > | > REDLINK.CO.......................................................................... > | http://redlink.co/ >
