Re: [OT] Microsoft Sets Tolls for .Net Developers
Agreed. I've also been suprised by the recent rise in FUD thats coming our way... http://www.javaworld.com/javaworld/jw-10-2001/jw-1019-iw-netvsjava.html? A nice MS marketting strategy seems to be comparing .Net to EJBs rather than to Java (or Servlets or JAXM or whatnot). Hardly a fair or useful comparison. .Net still seems to use COM under the covers anyways so COM v EJB or .NET v. Java seems more sensible but then I suppose thats the point of FUD afterall. James - Original Message - From: Jon Stevens [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 24, 2001 10:41 PM Subject: [OT] Microsoft Sets Tolls for .Net Developers Why am I not surprised? The funny thing is that even in this down economy and with all the free (better?) alternatives that are out there, people will actually still pay for this stuff! We should put a paypal link on the Jakarta homepage and donate the money to AIDS research or some other worthy cause. -jon -- Forwarded Message Link: http://slashdot.org/article.pl?sid=01/10/24/010249 Posted by: michael, on 2001-10-24 11:40:44 Topic: ms, 153 comments from the firstborn-son-comes-later dept. matsh writes: Today Microsoft [1]revealed the cost of signing up as a developer to .Net. Entry level is $1,000. Standard level $10,000. Custom support will cost even more. References 1. http://news.cnet.com/news/0-1003-200-7629784.html -- End of Forwarded Message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RMI Messaging
JXTA is an attempt to define peer-peer based protocols. (http://jxta.org) RMI is client-server and so not the best way of doing peer based messaging. You might find JMS useful instead for publish / subscribe or queue based communication. Publish / subscribe is very peer based. James - Original Message - From: intan To: [EMAIL PROTECTED] Sent: Thursday, October 25, 2001 5:27 AM Subject: RMI Messaging Hi all, I'm Intan, from Malaysia. Does anybody knows 'bout peer-to-peer system? I really need a help here. please give me your opinion on this coz i've been assign an application which is on messaging system between peers in a real time environment. I've decided to use RMI as the networking structure. So please give me yur opinion on this. Thanx. Regards, Intan -junior programmer
Re: [OT] Microsoft Sets Tolls for .Net Developers
Any plans to do an open source Java implementation of it? :) Then we could do an open alternative to My Services. 'Open Services' anyone? :) James - Original Message - From: Chuck Murcko [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Wednesday, October 31, 2001 4:05 PM Subject: Re: [OT] Microsoft Sets Tolls for .Net Developers We did, several years ago, at Trintech, for Visa, Mastercard, and Amex. They all use it. I think Brother International just adopted it. It even worked over WAP. 8^) But it is not getting all the hoopla that Passport is getting. And it was meant for users to select as a choice, from a website, not to be supplied to them as the default/only thing they can use. Chuck On Wednesday, October 31, 2001, at 06:39 AM, Endre Stølsvik wrote: On Thu, 25 Oct 2001, Fernandez Martinez, Alejandro wrote: | Paying for an online agenda? document storage? e-wallet? This looks like the | e-commerce flop on steroids. This is the stuff that will succeed: Microsoft Passport. Mix in Activation Code. Then pay for My Services. And find yourself placed firmly within MS World with no other options. - Be afraid. Be very afraid! In my opinion, the net does need some kind of ewallet stuff. It's just that M$ is the last company in the world that should own it. Why hasn't VISA and MasterCard and the like done this stuff ages ago? -- Mvh, Endre -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] Chuck Murcko Topsail Group http://www.topsail.org/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] MS makes a better PetShop...
http://msdn.microsoft.com/net/compare/petshop.asp Its not a very fair comparison (suprise suprise) but from a quick look at the source code, it seems MS achieve their performance gains by not using EJBs :-) I wonder what the figures would look like if the PetStore were implemented along similar techniques using just regular JavaBeans and JSP... James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] MS makes a better PetShop...
From: Geir Magnusson Jr. [EMAIL PROTECTED] On 10/31/01 6:45 PM, James Strachan [EMAIL PROTECTED] wrote: - Original Message - From: Jon Stevens [EMAIL PROTECTED] on 10/31/01 1:54 PM, James Strachan [EMAIL PROTECTED] wrote: It would be interesting to have a Java competition - trying the various different techniques, tools and frameworks and seeing how each of them stack up to .NET. Comparing code complexity, performance etc. e.g. with beans or EJBs, with JDBC stored procedures or Turbine, with JSP or Velocity, then on a bunch of runtime platforms and databases and see how they stack up doing the same application. James Unfortunately, none of us in Jakarta land get paid to write demo's so I doubt you will see one soon. :-( I know! I was thinking about it another way. Most frameworks end up making a sample web application to demonstrate them in action. So Velocity, Struts, XMLC, EJBDoclet, JSP tags and so on could just pick the PetStore as a demo to build in the future (or at least a part of it). I've been thinking of converting PetStore to Velocity, as we have had questions on the Velocity list asking about just that. It would give a real apples to apples comparison. As jon notes, it's going to be a bit of work, although we could try to recycle the lutris simple beans... Now, if I could just avoid sleep... ;-) Thinking a bit more about it, using Turbine/Torque or Castor or EJBDoclet or JDO or whatever it should be a pretty quick job to make the 'simple beans'. Then sharing the same set of simple beans we could experiment with plugging in the various display/templating/framework technologies, Turbine, Velocity, JSP/tags, struts, XMLC, Cocoon/XSLT etc. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] MS makes a better PetShop...
From: Geir Magnusson Jr. [EMAIL PROTECTED] On 11/2/01 3:13 AM, Jon Stevens [EMAIL PROTECTED] wrote: on 11/1/01 11:59 PM, Matt Egyhazy [EMAIL PROTECTED] wrote: perhaps sun should make it more clear that petshop is not a benchmark and is instead a multi-faceted example of the possibilities offered by j2ee. i suppose they could rework it and create a benchmark out of it... microsoft is obviously misusing it...and that is possibly what they do best (and are 'doing right'), spread FUD. matt I don't get it though. Why shouldn't a fully functional demo also be able to be used as a real application (or the basis for one)? A pet store shopping cart isn't rocket science. Even if it is just an educational science project, why does it have to be that much more complex and overly done than an equivalent application in another language/system/os. The point being is that M$ claims that their version of PetStore is that much smaller and easier to understand. Well, if their version also has all of the same showcase of features, then how come it is still that much smaller/simpler/faster? Except that (someone noted) that the MSFT version doesn't have all the same features, so it's not a valid comparison. This is an opportunity for us to build a PetStore example w/o a middle tier, and see how that compares to the .NET version. Agreed. It could also be a useful comparison to see how simple Java of PetStore, w/o a middle tier compares to the full-monty, multi-tiered EJB PetStore implementation with data access objects, session beans, entity beans, state beans and all those other patterns. i.e. a way for developers to evaluate what the time performance differences are (both in development, maintenance and runtime) from doing things in a simple way, just at the web tier with a seperation from business logic, persistence presentation or using all the various EJB technologies related patterns. Then developers could see how it affects the amount of code, what different deployment topologies are open to them etc. It could help developers decide when EJB is right for them and when its not. I admit I'm an EJB-cynic myself after being burnt on several projects - however it would be good if the EJB-petstore could clearly demonstrate the benefits they offer over using just regular beans in a single-tier petstore. All that extra money we need to pay to the EJB vendors and all that extra code complexity must have some clearly demonstrable benefits right? :-) James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
request for Karma for jakarta-site2
I'd like to be able to add myself (and maintain my bio) to the who we are page. Could I please have sufficient karma for my user account: jstrachan Many thanks. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Object Relational Mapping
- Original Message - From: Chen, Alan (GSAM) [EMAIL PROTECTED] Hi, I wonder if you have any plans to implement an Object Relational mapping framework. I am very interested to participate in such a project because I don't see EJB entity bean as the solution for all developments. In fact, most people who purchase J2EE servers most likely should be using TomCat instead because they are just buying a very expensive servlet engine with a jdbc connection pool. With an OR layer, we can easily turn TomCat into a scalable application server and developers can focus on writing business rules and logics. We could follow JDO spec to start with and I really think an open source JDO can penetrate into the development community much quicker than Sun's Reference implementation. Or you could petition Sun to open source the reference implementation of JDO then others can contribute to it extend it - like they've already done with Serlvets JSP (Tomcat) and the standard tag library (JSTL). Remember to look out for Castor though I don't think its JDO compatible. http://castor.exolab.org/ Then there's Torque in the Turbine project which is in a similar space, though not JDO. http://jakarta.apache.org/turbine/torque/index.html James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: is a statement of the license in all source files?
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] On Thu, 27 Dec 2001, robert burrell donkin wrote: am i right in thinking that for legal reasons we need to include the complete license text in every source file (rather than just the short form)? My recollection is that you are correct ... we need to be using the long form, at least for the version 1.1 license (i.e. the current one). I thought I saw a mail go by a month or so ago whereby a short form of the licence was allowable in source files that refers the reader to a LICENSE.txt file? James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: is a statement of the license in all source files?
From: Jon Scott Stevens [EMAIL PROTECTED] on 12/28/01 2:03 AM, James Strachan [EMAIL PROTECTED] wrote: I thought I saw a mail go by a month or so ago whereby a short form of the licence was allowable in source files that refers the reader to a LICENSE.txt file? James I have said it about a thousand times...it isn't ok. There is no short form ASF license at this point. There is one for the 2.0 license, but not the 1.1. Thanks for the clarification Jon. I dug out the mail I was thinking of - its 5th December by Roy Fielding titled 'proposed change to ASF license' on [EMAIL PROTECTED] And 2.0 of the license is just a proposal right now - so it should not be used. Just out of interest does anyone know the current status of the 2.0 proposal? Any ideas if or when it might become accepted? James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: J2EE considered harmful
Hi Jeff I share your oppinions on EJB. Whenever I ask developers why they are using EJB the common answer I get from people is 'well I get transactions for free'. When most of the time they don't do 2 phase commit with their database anyways. And all that extra work just to get 'acceptable' performance from EJB. Jeez this stuff is meant to help us not hinder us. I agree that EJB has shoved too many things together in one 'server side component' framework. Perhaps working from core specs is better and just choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias is to use 'local' object technologies such as Java Beans, Servlets, JDBC, JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP or whatnot) when distribution is required. I try to avoid RMI if truth be told. It seems so 80s ;-) I'm still not convinced at all that EJBs are even worth considering when when building web applications - why should be business logic be remote in a web-centric world? Why not deploy the business logic with the web application and save all those costly synchronous RMI calls. You can have seperation of concerns without making things remote. You only have to look at MS's PetShop to see how simple and fast to develop web applications could be while still seperating business logic, persistence and presentation - or how slow and painful they can be if you follow the EJB path. I do think a simple open source alternative to EJB would be a good thing. Already Jakarta has most of the bits almost in place, tying them all together would be cool. FWIW you might want to keep an eye on the AltRMI project at Jakarta Commons which hopes to make RMI and the Remote stuff much easier. James - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 8:38 PM Subject: RE: J2EE considered harmful Amusingly enough, I've been considering writing an article with this exact same title. I've implemented two medium-sized systems using EJBs (http://www.similarity.com and http://mav.sourceforge.net/pig) and I've been haunting the ejb-interest list for more than a year. I was never ecstatic about the technology, but now I'm starting to feel downright disillusioned with it. This is not coming from someone stumbling around with the technology. The first thing I did was read Richard Monson-Haefel's book cover-to-cover, and I started with EJB2.0 (pd1) when Orion was the only implementation. I've got most of the 2.0 spec memorized. I have no trouble writing the deployment descriptors by hand. The problem is, even after more than a year of this, I still find that writing software using EJBs is a steady progress of fighting the technology to make it do what you want. It shouldn't be like this. Having to write three or four different classes, plus an elaborate deployment descriptor for each object slows things down a bit. Tools like xdoclet help, but it's still a complicated and painful process to refactor anything. Basic software design patterns are agonizing or impossible to implement. Observable? Time to learn JMS and Message-Driven Beans. Singleton? Not in the framework... you have to set up an external RMI server. Presistance in the EJBland is a disappointment. Even with EJB 2.0, entity beans are not remotely mature. There is no support for relationship attributes or automatically generated primary keys. The query language is constrictive, offering no support for ordering, aggregation functions, or retrieving data which spans more than a single class. After 20+ years of research and advancement in RDBMS technology, this is a colossal step backwards, and the consequence is that entity beans radically underperform systems with more direct database access. I find that I must constantly sidestep the container with direct JDBC in order to meet performance or feature requirements, and it sounds like this is a common problem. Overall, my feeling is that Sun tried to cram too many disparate technologies into a single API. EJB! It's a distributed object model, transaction model, security model, persistence model, component model, message queue, desert topping, and floor wax all rolled into one! Some of it makes sense, but some of it (especially persistence) doesn't. I'm surprised that people can build large applications with EJB. My guess is that it's probably very effective for one particular class of problem - ecommerce apps. I'm sure it's no accident that all the examples in the spec are Order, LineItem, etc. Unfortunately, this doesn't help me, or any of the rest of the people who are working on applications that are actually interesting. And my guess is that since ecommerce is 90% of the market for expensive app servers, Sun doesn't really care. Ok, enough whining. What to do about it? I really like the idea of an Apache community building a truly free competitor to J2EE. I don't like being tied to
Re: J2EE considered harmful
Hey Andrew Insteresting thread ;-) - Original Message - From: Andrew C. Oliver [EMAIL PROTECTED] On Fri, 2002-02-01 at 04:14, James Strachan wrote: Hi Jeff I share your oppinions on EJB. Whenever I ask developers why they are using EJB the common answer I get from people is 'well I get transactions for free'. When most of the time they don't do 2 phase commit with their database anyways. And all that extra work just to get 'acceptable' performance from EJB. Jeez this stuff is meant to help us not hinder us. I agree that EJB has shoved too many things together in one 'server side component' framework. Perhaps working from core specs is better and just choosing the bits you want/need, JTA, JDO, JNDI:, JMS etc. My personal bias is to use 'local' object technologies such as Java Beans, Servlets, JDBC, JSP, JDO, Turbine etc. Then use 'messaging' (whether it be SOAP, JMS, HTTP or whatnot) when distribution is required. I try to avoid RMI if truth be told. It seems so 80s ;-) I'm still not convinced at all that EJBs are even worth considering when when building web applications - why should be business logic be remote in a web-centric world? Why not deploy the business logic with the web I agree with everything but this. For scalability you should have the option but should not always use it. Agreed. Though I've 2 points to make. #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. Most business logic in most web applications is pretty minimal in terms of computation and is often mostly database intensive so moving this code to another process doesn't usually buy much in terms of scalability - if anything its the reverse thats true - what with all that EJB distributed garbage collection connection based protocol stuff that needs to be done scalability (and usually always performance) can go down. If your application will grow it is good to have a middle tier that can be moved and load balanced. With Entity beans of course this is less possible. (And stateful session beans ;-). I think this is true of traditional GUIs, say a Swing client front end, a middle tier server (say server side beans aka EJBs) and a database. I don't think this is true of web applications as they are quite different things - a servlet engine is not a 'GUI' client. Servlet engines are a stable, performant and very scalable application servers in their own right. Get a hardware load balancer and a farm of servlet engines and your *way* scalable. Arguing for the need for another, remote CORBA component-centric application server based on mostly connection-based protocols, RMI, stubs and distributed garbage collection to make your web-application more scalable seems, well, strange. In my experience web applications scale best when you have a big server farm of servlet engines which are load balanced. A database at the back and hopefully some kind of read only caching going on to take as much load off the poor database as you can. Then you can distribute parts of your web application into different server farms, get load balancing, shuffle things around as load changes etc. Then pick the web technologies of your choice, Struts, JSP, Velocity, Turbine etc. Away you go. I still don't see the 'scalability' argument as in any way advocating that EJBs are actually useful for web applications. In fact this idea that EJBs are required to build scalable web applications is plain false - probably marketing hype spread by the EJB vendors. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: J2EE considered harmful
From: Andrew C. Oliver [EMAIL PROTECTED] #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. True, I don't like the Servlet approach. I tend to admire clean code and a Servlet approach makes this less likely (assuming the team is more than 1 guy and you have differing skill levels on the team). There are many ways to work with HTTP, servlets is just one. There are many others even just at Jakarta. JSP, Velocity, Struts, Turbine, Avalon, Cocoon etc. Incidentally having worked with various 'distributed models' such as CORBA and EJB I find Servlets the cleanest and best designed applicaiton server solution so far by quite some margin. There's a great open source implementation of the spec (Tomcat 4) and look at all the diversity in layers added on top to improve developer productivity. JMS is not appropriate for a number of areas. Like what? In truth I've not yet learned enough about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I'm not into XP, but often the scalability concern happens over night. There should be some framework in place for making it possible to do this somewhat suddenly. There should be a strategy yes. Though this doesn't advocate EJBs. (Though I don't think you are advocating them). I'd say you have about a weeks warning on most systems on just how much you need to scale up after deployment. Systems are make it or break it. You can apply techniques to make this more predictive, but a lot of this happens outside my area of control most of the time. (Political, socio-economic and chaos theory are involved which often result in unpredictable community size, and you must plan to be way off no matter how careful or disciplined your approach) Agreed. Scalability needs to be thought about seriously. I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. I'm more into a scalable version of the RUP. In my opinion XP is a hack of a methodology (the RUP actually covers most of its issues). XP also suffers from the misconception that programming is the most important activity in software development (I would argue requirements gathering as the most important activity in software development...programming is easy, figuring out WHAT to program is hard This is not to say I'm not into an iterative approach to this, only that I think XP is lacking. At least it admits its own lack of scalability.) One day I'll start a project to create a methodology that merges the disciplined approach to software that I admire with the opensource principles and approaches that I think are necessary for effective teamwork. (minus the flamewars ;-) ). Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just That is irrelevant to the issue. Not really but maybe I'm not expressing it properly. Using EJBs wastes *alot* of valuable developer time when they could be doing something more useful like adding new features, making things more scalable or making things more performant. I would like to see an adequate distributed system (which it looks like there are at least 2 in the works within or slightly external to our community), and EJB does not fit the definition. Agreed. because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. That doesn't mean you plug your fingers in your ears and say na na na scalability I'll refactor later. Agreed. I find a balanced approach between planing for the future and refactoring later works best. We do need an adequate distributed object system for some situations. Agreed - but like I said, they are pretty easy to do with HTTP, SOAP, JMS etc. It doesn't *have* to be EJB. That was my main point. Too many developers start building a web application and *start* with the EJB parts - rather than building the actual web application then seeing where EJB, JMS, SOAP or HTTP servers might help to distribute some of the load. I think this is true of traditional GUIs, say a Swing client front end, a
Re: Re: J2EE considered harmful
From: acoliver [EMAIL PROTECTED] On Fri, 1 Feb 2002 18:35:55 - James Strachan [EMAIL PROTECTED] wrote. JMS is not appropriate for a number of areas. Like what? UI, guaranteed failure situations. I don't follow. JMS/MOM is one of the only solutions where clients and servers work in a connectionless way - clients and servers don't need to be running at the same time. The system can handle failures gracefully, with persistent messages, retry, reconciliation, load balancing, fault tolerance etc. In truth I've not yet learned enough about SOAP to speak intelligently about it All I'll say is I think SOAP has a much better future than EJBs. From what I've read I'd tend to agree, though it looks...bulky. Agreed - though its a universal messaging format that can pass across all transports; which is kinda handy. So whether http/email/news/MOM is used you can connect anything to anything across diverse transports. I was just emphasizing that web applications are scalable - just add more boxes - and often they require quite modest hardware. EJB systems on the other hand can often need huge machines just to make quite simple systems. Agreed. I have fully stated: EJB sucks. However it would be nice to have something there where you can isolate your database resources into a pool of *servers* such as with any transaction processing system (going back to even DCE crap -- which did suck too, but served a purpose) Totally agree. I think adding TP type abilities to web/MOM/SOAP would be cool. So it looks like we basically agree. ;-) We're very verbose guys ;-) +10 ;-) James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
I agree Jeff; though for such a smart container to work in an elegant way I'd prefer to develop the beans in a non-distributed manner and the smart container do the rest - distributing what it thinks makes sense - along the EOB / AltRMI lines. Not code to a server side componet API like EJB. Though it seems EJB is going along the 'assume everythings remote and we'll try optimise when things are local'. So maybe there's some sense in that. James - Original Message - From: Jeff Schnitzer [EMAIL PROTECTED] From: Steve Downey [mailto:[EMAIL PROTECTED]] Most objects don't work if they are made distributed without careful consideration. I wonder if that has to be the case. Right now, our distributed object containers are blissfully stupid. We (humans) can point at any individual class or interface and say remote thyself! but that's as far as it goes. The container just does what we programmers tell it to. Just like me, a hypothetical smart container could make some pretty educated guesses about where and when a set of existing objects should be remoted. Furthermore, it could automatically learn, over time, not only where the best boundaries are, but what are the best situations to perform the remoting/migration. Instead of deciding which classes should be remote, a smart container could decide which *objects* should be remote. And it could learn the answers by watching object behavior over time. Of course, architecture would still have a big effect on performance - but it does already, even in a single-machine environment. We don't hand-optimize our assembly anymore, and suspect that eventually we won't be hand-optimizing our distributed systems, either. JADE and Mobile Agents are not quite what I have in mind. The agent concept is very thread-centric, whereas this idea is object-centric. It sounds like EOB and AltRMI are closer to the mark. I'm going to have to take a long look, and maybe try to restart this discussion on one of their mailing lists :-) Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java is dead... but it could still be saved!
on 2/4/02 8:29 PM, Aaron Smuts [EMAIL PROTECTED] wrote: Could someone explain the issue, especially with reference to JSR107 (JCACHE). Aaron Yes. I'm on JSR 107 and I seem to be the only really vocal person there about my needs. Brian Goetz cares as well, but isn't nearly as vocal. Simple: JSR107 is being created under a non-open source license and Oracle will own the rights to the specification of the JSR. I'm complaining about this wildly. I've asked Jerry the Oracle guy several times (off-list) and he claims that one day Oracle will commit to releasing an open source reference implementation - but I'm still waiting for an official announcement - and its been 5 months and counting... James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Manual (was ApacheForge)
I think one thing this conversation seems to have highlighted is that there's plenty of good documentation all over the apache sites, we could just do with some more sitemap / indexing / searching features to be able to find stuff. (quickly ducking before people think I'm volunteering). James - Original Message - From: Fernandez Martinez, Alejandro [EMAIL PROTECTED] To: 'Jakarta General List' [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 12:31 PM Subject: RE: Apache Manual (was ApacheForge) Ok, thanks a lot, Marc and Jon. Included are some links from xml.apache.org, luckily they resemble Jakarta's documents a lot. I know nothing about other Apache projects; I started adding links from httpd.apache.org like crazy, but then realized that the TOC was losing focus exponentially. Probably, someone else should tackle this problem. Now, including the valuable contributions of Marc and Jon, the annotated Apache manual TOC would look like this. 1.- Introduction Who we are, why are we doing this. http://jakarta.apache.org/site/whoweare.html http://xml.apache.org/whoweare.html http://httpd.apache.org/ABOUT_APACHE.html 2.- Project proposal Proposal stage, committers needed, community. http://jakarta.apache.org/site/getinvolved.html http://jakarta.apache.org/site/newproject.html 3.- Apache rules Who gets to vote what. Voting rules, valid votes, +1/+0/0/-0/-1. http://jakarta.apache.org/site/roles.html http://jakarta.apache.org/site/decisions.html http://xml.apache.org/roles.html http://xml.apache.org/decisions.html http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt 4.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. http://jakarta.apache.org/site/dirlayout.html http://jakarta.apache.org/site/guidelines.html http://jakarta.apache.org/site/agreement.html 5.- Code quality Add copyright notice, add authors. Format your code but not others'. http://jakarta.apache.org/site/agreement.html http://xml.apache.org/source.html 6.- Testing Adding test cases. Solving bugs, errors, showstoppers. Security problems. http://httpd.apache.org/security_report.html 7.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. Not done yet. 8.- Dependencies What jar's to use and what to avoid. http://jakarta.apache.org/site/jars.html 9.- Documentation Where to look for it. What to expect, what not to expect. Not done yet. 10.- Releases When to release, what to release. Release process. http://jakarta.apache.org/site/binindex.html 11.- Support Whom you should ask, what you should figure out yourself. http://jakarta.apache.org/site/mail.html http://xml.apache.org/mail.html 12.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. http://www.apache.org/foundation/licence-FAQ.html http://xml.apache.org/dist/LICENSE.txt -Mensaje original- De: Marc Saegesser [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 20 de febrero de 2002 20:19 Para: Jakarta General List Asunto: RE: Apache Manual (was ApacheForge) Alex, That's a really good start. My only comment right now is to point out that some of the topics in this list are Jakarta specific and Apache is much bigger than Jakarta. It would be cool if a manual such as this covered how other Apache projects handle similar tasks. I'd also include a chapter on Apache and Jakarta rules. For example, voting rules, what constitutes a valid vote, what are the voting types and when they apply, what are meanings of +1/+0/0/-0/-1 in the various voting types. A collection of release instructions for various projects might also be useful. When I was the release manager for Tomcat 3.2.x I got some initial help from Craig, but after that I had to invent most of the process myself (and I'll be the first admit that I didn't document that process :-( ). I'm sure I think of more after giving it some more thought. Good start, though. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JakartaOne?
JavaOne is around the corner. Do any Jakarta folks fancy a JavaOne get together in a bar somewhere? Maybe Jon's new bar? James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JakartaOne?
This all sounds great - am looking forward to it. And to answer Jon's mail too, Tuesday sounds good. Apart from just meeting folks, having techie chats and drinking beer, it will be nice to do some cross-group fertilization. There's so much going on that its hard to keep track of it all. e.g. Maven is new to me ;-) James - Original Message - From: Geir Magnusson Jr. [EMAIL PROTECTED] On 3/4/02 1:25 AM, James Strachan [EMAIL PROTECTED] wrote: JavaOne is around the corner. Do any Jakarta folks fancy a JavaOne get together in a bar somewhere? Maybe Jon's new bar? I was thinking about this earlier in feb, but wasn't sure we had the time... I wanted to call it 'OpenOne' (but 'JakartaOne' is nice...) and use a space like Jon's where we could have both a social gathering as well as some short technical talks on things that didn't make it into JavaOne (for example, if it didn't have anything to do with XML or web services). Here's what I had so far as a draft : I would like to get a sense of community interest for the following idea Proposal Hold an off-site convention during the week of JavaOne to provide a venue for topics that didn't make the cut for JavaOne as well as topics that did, of course. Examples include (imagination challenged right now...) o bastard J2EE technologies - template engines (could you guess I would suggest this ?) - publishing frameworks (Cocoon et al) - web app frameworks (Turbine, Maverick, Struts) - ? o mainstream technologies - web services (I want to hear Sam talk about Axis :) - XML-RPC - ? o community discussions - JSPA issues - ? o other stuff - how about JDD talking about Objective C - Gump sociology - Maven Rationale - There are a lot of interesting things in the world that Sun's marketing crew doesn't have space or interest for at JavaOne. Many of these things are in daily production use by people, and it would be nice to hear about them. Many developers will be in the area for this week, and if we could find a way to bring us together for both social interaction as well as learning about some of the topics we work on and are interested in, it seems like a win all around. Thoughts We have an in with an event space in San Francisco (hey, Jon!) and from what I understand, it has two distinct spaces, one of which can serve alcohol. So we can divide, cleanly, the social space and the technical space. Those in the social space can bring their own, I guess :) However, I think if we do this, we should pay for the space (unless studio.tv wants the publicity :), and there lies a conflict of interest problem, but I assume that if the rate is competitive, as I am sure it will be, we can all look the other way. I don't know if we have the time to pull it off - it would be nice to put something non-lame together. I think we shouldn't be aggressive about this - find a spot in the schedule so people aren't torn between J1 and this... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting The bytecodes are language independent. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: POI web update
jakarta.apache.org/ant and jakarta.apache.org/avalon added. Is jakarta.apache.org/commons in the list - if not can we add that too please? James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] JCP rant
Totally agree. Though its worth mentioning that the Servlet, JSP JSTL JSRs all have their their reference implementations developed at Jakarta (Tomcat jakarta-taglibs) so there's CVS, a public archived email list and bugzilla. I do hope that these JSRs start a trend that most/all JSRs open source the RI and TCK. It just makes so much sense. I think Sun as a company still have a lot to learn about open source; though there's plenty of good people at Sun who are showing the way. I'd prefer all EG communication to be open on a public forum though I understand that sometimes privacy enables some companies to participate do to IP issues. James - Original Message - From: Daniel F. Savarese [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 21, 2002 7:12 PM Subject: [OT] JCP rant Somebody asked on the axi-user mailing list why they should use Axis instead of JAXM. I offered some comments, but tried not to stray too off topic. In light of a recent JCP-related thread, I thought there might not be any objections on general@jakarta if I vented for a minute. When you use JAXM, you'll run up against all sorts of limitations and the best you can do is send a suggestion/comment to an email address. With Axis, or any Apache project, if you run up against a limitation, you can discuss it on a mailing list and submit a patch. Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and provide source code tend to produce better results than those with fewer feedback cycles. I'll use JAXM and JAX-RPC as examples. JAXM had no mailing list for developer discussion/feedback as it was being designed/developed with only the usual JCP JSR comment address. JAX-RPC has a jaxrpc-interest mailing list that has helped the spec evolve into something more likely to be useful to developers. With something as simple as a mailing list a JCP JSR can gather much better requirements. However, neither JSR provided source for their reference implementations, making debugging and patch submission an impossibility. The problem with the JCP is not merely the licensing. It is also the basic JSR procedures. The objective of a new API is to meet some set of developer requirements in a particular application domain. If you don't consult with your users, the target developer group, you probably won't develop a useful result. JSRs would produce better results if run a little more like Apache projects, with more opportunity for user feedback in an open forum to mold the ultimate result into something useful. daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Why Sun won't certify JBoss (was Re: Jakarta is not an open source project in the pure community sense anymore)
A thought struck me today which is probably totally obvious to folk but I thought I'd share it anyways. Sun gets pots of cash from companies who develop J2EE compliant software from the J2EE license fees. So its in Sun's interest to protect the BEA's, IBM's and their own J2EE products. The money they get is based on revenue of the company (so thats quite a lot of money from BEA IBM). The money-men at Sun probably see open source J2EE solutions as lost revenue to possible commercial J2EE solutions so when folks like JBoss come along they see it as in Sun's interest to not certify them to protect their J2EE licence revenue nest egg. Though with the .NET competition now I think its in their interest to protect their J2EE market place by allowing open source solutions; otherwise long term folks will just move away from J2EE. James - Original Message - From: Stephane Bailliez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 22, 2002 4:52 PM Subject: Jakarta is not an open source project in the pure community sense anymore Apparentely I did not pay attention to those many gremlins working out for Sun and IBM in Jakarta and that are so closed... doh ! See Marc Fleury's interview. --- http://www.onjava.com/pub/a/onjava/2002/03/20/jboss_interview.html [...] Anglin: There has been much speculation of late regarding JBoss and Apache Jakarta. Could JBoss become a Jakarta project? Fleury and Mason: No, we don't see that happening. Jakarta is not an open source project in the pure community sense anymore. It is dominated by Sun/IBM employees. We are more focused on growing our own professional services organization through JBoss Group. As such, we form a hyper-efficient consultancy, where our open source product base enables us to achieve an unparalleled degree of efficiency in sharing and communicating knowledge. You may feel that our open source nature limits us here, but never when it comes to high-level knowledge. The ability to see and reproduce source code does not automatically give people the understanding of how it's used or how it can be optimized. If they do achieve that on on their own, that's great. For those who want more insight, we sell the services to get them there. The second reason for our dissatisfaction with Apache has to do with problems in the 3.2 version of Tomcat (the new one is better). When those problems arose, we grew close to Jetty, a competing open source project backed by MortBay Consulting in Australia. We met these guys, spent time with them, and we found there were a lot of similarities -- they are a husband-and-wife-led company dedicated to their product because it is their business. It just happens that we relate better to people with goals and expectations similar to ourselves --dedicated independent professionals. JBoss Group is about supporting and promoting that way of life and work, which, in our opinion, is conducive to the development of great software. [...] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta is not an open source project in the pure community sense anymore
I thought this was a good article - apart from arguing that Apache is not a true open source project in the community sense which I think is just plain wrong. Its got the best community by far of any open source project I'm aware of though I guess thats pretty subjective. Other than that I think Fleury Mason make a very convincing argument that Sun should allow JBoss to be certified. The quote from Karen Tegan is interesting... At the same time, having a strong brand and compatibility standards are important to the development of a robust market for J2EE platform products, tools, and components. The J2EE Compatible brand has achieved significant momentum over the past two years, and we want to make sure that any open source efforts don't impact the viability of that effort. This does not seem like an argument as to why JBoss cannot be certified. Indeed this seems to suggest that JBoss should be openly tested for conformance to protect the 'J2EE Compatible' brand. Otherwise the only alternative is to create an open source 'JBoss Compatible' brand (i.e. an open source J2EE test suite) instead which would only serve to fragment the J2EE marketplace and weaken the viability of the 'J2EE Compatible' brand. James - Original Message - From: Stephane Bailliez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 22, 2002 4:52 PM Subject: Jakarta is not an open source project in the pure community sense anymore Apparentely I did not pay attention to those many gremlins working out for Sun and IBM in Jakarta and that are so closed... doh ! See Marc Fleury's interview. --- http://www.onjava.com/pub/a/onjava/2002/03/20/jboss_interview.html [...] Anglin: There has been much speculation of late regarding JBoss and Apache Jakarta. Could JBoss become a Jakarta project? Fleury and Mason: No, we don't see that happening. Jakarta is not an open source project in the pure community sense anymore. It is dominated by Sun/IBM employees. We are more focused on growing our own professional services organization through JBoss Group. As such, we form a hyper-efficient consultancy, where our open source product base enables us to achieve an unparalleled degree of efficiency in sharing and communicating knowledge. You may feel that our open source nature limits us here, but never when it comes to high-level knowledge. The ability to see and reproduce source code does not automatically give people the understanding of how it's used or how it can be optimized. If they do achieve that on on their own, that's great. For those who want more insight, we sell the services to get them there. The second reason for our dissatisfaction with Apache has to do with problems in the 3.2 version of Tomcat (the new one is better). When those problems arose, we grew close to Jetty, a competing open source project backed by MortBay Consulting in Australia. We met these guys, spent time with them, and we found there were a lot of similarities -- they are a husband-and-wife-led company dedicated to their product because it is their business. It just happens that we relate better to people with goals and expectations similar to ourselves --dedicated independent professionals. JBoss Group is about supporting and promoting that way of life and work, which, in our opinion, is conducive to the development of great software. [...] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Sun is proposing changes to the JSPA draft so that all of Apache's requirements are satisfied
Great news! http://jcp.org/aboutJava/communityprocess/announce/LetterofIntent.html James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
From: Peter Donald [EMAIL PROTECTED] Sou you end up with something like following in torque MyData (The Biz Object) MyDataVO (The Value Object) MyDataPeer (The Peer) AbstractMyData (the abstract biz object) AbstractMyDataPeer (The abstract Peer) And the only one decoupled from the persistence framework is MyDataVO. In an ideal situation you would just have a single object MyData that is free from persistence framework and is nice and simple. (and basically a clone of MyDataVO). The rest of the stuff could be dynamically configured at runtime - including the mapping to physical datasource. Any system that did that and did not have all the rest of the cruft would be a sure winner IMHO. Agreed. I've wondered a few times if maybe Torque could be patched so that in addition it could work with DyanBeans as an alternative to code generation. Then at runtime Torque could just work given some regular beans (MyData) or even just figure out its own DynaBeans based on the database schema. http://nagoya.apache.org/gump/javadoc/jakarta-commons/beanutils/dist/docs/ap i/index.html James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject - satyr
It also uses Xalan/Xerces for it's XPATH/XML requirements If you want a fast XPath engnie you might find Jaxen useful. http://jaxen.org e.g. http://dom4j.org/benchmarks/xpath/index.html James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [New Subproject Proposal] ObjectBridge
I'm a non-binding +1 on moving OJB to Jakarta BTW. More below... From: Jon Scott Stevens [EMAIL PROTECTED] on 4/30/02 11:11 AM, Gerhard Froehlich [EMAIL PROTECTED] wrote: PS: hmm curious if takes the jon hurdle ;-). +1. The proposal and project clearly meet ALL of the requirements set out on the newproject page. I would really like to see some sort of commitment to torque-obj integration/use/conversion/whatever though. Agreed. I'd like to see how the Torque XML database schema document could be used to generate the SQL, documentation and OJB compliant model too. Then we'd have the best of both worlds. I noticed Torque already has a 'project-ojb-model' which kinda works (and looks much cleaner generated code than the Torque equivalent) but doesn't quite work yet. It certainly looks like a promising area of development. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DRAFT1] Jakarta Newsletter - November 2002
From: Jeff Martin [EMAIL PROTECTED] Don't suppose you'd consider putting a link to XMLUnit http://xmlunit.sf.net/ in the Jelly section. It's always good to try a bit of shameless publicity seeking ;-) Its pretty well hidden, but there is a link in the Jelly tag reference... http://jakarta.apache.org/commons/sandbox/jelly/tags.html#jelly:xmlunit as well as in the javadoc http://jakarta.apache.org/commons/sandbox/jelly/apidocs/org/apache/commons/j elly/tags/xmlunit/package-summary.html so there is at least some XMLUnit publicity there :-) James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Forum Software.
Try gmane http://www.gmane.org/ then you can use your favourite news reader software to browse the already existing mail lists - it supports replies too. James --- http://radio.weblogs.com/0112098/ - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: Jakarta General [EMAIL PROTECTED] Sent: Wednesday, January 22, 2003 4:07 PM Subject: Forum Software. Well, once again I would like to bring up the concept of forum software for Jakarta. The reason I am bringing it up again is that mailing lists are intrusive and spammy. Daily I get flooded with a ton of email that I have absolutely no interest in reading. However if I unsubscribe to the lists than when there is something that I would like to know about or answer, I will miss it. In addition, if I unsubscribe I'm not able to post my own issues. With a mailing list, the communication mechanism is just too intrusive. On a forum I can pick and choose what I want to read and reply to. As for them being used, its a simple matter of retiring mailing lists for forum software. When we consider that at least 90% of Jakarta users are not Jakarta developers but will often have a question or an important insight, than the folly of communicating only in mailing lists becomes clear. -- Robert Simmons __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Forum Software.
From: Danny Angus [EMAIL PROTECTED] I think this is a terrible idea, unless... we had a mail-news gateway which would expose the lists as news groups. They already are. Point your browser/newsreader at news://news.gmane.org/ or in particular here and follow this thread in your news reader... news://news.gmane.org/gmane.comp.jakarta.general James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Fwd: Maven as a top-level apache project]
From: Costin Manolache [EMAIL PROTECTED] Maven is a nice tool - and I wish it good luck wherever it goes. But if Maven charter will include the creation of a maven-only repository - I hope at least some board members will vote -1. I don't see that ever happening. Already the Maven repository can be used by Maven itself, the generated Ant builds and, by the sounds of things, Centipede too You can even use your web browsers to surf download jars yourself. e.g. surf this... http://www.ibiblio.org/maven/ James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
