Re: What's up with Avalon? (was: Any James developers here?)
Sam Ruby wrote: > > Pier P. Fumagalli wrote: > > > > > (going round and round and round...) > > > > Yeah, and it seems not enough... What are the other two modules > > that suddently appeared on the CVS? jakarta-avalon-logkit and > > jakarta-avalon-testlet > > > > They also have wrong permissions, along with the main > > jakarta-avalon repository... WAAAHG!! > > Furthermore, at some point after 4:47pm EST yesterday and 3:37 EST this > morning, the framework cvs on java.apache.org was gutted, and as of this > moment the jakarta-avalon* cvs trees do not appear to be completely > populated. > > WAAAHG!! The jakarta-avalon is empty now as avalonis undergoing a maior spring cleaning to prepare for the move. Hope the finalize the move by the end of this week. In the meanwhile please have patience... Fede - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Any James developers here?
Jon Stevens wrote: > > on 2/14/01 2:38 PM, "Federico Barbieri" <[EMAIL PROTECTED]> wrote: > > >> Ok, so can we agree on this: > >> > >> /home/cvs/jakarta-avalon-foo > >> /home/cvs/jakarta-avalon-bar > >> /home/cvs/jakarta-avalon-whatever > >> /home/cvs/jakarta-avalon-peter > >> /home/cvs/jakarta-avalon-federico > >> /home/cvs/jakarta-avalon-yourmother > >> > >> ? > >> > > > > You're missing my point... > > org.apache.avalon and the kernel and blocks implementation are two > > different project. Very different. The avalon package's goal is to > > create a set of design patterns, contracts and interfaces to enforce > > good software design, runtime code reusing, IOC, SOC, etc. Phoenix is an > > intergation framework. Cornerstone is a set of default services for > > Phoenix. > > > > avalon is way much closer in the way it should be developed, goals and > > needs to the jakarta-util project rather than Phoenix. I whould strongly > > agree to have that code into the util project. > > Many avalon patterns are used by Phoenix, James, Cocoon and similar > > concepts are in Turbine too. So it should be in a common > > project/repository, not duplicated in each project. > > > > So what about merging avalon into the jakarta util and let Phoenix and > > Cornerstone live together in a separate CVS? > > > > Fede > > And you are missing my point. > > I don't care how many different CVS trees there are. Just prefix them with > "jakarta-avalon" if it is at all Avalon related. If it is related to another > project that you would like to create, then you need to propose that as > another project, not just another CVS tree. > > -jon > That's fine with me. so let's ge for jakarta-avalon jakarta-avalon-phoenix jakarta-avalon-cornerstone Is it ok with everybody? Fede - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: > > On 2/9/2001 at 8:12 AM Sam Ruby wrote: > >I would suggest that you start with a proposed code base. > > Going back over the posts, there seem to be at least five clear areas of > overlap: > > * XML Configuration +1 > * JNDI / Naming +1 > TESTING SUITES > > [Ant] testlet framework (basically similar to early versions of JUnit) > > [Tomcat/Watchdog/Slide/Ant] HTTP test clients for unit tests. > > [Xalan] Testing infrastructure proposal > < http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98183907325686&w=2 > There may be something interesting in the avalon project too under org.apache.testlet. Fede - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Any James developers here?
Jon Stevens wrote: > > on 2/12/01 1:33 PM, "Federico Barbieri" <[EMAIL PROTECTED]> wrote: > > > That's exactly why I want to split java.apache.avalon into three CVS! > > > > API (design patterns, interfaces, contracts etc. have a very different > > lifecycle from the framework implementation and it's critical to the > > health of projects depending on those API to have two development > > pipeline separated. > > > > Most of the org.apache.avalon package is quite stable... it's been > > stable for more than one year! What keeps changing is the kernel > > implementation (Phoenix) on wich dependencies are weeker. > > Ok, so can we agree on this: > > /home/cvs/jakarta-avalon-foo > /home/cvs/jakarta-avalon-bar > /home/cvs/jakarta-avalon-whatever > /home/cvs/jakarta-avalon-peter > /home/cvs/jakarta-avalon-federico > /home/cvs/jakarta-avalon-yourmother > > ? > You're missing my point... org.apache.avalon and the kernel and blocks implementation are two different project. Very different. The avalon package's goal is to create a set of design patterns, contracts and interfaces to enforce good software design, runtime code reusing, IOC, SOC, etc. Phoenix is an intergation framework. Cornerstone is a set of default services for Phoenix. avalon is way much closer in the way it should be developed, goals and needs to the jakarta-util project rather than Phoenix. I whould strongly agree to have that code into the util project. Many avalon patterns are used by Phoenix, James, Cocoon and similar concepts are in Turbine too. So it should be in a common project/repository, not duplicated in each project. So what about merging avalon into the jakarta util and let Phoenix and Cornerstone live together in a separate CVS? Fede > -jon > > -- > If you come from a Perl or PHP background, JSP is a way to take > your pain to new levels. --Anonymous > <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Any James developers here?
Sam Ruby wrote: > > It looks like Avalon has been steadily deprecating interfaces that James > has been depending on. Now James is broken. > >http://jakarta.apache.org/builds/gump/2001-02-11/james.html > > Who wants to volunteer to look into it? > > Standard reason: if one wants to deploy a server solution involving > multiple Apache Jakarta subprojects, each of which depend on different > point in time snapshots of Avalon, which version of the avalonapi.jar > should one put into the classpath first? > > - Sam Ruby > That's exactly why I want to split java.apache.avalon into three CVS! API (design patterns, interfaces, contracts etc. have a very different lifecycle from the framework implementation and it's critical to the health of projects depending on those API to have two development pipeline separated. Most of the org.apache.avalon package is quite stable... it's been stable for more than one year! What keeps changing is the kernel implementation (Phoenix) on wich dependencies are weeker. > P.S. Kudos to the Avalon team for deprecating interfaces. > Federico - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is reuse
Conor MacNeill wrote: > > Continuing the "What is ..." theme. > > I don't have a stake in the current DB Connection pooling argument. I don't > use either pool in my day to day work or within Ant. However, I have found > the discussion interesting, especially as I have just read Richard > Gabriel's "Patterns of Software". He deals with reuse a little and I think > he makes some interesting points: > > "First you need a central repository of code. It doesn't help if developers > have to go around to other developers to locate code you might be able to > use" > can't agree more on this! > "Second, there has to be a means of locating the right piece of code, which > usually requires a good classification scheme. It does no good to have the > right piece of code if no one can find it." > > "Third, there must be good documentation of what each piece of code in the > repository does." > Good documentation in a repository can solve the search problem quite well. > "For a lot of pieces of code it is just plain simpler to write it yourself > than to go through the process of finding and understanding reusable code". > > I think this last point is particularly strong in open source projects > where a lot of people want to implement things themselves. > This makes sense if I want to rewrite a piece of code I don't like. Most times I'll rewite code 'cause I don't know there is already an implementation. One of the biggest mistake (IMHO) is to say "it takes me 2 days to write the code. Why should I spend a week just to learn how to use other's people code?". Well usually because in two days you can't do what others have done in a year. Good architecture, debugging, features you may not need now but can relif a lot of work later etc. As I said reuse is the only way to create and enforce standards from the bottom up (not from some high authority). And standards are the only way to scale projects. One place to search is critical but it's not the only reason I think one CVS is better... one repository guarantee all this packages order and coherence. This for example means it takes less time to learn how a pakage works from the second time on. Can we have a kind of votation on a new jakarta-util project? (details about can be finalized later once we agree on goals) Federico [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Back to Avalon...
Jon Stevens wrote: > > on 2/2/01 12:27 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote: > > > At 11:10 2/2/01 -0800, Jon Stevens wrote: > >> Ok, I'm seeing other people discuss this without any sort of final decision > >> here, so I think we need to get back on topic. So far, top level package > >> names are expressly reserved for top level projects. > > > > Well not every one seems to obey it. Examples include catalina (3 top level > > names - catalina, naming, jasper), James (mailet, james). I am sure I could > > for more examples if I looked ;) > > I personally obey it and as someone at the PMC level, then I see my job as > being to encourage you and others to obey it as well. Two wrongs don't make > a right. I personally think that the namespace for Tomcat should really be: > > org.apache.tomcat > org.apache.tomcat.naming > org.apache.tomcat.jasper (at least until it is split out of the Servlet API) > > Catalina itself should live within the Tomcat namespace since it is simply a > revolution that has already been voted to become Tomcat. > > For a perfect example of this, I created Anakia which is used as the basis > to power our website. I placed Anakia within org.apache.velocity.anakia and > created a small documentation page for Anakia within the Velocity project. > > There are several things within Turbine that could be spun out as separate > projects as well such as Torque, DB connection pool, Intake, etc...however, > I haven't found the need so far to do that...(although, it is starting to > become more clear there is a need for that)... > > >> I would be +1 for something like this: > >> > >> org.apache.avalon > >> org.apache.avalon.phoenix > >> org.apache.avalon.cornerstone > > > > I would be -1 for it ;) The reason is we are just moving away from this. > > The reason is that the base framework is used by phoenix rather than > > phoenix being a part of avalon. I would put it in the same acceptability as > > mandating "org.apache.turbine.jetspeed" as Jetspeed uses Turbine. > > Then you should be suggesting another top level project be created instead > of creating a pseudo project that is half within Avalon and half within the > top level namespace. > > Just like there is for Jetspeed. > not sure... from Peter point of view phoenix is one possible kernel implementation exactly as cocoon is (uses avalon as scheleton) as James (is a block but a mailet container/engine too) and as turbine or jetspeed could be. Remember avalon is not by any mean related to the idea of Block. It's just a set of abstract design patterns and some utils. Right now I'm +0.5 for peter proposal. But I don't want this to stop avalon from moving. Federico Barbieri <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Struts? (was: Re: What is Avalon?)
Ted Husted wrote: > > > The desire to work together is core to my thesis that there is a > Jakarta community here. > > There often seems to be an assumption that our resources, or community, > is limited. There are a great number of Java developers in the world, > and our numbers grow every day. A project like Struts, with a clear > internal focus on J2EE compatability can easily attract developers that > would not otherwise contribute. I happen to be one. > > When considering the merits of a product, it is important to consider > the human factor of both our users and developers. It's no secret the > teams working on competiting solutions often "hate each other". Maybe > that's a good thing. It may not be as efficient, but given the human > factor, duplicating resources and fostering competition is usually more > * effective * than "benevolent" cooperation. > > We need more than just science. We need scientists. > > Are we developers looking for projects, or products looking for > developers? > > Are we building a cathedral, or a bazaar? > just a quick note... a pure bazaar does not scale. period. IMHO if two project share some needs it's probally more a pain than a gain to enforce code sharing too. But a third new project will probally benefit and so all following. It's a matter of opening the path in a forest to make things easier for followers. So I'm very +1 for a jakarta util project. Code sharing is the only way to create standards (good standars) inside apache itself without following Sun footsteps. That's the main goal of Avalon. For example it defines and implements a lookup service very different from JNDI (ComponentManager). It's not a Sun standard but IMHO it's much better for some situation. Many devs and users on the list are very happy about it and are using such pattern in their own products creating a new standard. It's hard not being Sun to enforce a standard but... I mean... we are Apache! Not an unknown group of loosers! :-) If you need a volonteer for jakarta-utils I'm definitly in. Federico Barbieri <[EMAIL PROTECTED]> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
