On Wed, Apr 30, 2014 at 5:52 PM, Reto Gmür <r...@wymiwyg.com> wrote: > Hi Rupert > > 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? >> > > This is deprecated and there is no 1:1 replacement. The idea is that the > java code should care about the application logic leaving the rendering and > with it anything that is specific to HTML to the renderer (that is for now > always freemarker with LdPathTemplate). >
... and I guess there are no plans to adapt existing UI to this model. The deprecation message of Webfragment mentions that [..] Links and ScriptResource should be in the template" I guess doing so should not be so much effort and allow to get rid of the remaining usages of the WebFragment class. If you agree I suggest to create an issue for doing so > >> >> 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? >> > > That's right. See also: > http://mail-archives.apache.org/mod_mbox/stanbol-dev/201404.mbox/%3CCALvhUEWuLxBXPncdEUSFA4tX7p1sD32oHu_4HaDa%3D51ZLVGFrw%40mail.gmail.com%3E > I created STANBOL-1335 for this. best Rupert > Cheers, > Reto > > 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/ -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen | REDLINK.CO .......................................................................... | http://redlink.co/
