Next Declarative Services (SCR) release

[Felix Meschberger <fm...@gmail.com>]

Hi all,

We are now close to being feature complete with the draft R 4.2
Declarative Service implementation. Also, I did all the changes on the
trunk (instead of the branch as I first intended). As a consequence, I
think it does not make any sense to try to push a 1.0.10 release.

Instead I will create a 1.2.0 release as soon as the open issues have
been fixed. This should make us as feature complete with respect to R
4.2 draft as possible.

Therefore I rescheduled all issues scheduled for the 1.0.10 to the 1.2.0
release and removed the 1.0.10 version from JIRA.

Regards
Felix

RE: Next Declarative Services (SCR) release

[Craig Phillips <lc...@praxiseng.com>]

Hi,
 
Not to hijack, per se...   And, there's probably some dev-standards thread out there...  Regarding trunk vice branch...  A la OSGi et al, I am rethinking all things CM and build related... I'll even go so far as to say that CMM (capability maturity model) is debunk;  I am aiming for a number of things:
 
1. Build irrelevance (the framework is the convention, NOT some build tool -- don't even get me started on how pathetic the state of build is these days... to the point where we must do everything to strive for build irrelevance altogether... Any other compromise on this principle is, well, just to keep lying to ourselves... enough is enough)
2. There is no need to recreate anything; Once it's built, it's built; Theoretically, throw out the source code; In practical terms, what I might propose is something the Peter K. did with his BND bundle/jar -- just through the source code under OSGI-OPT;
3. No CM.. ok, wishful thinking... But, following #2 above, if you bundle the source with the version of the as built bundle, well -- let's just put it this way.. there is zero need for a branch... In other words, everything is always on the trunk;
4. Get rid of a build altogether... A la scala et al, what if a bundle were ONLY source? Hmmm... The framework does the build... Again, "The Framework Is The Convention"...
5. Get rid of "context cookies" -- they couple everything; I think DS ('er SCR) is right in that context cookies generally are dissolved;
 
Yeah, quite revolutionary and apologize to hijack... Flame away... My motives... After architecting / designing / writing software day in and day out for 30 years, I'm fed up with the state of the industry -- except for OSGi and particularly declarative services (what Richard et al calls "Modular"); Whether fully intended or not, I consider the direction of "modular" a la DS to be "brilliant";  Loose coupling yet [more or less] tight binding at its finest;  And this leads to abandonment of CMM and CM and even build -- let a language like scala be the bundle with a DS dependency injection model as we really have a serious improvement in software development... your bundle is the source at a particular version, let alone it covers CM and CMM, and the framework is the convention AND the build...
 
Back to your local station, vent complete... Cheers, L. Craig Phillips, Praxis Engineering Technologies
 

________________________________

From: Felix Meschberger [mailto:fmeschbe@gmail.com]
Sent: Fri 7/31/2009 11:13 AM
To: Felix Dev
Subject: Next Declarative Services (SCR) release



Hi all,

We are now close to being feature complete with the draft R 4.2
Declarative Service implementation. Also, I did all the changes on the
trunk (instead of the branch as I first intended). As a consequence, I
think it does not make any sense to try to push a 1.0.10 release.

Instead I will create a 1.2.0 release as soon as the open issues have
been fixed. This should make us as feature complete with respect to R
4.2 draft as possible.

Therefore I rescheduled all issues scheduled for the 1.0.10 to the 1.2.0
release and removed the 1.0.10 version from JIRA.

Regards
Felix