Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org
 designates 69.89.18.112 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=O7iaDB/Ypj5tGbrtSB2K9cQLOp9hRT5pR5k5LKo/9kfqmdt3wW9XXFnjsYjmdKfV/ouGIDHphD2p82ysCdZ2/Qs9t32qACi6vlXhJopSogEwipKC3x7y/tO3h3QRY8n8;
Message-ID: <4A7EDC4E.10607@ungoverned.org>
Date: Sun, 09 Aug 2009 10:25:18 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: The framework does the build / the framework is the convention
References: <9E8C2EE38A83804B8A7CD8F5C5D6BA91E4C616@exch01.praxislan01.com>
In-Reply-To: <9E8C2EE38A83804B8A7CD8F5C5D6BA91E4C616@exch01.praxislan01.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Interesting. But why exactly did you need buddy policy for this?

-> richard

On 8/7/09 21:14, Craig Phillips wrote:
> Toying with this idea...
>
> I had written a script runner for OSGi (actually, I did it for equinox but I am a felix fan... although, I did have to make use of the buddy policy for the circular dependency -- seeing that pre-modular is rather abusive in that department);
>
> I wrote a BSF-JRuby-Groovy script runner (I am not a fan of javax.scripting -- it's way too complicated... pretty much like everything in jee) that would scan a directory ('er, the watcher part), load up / execute the script and allow the script to access any loaded class in the OSGi container; I spent days writing a class loader for those engines... barely any lines of code, but uncovering the riddles was another painful saga;
>
> Anyway, for a choice set of scripting languages, maybe even scala, and I guess I could mention java source as well -- I'm thinking I could write a bundle that would allow for "script-bundles" or "source-bundles" to be loaded into an OSGi container in pretty much the same fashion as "pre-built" bundles are now;
>
> In essence, "the framework is the build"; So, a "source-bundle" could contain all the same kind of OSGi bundle manifest information, OSGI-OPT, OSGI-INFO, resources etc... Except -- zero dot.class files... only source files, in possibly scala or maybe even dot.java files... Hence, part of the install/start process would be predicated on a "build" - I'm thinking scala or groovy could be "compiled" as well;
>
> Further, we no longer need complicated CM schemes -- after all, the bundle IS the source at a particular version; As for dependency management, well, if it aint available, we aint "compiling";
>
> The framework IS the convention;
>
> The convention is not some dreaded build tool of the anti-christ whose name is the name of the beast, which starts with an "M", but I digress;
>
> Several nightmares are alleviated, namely CM and build; As for the capability maturity model (what a scam that was), there is no need for anything to be "repeated"; The trunk just carries along;
>
> It probably wouldn't take too long to assemble a demo capability, but I just don't have the free time to devote to a production undertaking; In any case, it's time that new ideas to push the "modular world" further, and thus pushing the development "industry" away from and out of the perpetual nightmares that plague the industry, might just get to a level of quality RAD unheard of prior;
>
> Oh, I'm sure the "job security" crowd will have a fit, but they can't develop anyway;
>
> Flame away, back to your regular station...
>
> Cheers, Craig
>
>