Hi Reto I still do not see how to implement a *.web module for a component (e.g. the enhancer) without using a WebFragment. What is the replacement for LinkResource and ScriptResource?
I have also noticed that the CORS related things are all commented in 1.0.0. Does this mean that CORS is not supported or is there a replacement for that? best Rupert On Thu, Apr 24, 2014 at 10:34 AM, Reto Gmür <r...@wymiwyg.com> wrote: > 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/ >> -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen | REDLINK.CO .......................................................................... | http://redlink.co/
