You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mark Struberg <st...@yahoo.de> on 2012/05/05 11:32:17 UTC
[DISCUSS] CODI - the future is NOW ?
Hi folks!
I've recently tried to use CODI and DeltaSpike in the same project and it didn't work out well.
I think DeltaSpike has come to a point where we can think about to start the 'migration path' from CODI to DeltaSpike, and here is what I've thought of. The following is just a starting point for our discussion and _not_ yet agreed stuff!
a.) create a new extcdi-2.x branch. Trunk will (for now) still remain CODI-only! We will still ship bug fixes for 1.x but all new feature development is done in DeltaSpike.
b.) add deltaspike-core-api and deltaspike-core-impl as dependencies to CODI
c.) remove our own ProjectStage stuff. People should use the drop-in replacement from DS instead
d.) provide a small Extension which rewrites CODI @ProjectStageActivated annotations to DS @Exclude. Of course log a warning that people should change their impl because they are using a deprecated functionality
e.) remove all functionality from CODI core which got moved to DS. If possible create a compatible wrapper. Most of the time the effort for end users should just contain changing an import package.
f.) rewrite all ee modules to make use of the deltaspike-core stuff instead.
g.) if DeltaSpike ships a new feature which replaces a CODI feature, we will
As explained in a.) we will create a new branch. CODI-2.x is a transition path which will end in fully using DeltaSpike at the end of the year. For making this as easy as possible for the end users, we will really take care about binary compat and feature changes. Thus I like to propose a strict version schema: [major nr].[minor nr].[bugfix nr]
major nr = 2 this is fixed to 2 for now.
minor nr = x whenever we replace a CODI functionality with one from DeltaSpike we will increment this nr. This indicates that the user might need to change some import package or do some other small change.
bugfix nr = This is intended for being incremented when we ship a new COMPATIBLE version. Means the user can update to the latest without having to think about any compat issues. Of course we will only ship such bugfix releases in important cases. If a user has a problem with e.g. a 2.1.0 version and doesn't like to update to a 2.4.0, then he is very welcome to ship a patch and we will try to get a release out of the door. But we will not back-port everyday bugfixes to all the versions (that would be a huge amount of work, and no one pays us for it).
This means we will create an own branch for each minor nr increment during the release. Perfectly able to be maintained by the community or downstream users itself (a local git branch with a release to a company internal Archiva or Nexus is not a big thing nowadays).
WDYT?
Btw, I really like to thank all the users which are using CODI! I think I can speak for all committers that it was a pleasure to hack this stuff and it's always nice to hear on conferences that a lot of companies use it (even though they never speak up on this list or make any public announcement about it).
LieGrue,
strub
Re: [DISCUSS] CODI - the future is NOW ?
Posted by Gerhard Petracek <gp...@apache.org>.
imo we should keep the announced plan [1]!
regards,
gerhard
[1] http://s.apache.org/5yV
2012/5/5 Mark Struberg <st...@yahoo.de>
> whoops, figured I did not complete a sentence ;)
>
> > g.) if DeltaSpike ships a new feature which replaces a CODI feature, we
> will
> ... remove this feature from COD-2.x.y, provide a compat layer and
> increment the minor nr to x+1 (2.0.1, +new feature -> 2.1.0)
>
> LieGrue,
> strub
>
>
> ----- Original Message -----
> > From: Mark Struberg <st...@yahoo.de>
> > To: My Faces Development <de...@myfaces.apache.org>
> > Cc:
> > Sent: Saturday, May 5, 2012 11:32 AM
> > Subject: [DISCUSS] CODI - the future is NOW ?
> >
> > Hi folks!
> >
> > I've recently tried to use CODI and DeltaSpike in the same project and it
> > didn't work out well.
> > I think DeltaSpike has come to a point where we can think about to start
> the
> > 'migration path' from CODI to DeltaSpike, and here is what I've
> > thought of. The following is just a starting point for our discussion
> and _not_
> > yet agreed stuff!
> >
> >
> >
> > a.) create a new extcdi-2.x branch. Trunk will (for now) still remain
> CODI-only!
> > We will still ship bug fixes for 1.x but all new feature development is
> done in
> > DeltaSpike.
> >
> >
> > b.) add deltaspike-core-api and deltaspike-core-impl as dependencies to
> CODI
> >
> > c.) remove our own ProjectStage stuff. People should use the drop-in
> replacement
> > from DS instead
> >
> > d.) provide a small Extension which rewrites CODI @ProjectStageActivated
> > annotations to DS @Exclude. Of course log a warning that people should
> change
> > their impl because they are using a deprecated functionality
> >
> > e.) remove all functionality from CODI core which got moved to DS. If
> possible
> > create a compatible wrapper. Most of the time the effort for end users
> should
> > just contain changing an import package.
> >
> >
> > f.) rewrite all ee modules to make use of the deltaspike-core stuff
> instead.
> >
> > g.) if DeltaSpike ships a new feature which replaces a CODI feature, we
> will
> >
> >
> >
> > As explained in a.) we will create a new branch. CODI-2.x is a
> transition path
> > which will end in fully using DeltaSpike at the end of the year. For
> making this
> > as easy as possible for the end users, we will really take care about
> binary
> > compat and feature changes. Thus I like to propose a strict version
> schema:
> > [major nr].[minor nr].[bugfix nr]
> >
> >
> > major nr = 2 this is fixed to 2 for now.
> >
> > minor nr = x whenever we replace a CODI functionality with one from
> DeltaSpike
> > we will increment this nr. This indicates that the user might need to
> change
> > some import package or do some other small change.
> >
> >
> > bugfix nr = This is intended for being incremented when we ship a new
> COMPATIBLE
> > version. Means the user can update to the latest without having to think
> about
> > any compat issues. Of course we will only ship such bugfix releases in
> important
> > cases. If a user has a problem with e.g. a 2.1.0 version and doesn't
> like to
> > update to a 2.4.0, then he is very welcome to ship a patch and we will
> try to
> > get a release out of the door. But we will not back-port everyday
> bugfixes to
> > all the versions (that would be a huge amount of work, and no one pays
> us for
> > it).
> >
> >
> >
> > This means we will create an own branch for each minor nr increment
> during the
> > release. Perfectly able to be maintained by the community or downstream
> users
> > itself (a local git branch with a release to a company internal Archiva
> or Nexus
> > is not a big thing nowadays).
> >
> >
> >
> > WDYT?
> >
> >
> > Btw, I really like to thank all the users which are using CODI! I think
> I can
> > speak for all committers that it was a pleasure to hack this stuff and
> it's
> > always nice to hear on conferences that a lot of companies use it (even
> though
> > they never speak up on this list or make any public announcement about
> it).
> >
> >
> > LieGrue,
> > strub
> >
>
Re: [DISCUSS] CODI - the future is NOW ?
Posted by Mark Struberg <st...@yahoo.de>.
whoops, figured I did not complete a sentence ;)
> g.) if DeltaSpike ships a new feature which replaces a CODI feature, we will
... remove this feature from COD-2.x.y, provide a compat layer and increment the minor nr to x+1 (2.0.1, +new feature -> 2.1.0)
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: My Faces Development <de...@myfaces.apache.org>
> Cc:
> Sent: Saturday, May 5, 2012 11:32 AM
> Subject: [DISCUSS] CODI - the future is NOW ?
>
> Hi folks!
>
> I've recently tried to use CODI and DeltaSpike in the same project and it
> didn't work out well.
> I think DeltaSpike has come to a point where we can think about to start the
> 'migration path' from CODI to DeltaSpike, and here is what I've
> thought of. The following is just a starting point for our discussion and _not_
> yet agreed stuff!
>
>
>
> a.) create a new extcdi-2.x branch. Trunk will (for now) still remain CODI-only!
> We will still ship bug fixes for 1.x but all new feature development is done in
> DeltaSpike.
>
>
> b.) add deltaspike-core-api and deltaspike-core-impl as dependencies to CODI
>
> c.) remove our own ProjectStage stuff. People should use the drop-in replacement
> from DS instead
>
> d.) provide a small Extension which rewrites CODI @ProjectStageActivated
> annotations to DS @Exclude. Of course log a warning that people should change
> their impl because they are using a deprecated functionality
>
> e.) remove all functionality from CODI core which got moved to DS. If possible
> create a compatible wrapper. Most of the time the effort for end users should
> just contain changing an import package.
>
>
> f.) rewrite all ee modules to make use of the deltaspike-core stuff instead.
>
> g.) if DeltaSpike ships a new feature which replaces a CODI feature, we will
>
>
>
> As explained in a.) we will create a new branch. CODI-2.x is a transition path
> which will end in fully using DeltaSpike at the end of the year. For making this
> as easy as possible for the end users, we will really take care about binary
> compat and feature changes. Thus I like to propose a strict version schema:
> [major nr].[minor nr].[bugfix nr]
>
>
> major nr = 2 this is fixed to 2 for now.
>
> minor nr = x whenever we replace a CODI functionality with one from DeltaSpike
> we will increment this nr. This indicates that the user might need to change
> some import package or do some other small change.
>
>
> bugfix nr = This is intended for being incremented when we ship a new COMPATIBLE
> version. Means the user can update to the latest without having to think about
> any compat issues. Of course we will only ship such bugfix releases in important
> cases. If a user has a problem with e.g. a 2.1.0 version and doesn't like to
> update to a 2.4.0, then he is very welcome to ship a patch and we will try to
> get a release out of the door. But we will not back-port everyday bugfixes to
> all the versions (that would be a huge amount of work, and no one pays us for
> it).
>
>
>
> This means we will create an own branch for each minor nr increment during the
> release. Perfectly able to be maintained by the community or downstream users
> itself (a local git branch with a release to a company internal Archiva or Nexus
> is not a big thing nowadays).
>
>
>
> WDYT?
>
>
> Btw, I really like to thank all the users which are using CODI! I think I can
> speak for all committers that it was a pleasure to hack this stuff and it's
> always nice to hear on conferences that a lot of companies use it (even though
> they never speak up on this list or make any public announcement about it).
>
>
> LieGrue,
> strub
>