Re: [CHAIN] Chain 2.0

[Simone Tripodi]

Hi Steve!

thanks a lot for moving things forward, very appreciated and I personally
thank you.

Sorry for the late reply - unfortunately my OSS involvement decreased in
the last months due to my new job, I hope to get better organised soon, in
order to get back contributing ASAP.

Exploring your points:

>
>- Support for same features of 1.x
>
> this comes, fortunately, for free: Chain2 is not a complete redesign of
Chain, but rather a restyle

>
>- Increased modularisation
>
> Goal achieved - we no longer have a god module, but everything is splitted
in small submodules, i.e. APIs, core, web, ... functionalities are
distributed in separated bundles

>
>- Use of generics
>
> Done, I think we have found the definitive design - that doesn't mean this
is a closed chapter, feel free to dig in the source code and fill an issue
if you want to propose an improvement

>
>- A Fluent API (EDSL)
>
>  This is achieved via a single class, but agreed that needs anyway to be
better advertised

>
>- Web support
>
> Inherited from older Chain releases

>
>- Increase number of supported formats  for external chain
>configuration (add JSON, YAML etc.. to the current support for XML)
>
> As things stand, all of the above have been implemented apart from the
> support for additional files formats (defined in CHAIN-76), although more
> testing and samples are required.
>
 and, as you already noticed, this is still a TODO :)

> Christians links point to an interesting, if very specific use of chains :
> XChain fuses the commons-chain  and JXPath projects, and there may be merit
> in the creation of a module/component to accommodate this in chains.
> Whether this should be in a 2.0 release needs to be discussed,
>
I am not sure that feature would fit in the commons component, however
if Christian
is submitting a patch that contributes that functionalities in
commons-chain, I am open to apply it

> however, I would favour the following happening with Chain:
>
>1. Move CHAIN-76 to another release (2.1?) – I am not aware of any
>great demand for this functionality
>2. Make a 2.0 release candidate of the SVN trunk as is and move
>towards a substantial test phase.
>
>
That makes perfectly sense, I second you - just give me the time to have a
deep review to the codebase, so I can cut the first RC.

>
>
> This would have the merit of ensuring much of the recent great work from
> Simone and others goes out into the wider world and hopefully kick-starts
> interest in commons-chain. Of course, if the response is minimal, then
> perhaps we should reduce effort in commons-chain as is, although this is a
> wider community decision.
>
> Look forward to hearing opinions on this.
>
> Regards,
>
> Steve Westwood
>
Thanks a lot for participating, have a nice day, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Apr 24, 2013 at 3:48 PM, Steve Westwood <
steve.westw...@hexsaw.org.uk> wrote:

> **
>
> Christian Trimble recently sent to the list details of the XChain project
> (see http://xiantrimble.com/xchain/ and https://github.com/ctrimble/xchain)
> and pondered on whether aspects of this could be accommodated in
> commons-chain.  There has not been any response to this email (apologies to
> Christian), but it does raise an interesting question about where does the
> wider community want commons-chain to go.
>
> Simone Tripodi summarised his view of the 2.0 release recently, with it
> consisting of:
>
>- Support for same features of 1.x
>- Increased modularisation
>- Use of generics
>- A Fluent API (EDSL)
>- Web support
>- Increase number of supported formats  for external chain
>configuration (add JSON, YAML etc.. to the current support for XML)
>
> As things stand, all of the above have been implemented apart from the
> support for additional files formats (defined in CHAIN-76), although more
> testing and samples are required.
>
> Christians links point to an interesting, if very specific use of chains :
> XChain fuses the commons-chain  and JXPath projects, and there may be merit
> in the creation of a module/component to accommodate this in chains.
> Whether this should be in a 2.0 release needs to be discussed, however, I
> would favour the following happening with Chain:
>
>1. Move CHAIN-76 to another release (2.1?) – I am not aware of any
>great demand for this functionality
>2. Make a 2.0 release candidate of the SVN trunk as is and move
>towards a substantial test phase.
>
> This would have the merit of ensuring much of the recent great work from
> Simone and others goes out into the wider world and hopefully kick-starts
> interest in commons-chain. Of course, if the response is minimal, then
> perhaps

Re: [CHAIN] Chain 2.0

[sebb]

On 24 April 2013 14:48, Steve Westwood  wrote:

> Christian Trimble recently sent to the list details of the XChain project
> (see and<
> https://github.com/ctrimble/xchain> )
> and pondered on whether aspects of this could be accommodated in
> commons-chain.
>  There has not been any response to this email (apologies to Christian),
> but it
> does raise an interesting question about where does the wider community
> want
> commons-chain to go.
>
> Simone Tripodi summarised his view of the 2.0 release recently, with it
> consisting of:
>
> * Support for same features of 1.x
> * Increased modularisation
> * Use of generics
> * A Fluent API (EDSL)
> * Web support
> * Increase number of supported formats  for external chain configuration
> (add
> JSON, YAML etc.. to the current support for XML)
>
> As things stand, all of the above have been implemented apart from the
> support
> for additional files formats (defined in CHAIN-76), although more testing
> and
> samples are required.
>
> Christians links point to an interesting, if very specific use of chains :
> XChain fuses the commons-chain  and JXPath projects, and there may be
> merit in
> the creation of a module/component to accommodate this in chains. Whether
> this
> should be in a 2.0 release needs to be discussed, however, I would favour
> the
> following happening with Chain:
>
> 1. Move CHAIN-76 to another release (2.1?) – I am not aware of any great
> demand
> for this functionality
> 2. Make a 2.0 release candidate of the SVN trunk as is and move towards a
> substantial test phase.
>
> This would have the merit of ensuring much of the recent great work from
> Simone
> and others goes out into the wider world and hopefully kick-starts
> interest in
> commons-chain. Of course, if the response is minimal, then perhaps we
> should
> reduce effort in commons-chain as is, although this is a wider community
> decision.
>
> Look forward to hearing opinions on this.
>
>
I have no particular view on the API of Chain2, but I do think it's worth
ensuring that the API is as correct as possible.
Changes to the API often require incompatible code, and that should be
avoided as far as possible.

I note that there is a separate api source tree - if this is the only
public API, then that is great as it potentially allows changes to any
other part of the code without breaking the official API. However, it would
need to be made very clear to end-users that if they use anything else then
there are no guarantees that their code will continue to work or compile.
For example, if one uses a class from the sun.* package, one knows that it
is a hack at best.

Regards,
>
> Steve Westwood