Re: [Proposal] HiveMind Service Framework
I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. We have projects with a much smaller scope as normal jakarta projects and we have and had framework projects such as Cocoon, Avalon or Turbine outside of the commons. IMHO the scope of HiveMind is already to big for the commons which I see as software snacks: Small, easy to swallow and a side order for larger projects. Regards Henning On Tue, 2003-11-11 at 20:23, Martin Cooper wrote: Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available
Re: BSD style code and licensing issues
On Tue, 2003-11-11 at 16:20, Mark R. Diggory wrote: That last thread seemed such a waste of bandwidth. Unfortunately it swallowed a discussion we were trying to start concerning Licensing issues associated with the consideration of using BSD style licensed code in Apache Projects. To formulate a more solid point people can respond to: Can BSD licensed code be added to Apache licensed code bases? Can both licenses be maintained? If so can someone direct me to an example of this? You should read LKML for about six months or so. In this time, a licensing discussion and a GPL is evil and maybe even a why binary code is good/bad/don't care discussion as a bonus are due to happen (The average brain of the net lasts six months). As far as I can see: BSD code inclusion in ASF code is ok, no strings attached, but there should/must (depends on the BSD license) a notice which the original copyright must be included with the source tree (or even when starting the resulting program; some quite old BSD licenses required this, this is why older AIX/HP-UX boxes displayed a plethora of copyright messages when booting). BTW: I just re-read this conglomerate of politics, ideology, crude examples and pseudo-legal speech that calls itself LGPL (http://www.opensource.org/licenses/lgpl-license.php). IMHO, JBoss is in deep sh*t using this license: - JBoss is not a library. But the JBoss Group insists that it is (which they seem to do, because they themselves declare JBoss to be one (they even link the web site cited above) - If it is a library, then the whole § 2 applies. This basically means, that I can write an J2EE server by simply extending all the classes in the JBoss package (but e.g. calling it Foo J2EE Server) and putting a jboss binary distribution and a file that says: This product uses code from the JBoss application server with the appropriate copyright and a link to the JBoss source code repo. - I can redistribute this in compiled (no source code at all) form (§5). I'd say that LGPL is for a language like Java (which has no concept of linking) a pretty bad choice. In fact, I'd even look forward to JBoss Group trying to prove its claims in court. I'm pretty sure that in the end, the court will sack their own license and they (and all of their customers) will suddenly have an unlicensed products. And, if JBoss is a library, then all programs running in the container are suddently derived works. Which brings a whole new meaning to the concept of linking _AND_ the legal issues of the licensing terms of these programs! ObDisc: IANAL, I just play one at late-night drinking contests. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Außerdem können in Deutschland alle Englisch. [...] so entfällt die Notwendigkeit [...] Deutsch zu lernen. -- Johan Micoud auf die Frage warum er kein Deutsch spricht. (http://www.spiegel.de/spiegel/0,1518,273205,00.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. It doesn't seem unreasonable to me, if the criteria are met and the political implications of creating a new sub-project are acceptable. Otherwise a spell in commons will help to cement the community and do no harm. I would like to know if this has been proposed to Avalon, if not why not, if so what has been their reaction. I'm not suggesting that it should be, just that it might be a better fit with their charter. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Call on Stein to resign over Gernimo
On Tuesday, November 11, 2003, at 01:25 PM, Vic Cekvenich wrote: Geir Magnusson Jr. wrote: I think that this is the right list, very few people are intrested about the incubator. This is about ASF reputation. (It is also about the OSS reputation, including BSD, Linux, CodeHus, etc.) Due to this Stein mistake OSS could be view as very lowest form. Makes me think ... hmm, did Linux developers refactor SCO code? Shame. I would like to know... does ASF claim that if they refactor offending code one by one, they feel they are clean? or If the code was imported and beeing refactored, that that is a probelm. Vic : I didn't write any of the above. Please try and make clear your attributions especially when what you are saying is inflammatory and in the wrong forum. The ASF treats the allegations of code copying very seriously, and will take what actions are necessary to ensure that no IP rights are violated, any offending code, if found, is removed, and any other appropriate action is taken. I have been thinking about it, I do not think removing the offeding code is appropriate or sufficient. If proven, I think offending devlopers, new or old should be baned from ASF (and other OSS projects) for a few years. The project should be parked. Let it live on SF, why shield it (becuase now ASF has to use their lawyers/resources) ASF should publicly applogize, and as a sign of friendship with OSS, do something to help jBoss, such as help with J2EE certification, or help with code or something. Did I say that Stein should be removed, as the person out of all the OSS projects out there, did most to ruin the high reputation, trough negligence or some other reason. I feel dirty using Apache Struts today becuase of this mess. I already remvoed ASF licnese from basicPortal.sf.net when this was originaly done and uses a commons license or something like that. However, you must allow the alleged violations to be vetted - just as you wouldn't take the ASF's word that all was fine w/o explanation, you shouldn't take JBoss claim of violation at face value either. http://theserverside.com/home/thread.jsp?thread_id=22337#101208 Above says: The version 1.1 and 1.2 do contain an interface with methods hinting to the 3 maps design Marc is talking about. This is fine proof for me. I think some sort of joint commission should be set up, of people with fine reputation, to report in a certain timeframe as to what happened. Also a sepreare group should find out what to do about it. This is a crissis as big as any, IMO. To the people that are siting on the sidelines: Do something. It does not have to be public. It is when silent majority sits on the hands, and allows immoral things to happen that the society loses. This is about sofware, not about lawyers. I will try to make this last message on the topic of ethics, its up to the people sitting on the hands to see this is as a problem and do something. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
On Wed, 12 Nov 2003, Henning Schmiedehausen wrote: I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. Isn't that what this proposal is proposing? If it isn't, then [EMAIL PROTECTED] is the wrong list to propose it to. We have projects with a much smaller scope as normal jakarta projects and we have and had framework projects such as Cocoon, Avalon or Turbine outside of the commons. IMHO the scope of HiveMind is already to big for the commons which I see as software snacks: Small, easy to swallow and a side order for larger projects. Yes, this proposal is that HiveMind be a top-level Jakarta project; a peer to (say) Log4J and Tapestry. The commons is largely supposed to be for toolboxes; libraries that contain individual utility classes (commons-lang) or frameworks with a very precise, very focused use (commons-logging). Although you could scavenge a lot of useful stuff out of HiveMind, it is intended for use as a cohesive unit. In terms of homes, I can see a number of possible options: 1) Reject HiveMind outright --- and make Howard very sad. In this case, I would reorganize the Tapestry build to accomidate having HiveMind as a sub-project (once the grants from WebCT come through). I feel that is less than ideal; despite the overlap, and evolution of ideas from Tapestry into HiveMind, I'd prefer to keep them seperate, with seperate teams. 2) Keep it in the commons I have no real objection to this personally, but HiveMind doesn't quite fit with the commons charter, for the reasons discussed above (and in the commons charter). 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). 4) New TLD I think HiveMind is a totally useful swiss-army knife that opens up the doors for a lot of really terrific approaches to solving common development problems. However, it's still a bit light to be a TLD ... something like 6600 NCLOC if memory serves (don't bet on it!). Certainly if boil-the-ocean frameworks like Struts, Tapestry and Turbine aren't TLDs then HiveMind isn't either. 5) New Jakarta Project As stated in the proposal; this is my preference. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Howard wrote: 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). I didn't mean to suggest that you should try to move avalon architecture towards hivemind or vice versa, but I did wonder if there would be support @avalon for an alternative approach as an avalon sub-project. The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. Of course you went through this whole debate when we discussed whether we needed Tapestry as an alternative to Struts, as equal members of Jakarta neither approach can be seen to be in any way an endorsed or favourite. The same (IMO) would not be true for service frameworks if Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by some to be Jakarta's favoured solution. FWIW I'm certainly not going to oppose this, Hivemind seems to be a well thought out proposal, but I don't want Jakarta to be accused of trying to replace Avalon, and I guess that will mean involving Avalon folks in the discussion. Imagine the reaction there would be if I proposed a make utility as a Jakarta sub-project, and perhaps you'll get the thrust of my concern. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
FYI: I think someone wanted this to get forwarded to the Avalon 'general' mailing list, but since that doesn't exist, I thought I'd send it to our dev list. For the Avaloners: There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with Hivemind seeing that it has started to outgrow its current location in commons-sandbox. Some have suggested that it fits better over here in Avalon (as a sub-project) than in Jakarta. In some respects, I agree. I think its a little light to be its own top-level project (hivemind.apache.org) and if you look at the jakarta charters vs avalon charters, Hivemind falls more on the Avalon side of things. Not sure what Howards thoughts are on that. --- Danny Angus [EMAIL PROTECTED] wrote: Howard wrote: 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). I didn't mean to suggest that you should try to move avalon architecture towards hivemind or vice versa, but I did wonder if there would be support @avalon for an alternative approach as an avalon sub-project. The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. Of course you went through this whole debate when we discussed whether we needed Tapestry as an alternative to Struts, as equal members of Jakarta neither approach can be seen to be in any way an endorsed or favourite. The same (IMO) would not be true for service frameworks if Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by some to be Jakarta's favoured solution. FWIW I'm certainly not going to oppose this, Hivemind seems to be a well thought out proposal, but I don't want Jakarta to be accused of trying to replace Avalon, and I guess that will mean involving Avalon folks in the discussion. Imagine the reaction there would be if I proposed a make utility as a Jakarta sub-project, and perhaps you'll get the thrust of my concern. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- jaaron http://jadetower.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
