You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Rupert Westenthaler <ru...@gmail.com> on 2014/05/01 08:36:59 UTC
Re: [DISCUSS] 1.0 Release?
On Wed, Apr 30, 2014 at 5:52 PM, Reto Gmür <re...@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 <re...@wymiwyg.com> wrote:
>> Hi Rupert
>>
>> On Thu, Apr 24, 2014 at 9:24 AM, Rupert Westenthaler <
>> rupert.westenthaler@gmail.com> wrote:
>>
>>> Hi Reto,
>>>
>>> On Wed, Apr 23, 2014 at 4:38 PM, Reto Gmür <re...@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 <re...@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-Q6rx490S4AntF8G15EyKvpdh0TZmQ@mail.gmail.com%3E
>>> >
>>> >>
>>> >> >
>>> >> > WDYT?
>>> >> >
>>> >> > Cheers,
>>> >> > Reto
>>> >> >
>>> >> >
>>> >> > 1. https://github.com/fusepool
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> >> | Bodenlehenstraße 11 ++43-699-11108907
>>> >> | A-5500 Bischofshofen
>>> >> |
>>>
> REDLINK.CO..........................................................................
>>> >> | http://redlink.co/
>>> >>
>>>
>>>
>>>
>>> --
>>> | Rupert Westenthaler rupert.westenthaler@gmail.com
>>> | Bodenlehenstraße 11 ++43-699-11108907
>>> | A-5500 Bischofshofen
>>> |
> REDLINK.CO..........................................................................
>>> | http://redlink.co/
>>>
>
>
>
> --
> | Rupert Westenthaler rupert.westenthaler@gmail.com
> | Bodenlehenstraße 11 ++43-699-11108907
> | A-5500 Bischofshofen
> | REDLINK.CO..........................................................................
> | http://redlink.co/
--
| Rupert Westenthaler rupert.westenthaler@gmail.com
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
| REDLINK.CO ..........................................................................
| http://redlink.co/