Re: sorry - where is the techncal list?
Horace Vallas wrote: sorry for the interruption, but I'm looking for the list to which technical questions on tomcat (in particular) can be posed - I see many of the names I would expect but, lately, this now seems to be a list for discussions of organizational and infrastructure issues and I just have (probably simple) questions on tomcat and related items. You might consider the tomcat-user and tomcat-dev lists : http://jakarta.apache.org/site/mail.html read that, and follow the link at the bottom. geir If this is the technical questions list (it is what I had watched for a while), may I respsectfully suggest that a new list be formed for organizational issues and such - I know these are important, but they seem to be producing a lot of conversation and causing technical questions to, sort of, get lost in the volume. -- Wishing you an "OOBA OOBA" 21st Century (at last) Horace...once known as "Kicker" :-) Horace Vallas hav.Software http://www.hav.com/ P.O. Box 354 [EMAIL PROTECTED] Richmond, Tx. 77406-0354 voice: 281-341-5035 USAfax: 281-341-5087 Thawte Web Of Trust Notary in SW Houston, Tx. http://www.hav.com/?content=/thawteWOTnotary.htm ...drop by and chat if I'm online http://www.hav.com/chat/ === === === === === === === === === === What is a Vet? ... He is the barroom loudmouth, dumber than five wooden planks, whose overgrown frat-boy behavior is outweighed a hundred times in the cosmic scales by four hours of exquisite bravery near the 38th parallel. ... - Unknown http://www.hav.com/vet.htm ==== -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anna Kournikova virus (fwd)
Willie Wheeler wrote: FYI, I just got this message that indicates that the virus we just received uses mail client address books to propagate itself. *Microsoft* mail client address books. That's the critical piece... geir Willie -- Forwarded message -- Date: Mon, 12 Feb 2001 16:46:11 -0500 From: Jean Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Anna Kournikova virus Another new virus has popped up in the SCS environment. Here are the details: 1. The virus uses mail client address books to propagate itself, so you may get the virus in a mail message from someone you know. 2. It is an attachment, so if you do not open it, you are not infected. Simply delete the message. 3. If you got it and you opened the attachment, send mail to [EMAIL PROTECTED] The subject line of the mail might contain the following verbiage: "Here you have, ;o)" "Here you go" "Here is..." "Here you go :-)" The content of the mail might contain: Hi! Check this! Followed by the virus attachment, which is AnnaKournikova.jpg.vbs Jean Rogers SCS Facilities Help Desk Wean 3613 412-268-4231 www.cs.cmu.edu/~help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - 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: * DataSource/Database Pool +1 * XML Configuration +1 geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here you have, ;o)
"A.T.Z." wrote: Hi friends, Just relax. Wanne know the solution to these VBS things flying around?? It's so very very very easy, even costs you US$ 0,00 Man, I was hoping for a good riff on getting rid of the risky software that exposes millions of users to millions of dollars in data and opportunity loss from a company that doesn't seem terribly interested in solving the problem on behalf of their clients Alas. Associate .vbs with notepad so it launched notepad whenever you (or anyone else) tries to open it. I would suggest doing the same thing with .js This is the 'Raising the Bar' approach : keep those virus writers challenged Since no one can see the source code, it makes it a fun game for both the virus writers and the users - kind of a digital pinata. The only question is who gets to swing the stick. I would also suggest you get yourself a decent (and recent) piece of antivirus software. No reason to bomb anyone who uses Outlook.. And most certainly no reason to bomb me. Remember: the person who double clicks the attachment has no wish to do you any harm. True. But at this point, isn't this bordering on negligence? "Sorry, I didn't know the gun was loaded." "Ok. Just be careful next time." next time "Sorry, I didn't know the gun was loaded." I mean, you could argue that everyone was taken by 'surprise' at the Melissa outbreak, but isn't this the same problem again? geir Bye, B. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Sam Ruby wrote: Geir Magnusson Jr. wrote: Call it 'Rupert'. Be careful, that name might stick. ;-) That would be fine - forward progress! I guess the logo would be next... :) I mean, with Tomcat 4, nothing really guarantees that you won't abandon Servlet 2.3 for the Wiggly Green Spec from Planet Mongo, but I trust that you will stick to your 'mission'... :) The are *SOME* things that the PMC are ready, willing, and able to enforce immediately. You just happened to pick one of them. Really? How's that? If all the developers decided to switch to the WGSfromPM, what could the PMC do? I am not trying to be argumentative - I just thought that the PMC was well described as 'general oversight' with project-specific issues pushed down to the project participants. If the tomcat developers, arguably some of the top-tier servlet infrastructure developers in the world, decided that the WGSfromPM was superior to Servlet 2.3 ? Granted, Craig would be looking for a new employer, I think... :) Not to mention the fact that the likehood of a majority of Tomcat developers would be predisposed to consider such a thing is basically nil. And back to the issue, that is kinda my point : if you have a group of developers committed to producing a top quality db connection pool for general use, it's not clear that there is much one could do to enforce API stability in an external way that makes sense. At some point, you have to trust someone involved with the project... geir - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
Ted Husted wrote: Sam Ruby wrote: Whilst this group seems to have difficulty agreeing on anything grin, perhaps a proposal to create a new list could get enough support? Heck, it might even get some +1's from people that DON'T want to be subjected to this discussion any more. ;-) Ok, based on the response to the poll tallied at http://husted.com/about/jakarta/library.html Man, you are *damn* organized :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: The project should _host_ and maintain code that is shared by projects, not _develop_ utils that may be needed ( like CPAN, or alexandria ). How can that work in the current "project committer" model? I agree that it should be open to accept projects from the 'outside', but I think that to do that, it is required that it convert to the regular development model going forwards. I don't even know what we are talking about anymore : a 'CJAN' or 'Jakarta Tools' (aka Rupert :) project? I want to participate in a Jakarta Tools project, as I see a need (personal, communal, and global) for high-quality tools for building server based applications in Java. I know people who will go looking at application servers because they want a good connection pool, and that doesn't make sense to me. Jakarta is rich in general-use tools. We just need to get them out into the light of day, documented, and supported directly, not incidentally as part of larger projects. I know I am relatively new, and I am not criticizing. I just think there is a huge opportunity here. :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
[EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). That's also a sharing problem - the code is too deep inside a project. BTW, blaming the users ( for using the wrong OS for example ) is not working. Changing the code and placing it where it can be found may help. That's what I am advocating - Getting this stuff out front and center. I am not blaming the users. Its our fault if people don't know what the projects are about and have available. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Re: Code Sharing Concepts
"Craig R. McClanahan" wrote: "Geir Magnusson Jr." wrote: [EMAIL PROTECTED] wrote: If someone chooses to duplicate a piece of code, maybe the problem is with the way the code is written and shared. I think in some cases, its bacause people aren't aware that the stuff exists. Go through the Jakarta project sites, and find the number of places that offer a separate, clean FOO tool that supports BAR. (Choose your tool and it's expected functionality). One small proto-model of "shared code" code components already exists within the Jakarta community, and might serve as a starting point for discussions -- the Jakarta Taglibs project, which is focused on creating reuseable JSP custom tag libraries. This is your FOO, and BAR then is clearly defined. To me, this is a FOO that is generic - like 'visual component' or 'bean' - it is a general class of software where the functionaly is a degree of freedom left to the creativity of the developer. So you can say "Here is a collection of FOO, listed by functionality." I think this is a valuable model - clearly the Taglibs projects shows it's a valuable model. But I am not sure that all the projects in 'Rupert' would work well this way. For the 'single-instance' model, it would be harder to say "Here is a collection of JDBC-compliant DB connection pools". How can you distinguish? There certainly is space for both, or if you make FOO generic enough in each case, then the overall project model can consists of a set of libraries, each hosting a subject area : POOLS : (works as library ) - generic object pool - JDBC DB connection pool - ? XML Configuration : (works as library) - this would be a big list ETC: And each library (POOLS, XML Config) could manage the components within in, similar to how a Jakarta project manages its own work. [SNIP] As long as you avoid a rule that there will be only one kind of FOO in the library, that should avoid most of the potential conflict issues. Yes, but we should recognize that if the multiple FOO are something like a DB Connection Pool, the 'rule' would be that the differences in features and uses should be *clearly* enunciated, to the point of making sure the non-Jakarta developer looking for a solution can easily understand the differences, and make a decision. Otherwise, they *will* go elsewhere. Maybe my concern for the non-Jakarta developer is misplaced or misaligned with the intent here, but as I have said before, there seems to be an *enormous* amount of useful code for the Java developer scattered around, and finding a way of clearly describing, presenting and organizing it for general use would do the development community (and ourselves - nothing beats writing software that is actually used) a big favor. In order to make this work, someone(s) needs to step up and organize the basic infrastructure, but after that it can be fairly self-sustaining. (And maybe Sam can extend Gump to see which individual modules are being used in which projects -- having your shared code selected by some other project is a pretty good vote on it's quality, plus an indication of who you should talk to before changing APIs ;-). that's a great idea. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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!! - Sam Ruby The most remarkable thing about this thread is that there appears to be a consistant and correct spelling of 'WAAAHG'. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Velocity : it's not just a good idea. It should be the law. http://jakarta.apache.org/velocity - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mrs. Robinson...
"Pier P. Fumagalli" wrote: I found this nice article on Salon tonight, and I wanted to share it with my closest friends :) http://www.salon.com/tech/col/garf/2001/01/08/bad_java/index.html For sure the guy grew up in a bad way :) Just take a look at his name, is he an hybrid between Homer and Simon Garfunkel? (Well, I can't say my name is better - translated it would sound like "Peter Paul Smoking Chickens" - but his sounds like "Mrs. Robinson's Donuts"...) I'd give him a big phat "californian" what-EVERR :) :) :) He wrote a follow-up because a few people gave him a 'what-EVER'... http://www.salon.com/tech/col/garf/2001/01/18/java_response/index.html geir (And if "californian", wouldn't that be 'what-EV- hey? what happened to the lights? ' ) -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Ted Husted wrote:
Since I'm the lone wolf on this point:
snip
(3.1) mailing list(s)
jakarta-commons-general
jakarta-commons-DBCP (database connection pool)
jakarta-commons-sandbox (unreleased packages)
/snip
insert
(3.1) mailing list(s)
jakarta-commons
/insert
I think that I do agree with both sides : but I think that you are right
in the longer term - it will be clear as it evolves that we will need to
cut down on the noise if sub-sections get active enough. In the shorter
term, the single list will be community-building.
+1
and how about:
7. In general, packages should provide an interface and one or more
implementations of that interface, or implement another interface
already in use.
and:
23. Like all Jakarta subprojects, we adopt the Code Conventions for the
Java Programming Language as published by Sun. In addition, we specify
that indentation is constructed using 4 spaces only -- no tab
characters whatsoever.
I support the notion of standardization, but some of the Sun conventions
are just awful, particularly the bit about ending the method declaration
with a '{'
Futher, I like starting blocks with a { a la
if( foo )
{
block
}
I know it makes code 'big', but I personally find it easy to read, and
then if someone adds something, you don't get stuck with the bug
if(foo)
bar;
going to
if(foo)
woogie;
bar;
if they forget to add the braces, which can be a bear to find,
especially when groggy and tired :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
Gunnar R|nning wrote: "Geir Magnusson Jr." [EMAIL PROTECTED] writes: The thing that started this, about the coding guidelines, was in response to the addition of the Sun coding guidelines (rules...) - I was just indicating my preference. Of course, but it is important to be able to accept and tolerate different [SNIP] Geir - this is not to take it out on you, but I've been pretty annoyed/frustrated with people trying to specify to much. Better keep it simple - I have no problem reading code in different styles and I usually keep to the style of the author if I have to modify some code. Tolerance and respect for cultural richness is what I advocate. Opening braces on the same or next line - it is still code - black or white - you're still a human being. Unless I am a code generator, in which case, well, I'm a code generator. Seriously - I have to admit I do like some regularity to coding style, especially when we have this 'free' environment in Commons where any committer can commit anywhere. However, I was just indicating my dislike for some of the Sun coding standards which seemed to be hinted at as useful for Commons. mine kroner, Isn't that something like US$0.11? Gunnar geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
David Duddleston wrote: Over the several years I have been lurking these forums, the topic of a shared library of common classes has been discussed several times and a few different attempts have been made to realize this goal, but all have either failed or fallen sort. Avalon is probably the closest project to supplying a useful set of library code, yet it lacks strong support from the community and only has a relatively small set of classes. That could be - my problem when I went looking for things is that I surmised that Avalon was some sort of framework, rather than a collection of independent utilities. I got that idea because that is what the avalon site says... Peter and others are aware that this is often the perception. [SNIP] I have to side a little with Peter Donald on this, if you are serious about achieving this goal, then it is better to work with an existing project that is attempting to achieve some of the same goals. I would agree 100%, because of the benefits of community, but it's not clear to me what the Avalon goals are. By starting a new project is just the same as another subproject writing its own utility class even though there is already some code in another project that is closely related. If you feel strong that this needs to be a new project, then create your own informal group and come back a few months later with an established code base. Maybe - but you can see the kind of things people are proposing we go get (like asking if Poolman wants to be contributed) or things that people are proposing be pushed into here, like the 'web connector' subproject, and org.apache.tools.tar and org.apache.tools.mail from Ant (I think). So we seem to be attracting code bases already, may go out and solicit existing ones from outside of Jakarta - if the value we add is to make them easy to find, document them well, and be a community that supports them *for their own sake*, then I think there is significant added value. Just another rant Even after a few years, it still bugs me that license and copyright mark on each piece of Apache code is so darn long. Even a dog knows it only takes a few drops to marks its territory. Try marking a lawyer. They seem to require more than a few drops.. :) One thing I've seen is that people put it at the bottom, so it's out of the way. Is there any legal implication regarding position? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PMC meeting agenda
Peter Donald wrote: ... sucks being the only Aussie ;) I thought there were at least several thousand of you there. You certainly have enough room. I know a few that live in New York if you are lonely. :D geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JCP Survey
"Michael, Colin" wrote: Who, exactly, is doing this survey? Does not appear to be from Sun. Is there a link to this from the Sun website? Found a link to www.kingbrown.com in their page, who claim to do 'intelligent market research, and claims Sun as a client. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-site2
Done and done.
(this was my first site update, so if someone would give it a look-see
to make sure all is well, I would be much obliged...)
geir
Sam Ruby wrote:
Jon Stevens wrote:
now, if i can get some help with the encoding problem,
that would be nice...
===
RCS file: /home/cvs/jakarta-site2/xdocs/site/whoweare.xml,v
retrieving revision 1.25
diff -u -r1.25 whoweare.xml
--- whoweare.xml2001/03/15 06:25:59 1.25
+++ whoweare.xml2001/03/15 09:28:09
@@ -213,10 +214,7 @@
/p
p
-!-- temporary disabled until encoding issues can be figured out
-bCeki G#252;lc#252;/b (ceki at apache.org)
---
-bCeki Gulcu/b (ceki at apache.org)
+b![CDATA[Ceki Guuml;lcuuml;]]/b (ceki at apache.org)
br/
Ceki is the founder of the log4j project. Time permitting, he also does
custom development for clients. See a
===
RCS file:
/home/cvs/jakarta-velocity/src/java/org/apache/velocity/anakia/OutputWrapper.java,v
retrieving revision 1.2
diff -u -r1.2 OutputWrapper.java
--- OutputWrapper.java 2001/03/15 04:02:35 1.2
+++ OutputWrapper.java 2001/03/15 09:29:42
@@ -59,6 +59,7 @@
import org.jdom.Element;
import org.jdom.output.XMLOutputter;
+import org.jdom.CDATA;
/**
* This class extends XMLOutputter in order to provide
@@ -102,4 +103,14 @@
}
return buff.toString();
}
+
+/**
+ * Passthru CDATA content uninterpreted
+ */
+protected void printCDATASection(CDATA cdata, java.io.Writer out,
+ int indentLevel) throws IOException
+{
+out.write(cdata.getText());
+}
+
}
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
Peter Donald wrote: Jon Stevens : For #2: It certainly could start in the Commons. No it couldn't from what I understand. Commons won't allow imports directly from turbine/avalon and to try to do such a complex system generic from start may be a bit of a PITA at this stage. Especially when both turbine/avalon already offer a lot of support. Why wouldn't the import be allowed? That's one of the reasons for commons : to provide a place to collaborate across projects... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
Conor MacNeill wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Geir Magnusson Jr. Sent: Friday, 23 March 2001 3:20 PM To: [EMAIL PROTECTED] Subject: Re: New Subprojects Peter Donald wrote: Jon Stevens : For #2: It certainly could start in the Commons. No it couldn't from what I understand. Commons won't allow imports directly from turbine/avalon and to try to do such a complex system generic from start may be a bit of a PITA at this stage. Especially when both turbine/avalon already offer a lot of support. Why wouldn't the import be allowed? That's one of the reasons for commons : to provide a place to collaborate across projects... I guess it would depend on their level of coupling, wouldn't it. It is the difference between a framework and a collection of common utility classes. When you import framework classes, often it seems to be viral. To use that one class you end up importing quite a few other supporting classes. That is what makes the Commons a difficult project, there is often a natural desire to make it into a framework. The alternative may be a lot of "insulating" interfaces to allow the components to be plugged into a system without the supporting framework. It also functions simply as a place to work - what goes on in the 'sandbox' doesn't have to be an Official Component (tm). geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
Peter Donald wrote: At 11:20 22/3/01 -0500, Geir Magnusson Jr. wrote: Why wouldn't the import be allowed? That's one of the reasons for commons : to provide a place to collaborate across projects... Go back to the original discussion. Essentially all components should not rely on external frameworks but should use the JavaBeans style standards. Any code that makes it into commons is either free of the framework or allowed in with the assumption that it will be refactored to be free of the framework. Ok. Remember the motivation is to provide software components that can be shared across projects. If they are tailored to one specific framework, they won't easily be able to work in another. If you make it more general, then I assume more people can share the software. As a sharing mechanism between projects commons with it's centralized control is bound to fail - but then again you know my opinion on that. Decentralizng control was one of the things that could of made it work combined with cjan. Oh well... What centralized control do you keep seeing here? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
James House wrote: Maybe I'm still unsure of the purpose of "the commons" but, do you really want something as huge as a process automator in there? -- We're talking about something on the scale of a full-blown EJB container here. It's not something somebody would want packaged along with a handy 'Collections' library. That's very true - but one of the motivations of Commons was to be a place for open collaboration, sharing and, while some hate the word, 'experimentation'. It would be a place for multiple people to work, and then as things shape up, you have a better basis for deciding where such a beastie will live as a 'formal' project. You could also try it under the asupices of Avalon, Turbine, Struts too... gier -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Subprojects
Alex Fernndez wrote: Jon Stevens wrote: I can't wait to see what it will be like to configure all these Commons components and how many .xml files I will have to edit or how much configuration code I will have to write to make it work... You're right, of course. If instead of integrating a whole framework we have to configure 100 components so the pool has trace, XML, task scheduling, web-admin and whatever capabilities, it isn't what we need. In fact, if the component configuration cannot be integrated in our global configuration scheme, it will not do. So, in a word, we don't need components that integrate with each other; we need components that need no integration at all. Perhaps we would be better off with a framework; but that's not what we think. My better judgement tells me to dare not suggest how getting a common configuration pattern for the components might be realized, as I am sure it will bring howls of derision and scorn regarding central control and big brother. However, this is a really good point and a discussion we should have in Commons-land. Please come and join if interested. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] J2EEUnit donation to ASF
Jon Stevens wrote: on 3/27/01 9:57 AM, "Vincent Massol" [EMAIL PROTECTED] wrote: Yes. My name is Vincent, although Victor is also a nice name ... :) Ok, I wrote vincent and then say victor in another email and changed it to that...sigh... OK ... sigh If you have ideas, they are welcome ... I like: JTwoEEUnit JToEEUnit JTooEEUnit Those might be to close. There is always the acronym approach... Java Enterprise Unit Test Framework JEUTF I also like creative non-descriptive names: Ducky Well, 'Rupert' is still available... and my favorite of all: UnitTestingSystemForSunOverHypedMarketingBuzzwords How about .NETUnit ? -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] J2EEUnit donation to ASF
Martin Cooper wrote: At 09:57 AM 3/27/01, Vincent Massol wrote: OK ... sigh If you have ideas, they are welcome ... It seems to me the '2' could go, because that's nailing it to a version, and the second 'E' could go because we don't need an Edition. Then we're left with JEUnit for Java Enterprise Unit testing framework. That's not so bad. I like this. It keeps the 'Unit' and if you can get away with JE w/o Sun getting upset... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Velocity 1.0 Released
The Velocity project is pleased to announce the release of Version 1.0 of the Velocity template engine. Velocity is a powerful template engine written in Java and released as open-source software under the Apache Software License. Sun's Dot-Com Builder developer information site just did a "Best Practices" product profile of Velocity. The article is located at http://dcb.sun.com/practices/profiles/velocity.jsp For more information, including the v1.0 release of Velocity, please visit the Velocity home page at http://jakarta.apache.org/velocity/ Velocity is part of the Jakarta Project, a group of open-source software projects of the Apache Software Foundation chartered with providing open-source server solutions based on the Java platform. For more information about Jakarta, please visit http://jakarta.apache.org/ For more information about the Apache Software Foundation, please visit http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Binaries in CVS
Sam Ruby wrote: A final note. At http://jakarta.apache.org/velocity/ymtd/ymtd.html you will find a comparison between Turbine/Velocity and Struts/JSP. I pretty much agree with everything said there. But I'll place my bets on Struts/JSP. Not because of some presumedly massive Sun marketing machine. Not because it it technically better. But because I for one don't like rewriting my applications every few months. The comparison was really about JSP vs. Velocity. What if you could use Struts/Velocity? :-) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaworld Awards
Ceki Gülcü wrote: Greetings, Here are some pretty good news: http://www.javaworld.com/jw-05-2001/jw-0504-finalists.html Regards, Ceki Congratulations to log4j and Tomcat 3.2! If no one has done it yet, I am going to put this up on Jakarta news. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: if and unless attributes for all Tasks
When I ran across it in XSL, two words came to mind : 'scope creep'. I don't know the history of XSL, but that couldn't be what people were thinking in the beginning. geir Jon Stevens wrote: This is such a great discussion, I just had to open it up to a more general group. The Ant group is discussing the fact that putting conditional statements into XML is a terrible idea, yet JSP/Struts is doing exactly that with taglibs. Am I the only one who sees the disconnect here? http://jakarta.apache.org/struts/struts-logic.html -jon -- Forwarded Message From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Tue, 15 May 2001 16:27:25 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: if and unless attributes for all Tasks Build scripting is all ABOUT conditional processing - i.e. if source file A is newer than object file B, compile source file A. This low-level conditional checking is built into Ant (and make) so that you don't have to see it - and that is the primary advantage of build tools over scripting tools - it simplifies the required instruction set. This does not, however, eliminate the need for conditionals at a higher level of abstraction. Also, I have several times had to use the uptodate task paired with the if/unless conditions to achieve checks that are *not* built into Ant - and this is conceptually at the *same* level of abstraction of the .java/.class checks. I think what Jesse was saying (At least, what I so strongly agreed with) is that XML is not a good language for doing if/checks and what not. If you need to do logic, even simple logic, you're better off to write a task in Java and have all of the power that a real procedural/OO language can give you or use different build scripts. Instead, we should keep ANT in a make style of dependencies and make things as simple and approachable as possible. ANT dependencies are hard enough to wade through if you're new to a large build.xml. As you add more and more control structures, ANT becomes decreasingly accessible and then losses what I consider to be a big part of it's value. Jason Henriksen -- End of Forwarded Message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Jakarta Deprecation Policy
Jon Stevens wrote: Well, there haven't been many flame wars around here recently, so let me start one. I seem to be good at that. :-) What I propose is that we take this document (or one similar to it) and migrate it up to the overall Jakarta Project instead of just being a Turbine policy and get all the projects to sign their name on it. http://jakarta.apache.org/turbine/deprecation.html I think it would go a long way towards raising awareness of the need to deprecate things (thanks to Sam starting this with Gump) as well as make the corporate types feel more comfortable with regards to depending on that Open Source Software stuff... Comments? +1 in general, with agreement with others' remarks about it being not appropriate for major releases ( n.x - (n+1).0 ) and not applicable for v 1.0 However I do worry about how this might subtly (or un-subtly) affect the development 'gestalt'. As projects get more mature, acquire a serious user base, etc, doesn't this kind of thing happen as a matter of course? In the few cases that it doesn't, Uncle Gumpy seems help keep us on the straight and narrow. If this is true, would it be just as useful to offer as a set of guidelines? geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Turbine
Tim Vernum wrote: In general, I believe that automated build/test processes are *very* important, an do work. We've got some teams using CruiseControl here, and it is doing well. The reasons I think that gump registers so many failures are: 1) The environment in which gump runs is not identical to the environment the developers run (OS, jdk, jars, etc), and I'm not sure if it is even well defined. Now, given that these are supposed to be cross platform java projects, that shouldn't be an issue, but it has been, and will continue to be. When has it been? If an OS issue is found, Gump did its job. The 'cross HEAD CVS', which is how i think of Gump, does something that developers don't do, but should have done for them - which is early detection of interface-ish problems. There is nothing (other than the sloth of Daedalus) which prevents us from adding any 'test' we want - Gump is running the Velocity testbed, for example, which is more than interface-related, but functional as well. I once thought it important to setup Gump tests that specify a specific version set (i.e. the release versions of all dependencies), but I realize that's pointless. Do the test once, and repeating can add no new information. Unless each developer replicates the Gump environment on his/her workstation, they will not find all problems. However doing so will only fix problems for that environment, so in some ways leaving it slightly undefined is helpful to keep portability. Yes. 2) Developers can't/don't run the tests before checkin. In our situation, if you checkin something that breaks the tests, you're an idiot. I don't think that happens in apache, for a few reasons. The primary one being that most people are doing this in the spare time, and a channeling in patches from numerous sources. Forcing full rebuilds with unit tests would make that channel so small that work would grind to a virtual stand-still. Not sure I buy this - Velocity has a unit test suite that has saved us (me) in countless instances, so I know if a change has altered the gross functional envelope that we have been able to define. 3) Developers can't/don't test other projects. This is particularly relevant to ant, but also to some of the XML and (soon) commons modules. A number of build failures have been due to changes in ant. Ant should continue to be free to change things as needed to make ant better, and that will continue to break projects that rely on specific ant features/bugs. Unless the developers are going to rebuild all the dependant projects everytime they make a change, then this will keep happening. Interesting topic : like any other released package/project/tool with users, does Ant ensure that it is backwards compatible with itself, at least on major version boundaries? (I think it should be...) [SNIP] 5) Attitude. Given the length of time that some projects remain broken, I guess some projects don't particularly care too much. Which is a pity. (Granted some projects believe they've fixed it, and that gump is misbehaving, so you can't blame them for that). I think if it gets repositioned to fill such a role (or maybe it already is, and I'm misinformed) then solving (4) will be useful. Ultimately though, (5) is the kicker. That's a matter of resources for (4) and time and social engineering for (5), I think. With an all volunteer group, I think it has to be worked into the culture. While you could force the issue by making it a part of being a Jakarta project, I don't think we want to do that. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Turbine
Sam Ruby wrote: Geir Magnusson Jr. wrote: There is nothing (other than the sloth of Daedalus) which prevents us from adding any 'test' we want - Gump is running the Velocity testbed, for example, which is more than interface-related, but functional as well. That test suite takes 58 seconds to run. I think we can afford that. In any case, it runs on my machine, not on Daedalus. No - what I meant was adding to the gump cycle time by adding more CVS activity to the mix. I figured that the CVS is the bottleneck - you can always parallelize the gumping once the source is there, although I suspect you won't need to :) That's a matter of resources for (4) and time and social engineering for (5), I think. With an all volunteer group, I think it has to be worked into the culture. While you could force the issue by making it a part of being a Jakarta project, I don't think we want to do that. This is happening. Six months ago several key projects were in perpetual alpha, and there was very little code sharing. And Gump was just a concept. Six months later, look at how things have changed. The mere thought that somebody might not have addressed a problem 48 hours after it was detected is being raised as an issue... Gump and I are happy. It's never clear to me that they are distinct entities ;) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene acceptance in Jakarta
Did you consider that we were out of functional email reach? +1 from me - I haven't used it, but it comes highly recommended from a source I trust (besides you...) geir Jon Stevens wrote: Re: Lucene being added as a Jakarta Project. 5 of 10 (not counting Duncan) of the PMC members voted +1. The rest haven't voted (shame on you). Can I please get the rest of the people to cast a vote? thanks, -jon +1 Daniel F. Savarese [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] Ceki Gülcü [EMAIL PROTECTED] Peter Donald [EMAIL PROTECTED] Jon S. Stevens [EMAIL PROTECTED] No vote: Pierpaolo Fumagalli Ted Husted Geir Magnusson Jr. Craig McClanahan Sam Ruby -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ You have a genius for suggesting things I've come a cropper with! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal to make BSF an ASF project
Pier P. Fumagalli wrote: Sam Ruby at [EMAIL PROTECTED] wrote: Craig R. McClanahan wrote: +1 for BSF as a Jakarta project. Ditto. Doh :) +1 Pier Re me +1 geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ You have a genius for suggesting things I've come a cropper with! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Helma XML-RPC @ Jakarta
Jason van Zyl wrote: Hello, I would like to propose the movement of the Helma XML-RCP package (http://xmlrpc.helma.org/) to Jakarta. The Helma XML-RPC package is the most popular OSS XML-RPC package and Hannes Wallnoefer would like to donate the code to the Jakarta project. There is an active community based around the package but organizing the effort is something that Hannes would like some help with. The Helma XML-RPC package is used extensively in Turbine, will be used extensively by CollabNet, and is used in the Helma project itself so interest will not drop off any time in the near future. There is full documentation for the XML-RPC package, and we are working on a test bed so the code is in good shape and healthy. I am also willing to be the PMC member that oversees the project. We have an initial committers list as follows: Hannes Wallnoefer [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] John Thorhauer [EMAIL PROTECTED] Daniel Rall [EMAIL PROTECTED] Leonard Richardson [EMAIL PROTECTED] Josh Lucas [EMAIL PROTECTED] There are also people on the XML-RPC dev list that are not listed here but who are active. So it is likely that this list will double in size very shortly. Thoughts? Does that belong here in Jakarta or in XML land? Either way, +1 from me, btw. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ You have a genius for suggesting things I've come a cropper with! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Helma XML-RPC @ Jakarta
I believed that xml.apache.org was the appropriate place to try first, and if it can find a happy home there, I still think thats appropriate. However, this is a living community, not just a code base - Hannes and co-conspirators are coming with it. Therefore, I think top level in xml would be nice, but that's only a suggestion - I am not a part of xml.apache community. If they can't be acommodated in a way that is satisfactory to all, +1 for here in Jakarta. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ You have a genius for suggesting things I've come a cropper with! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] $un, M$ and Java
Peter Donald wrote: On Mon, 13 Aug 2001 21:29, Geir Magnusson Jr. wrote: Sam Ruby wrote: Kevin A. Burton wrote: - - No more competition from .NET/C#. (why would anyone want to support an MS proprietary language?) s/MS proprietary language/draft ECMA standard language/. ECMA also has a fast path to ISO. With not one, but two [L]GPL implementations underway (http://www.go-mono.com, http://www.southern-storm.com.au/portable_net.html). Microsoft is even teaming up with Corel to ensure that there is a version for FreeBSD. I am not in any way a Microsoft fan. That said, I appreciate their strategy - if they really make C#/.NET/whatever a genuine standard and don't do the usual embrace and extend [and extinguish] or lock up pieces with patents (that's where my money is...), then it all will come down to tools and services, something they actually do pretty well. I am not familiar enough with it but I was under the impression that it is just the language and an absolute minimum of the runtime that is standardized. It would be the equivelent of stripping 95% out of java class libraries and standardizing that. The rest is still kept closed I thought. Ah. Not sure. I wasn't about to believe that it would be fully open, but was expecting it to be visible but protected somehow. Sam? (He's 'sort of' heavily involved with this :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ Well done is better than well said - New England Proverb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Call for Papers
Jon Stevens wrote: Maybe people can write some proposals about talks that don't center around JSP. Last year was nuts...something like 50+ talks on JSP alone. Ewww. I have an idea for a non-JSP talk... -jon * 2002 JavaOne(sm) Conference Call for Papers Sun Microsystems is seeking proposals for sessions for the JavaOne(sm) Conference, to be held March 25-29, 2002. The Call for Papers process begins August 31, 2001. Deadline for submitting papers is September 30, 2001. Call for Papers contact: [EMAIL PROTECTED] http://java.sun.com/javaone/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ Well done is better than well said - New England Proverb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Making Commons-Cactus a top level projet
On 9/14/01 6:04 AM, Vincent Massol [EMAIL PROTECTED] wrote: - Original Message - From: Vincent Massol [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 4:43 PM Subject: Re: [VOTE] Making Commons-Cactus a top level projet [snip] We need: - a new CVS. Is it possible to not to loose any history by copying the CVS files rather than doing an import ? Actually, it may be a good idea to move to a clean CVS (?). Otherwise, as there will be a package change it will mean a lot of empty directories in the src/ directory. Don't you want to preserve your history? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ If you look up, there are no limits - Japanese Proverb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
On 10/22/01 1:23 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jon Stevens at [EMAIL PROTECTED] wrote: import email.RequireApproval.vm; Wow. When did Velocity files become ok to import? :-) You didn't know? They're adding those to the VM spec, so that you can directly write in Velocity without having the hassle to pass thru Java :) :) Pier (being ready to be flamed by JG! :) From what I understand, Sun likes it so much its going to be part of system services in the next major rev of Solaris. Sort of like how Microsoft 'integrated' IE into their OS. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
On 10/22/01 8:59 AM, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, I now have a proposal for BCEL which can be found here: http://www.apache.org/~jvanzyl/jakarta-bcel +1 I'm +1 with the comment that this does add a little scope creep to Jakarta. I don't mind as much as I hope we acknowledge it. Maybe it's time to reorganize the site and see who salutes or flames :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributing the JSSE
On 10/23/01 5:55 PM, Jason van Zyl [EMAIL PROTECTED] wrote: On 10/23/01 2:38 PM, Jon Stevens [EMAIL PROTECTED] wrote: on 10/23/01 10:40 AM, Jason van Zyl [EMAIL PROTECTED] wrote: I want to distribute the JSSE jars with the Turbine Development Kit but I'm not entirely sure if it's legal. On the JSSE website it says that the binary implementation may be used royalty-free as part of commercial applications, but in the license it says for internal use only? It is not legal. If that is indeed the case does anyone know of any JSSE implementations that can be distributed? Why is it not legal? According to the license posted by jason, there is a supplemental section that reads : SUPPLEMENTAL LICENSE TERMS These supplemental license terms (Supplement) add to or modify the terms of the Binary Code License Agreement (collectively, the Agreement). Capitalized terms not defined in this Supplement shall have the same meanings ascribed to them in the Agreement. These Supplement terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. License to Distribute. Sun grants you a non-exclusive, non-transferable, royalty-free, limited license to (a) use the binary form of the Software for the sole purpose of designing, developing and testing your JavaTM applets and applications intended to run on a compatible Java environment (the Programs), provided that the Programs add significant and primary functionality to the Software, and (b) reproduce and distribute the binary form of the Software through multiple tiers of distribution provided that you: (i) distribute the Software complete and unmodified; (ii) do not distribute additional software intended to supersede any component(s) of the Software; (iii) do not remove or alter any proprietary legends or notices contained in or on the Software; and (iv) only distribute the Software pursuant to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and provides that Sun is a third party beneficiary to such license agreement. If you distribute the Software pursuant to this paragraph, you must include the following statement as part of product documentation (whether hard copy or electronic), as a part of a copyright page or proprietary rights notice page, in an About box or in any other form reasonably designed to make the statement visible to users of the Software: This product includes code licensed from RSA Data Security. The only problem that I see is (iv). Is that it? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site update
On 10/27/01 4:27 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, When doing site updates, please don't forget to update before starting editing. For example, Berin reverted many changes to the news and binary pages. Shouldn't the cvs commit caught that on the merge? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Anyone wants to...
On 10/27/01 7:33 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Take up some moderation works? I'm fed with all mailing lists :) Pier Yep - send stuff my way. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] MS makes a better PetShop...
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... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Microsoft Sets Tolls for .Net Developers
On 10/31/01 1:57 PM, James Strachan [EMAIL PROTECTED] wrote: Any plans to do an open source Java implementation of it? :) Then we could do an open alternative to My Services. 'Open Services' anyone? :) And maybe we could also hijack a top level domain, and put it as part of our new .COM project... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] MS makes a better PetShop...
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. geir I don't really see what M$ did as being FUD. What they are doing is showing the hypocrisy of Sun's marketing engine and the technologies that Sun is pushing on people to use. W a k e u p p e o p l e -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cross site scripting
On 11/21/01 6:59 AM, Danny Angus [EMAIL PROTECTED] wrote: Hence my own conviction that the only safe option is no HTML in submissions. However I'd rather escape it on the way in than the way out to reduce load. That's something I intuitively agree with, and don't understand the contrary point of accepting everything in and processing everything out. I would guess the amount in would be significantly less than the amount out, and you get to leverage the context in which you are accepting input. (I.e. There should be no HTML on the input of a simple order form, for example...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: BCEL @ apache
On 10/7/01 8:47 PM, Conor MacNeill [EMAIL PROTECTED] wrote: From: Jason van Zyl [mailto:[EMAIL PROTECTED]] I would volunteer to help the move if it was decided to move it to jakarta. I can help out here too, if it goes ahead. Are you back? I still can't solve that ant classloader problem. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BCEL @ apache
On 10/7/01 8:47 PM, Conor MacNeill [EMAIL PROTECTED] wrote: From: Jason van Zyl [mailto:[EMAIL PROTECTED]] I would volunteer to help the move if it was decided to move it to jakarta. I can help out here too, if it goes ahead. Conor A thousand pardons for posting the last one to general@. It's 5:50 am, coffee just finished brewing, and I forgot this was a general@ thread with replied to list. Sorry again, all. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commentary by Linus Torvalds
On 12/2/01 10:40 PM, Neville Burnell [EMAIL PROTECTED] wrote: anyone remember Lotus Developments and WordPerfect Corporation ... they had billions in the bank too And before last month, Enron seemed to be doing ok :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, 3 December 2001 11:46 AM To: Jakarta General List Subject: Re: commentary by Linus Torvalds Jon Stevens [EMAIL PROTECTED] writes: http://groups.google.com/groups?q=g:thl2361245693dhl=enselm=linux.ker nel. Pine.LNX.4.33.0111301643170.1224-10%40penguin.transmeta.com I wonder why he says Sun is doomed. I always wonder how people can say any of these companies are doomed. They have billions in the bank. It would take years and years and years of stupidity to drain this money down to 0. SUN, Microsoft, Oracle. They are not going anywhere. They will just change their strategy. ... then again you should never underestimate the power of stupidity :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comment for Apache.org
On 12/10/01 9:08 AM, Ted Husted [EMAIL PROTECTED] wrote: It is admittedly not a perfect universe, but I think the Jakarta Universe would be poorer without Jon Stevens in our midst. Some things are a package deal, and Jon seems to be one of them. I sometimes wonder if he is not employing reverse psychology on the rest of it. For example, it was Jon's flames that gave birth to the Commons (like a Phoenix rising from the ashes). He said that saying some of us weren't playing nice with others -- so we set up a playpen. Weeell Not exactly sure about that... :) lloyd wrote: Wow. It would be really great if you wrote an email that made some logical Having lurked on this list for awhile, I'd say it would be great if you could get through one e-mail exchange without being an asshole. -- 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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comment for Apache.org
On 12/11/01 10:32 AM, Tiseo, Paul [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 4:45 PM When you come close to 1/5th the amount of work he has done for Apache then you can judge. So, if I understand Apache's so-called meritocracy system, the more you do for a project, the more unprofessional and ego-driven behavior you are allowed? So, If Jon doubles his workload, will he then be allowed to murder dissenting listmemebers instead of simply insulting them? :) That sort of thing would come in handy from time to time... Hmm -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Comment for Apache.org
On 12/11/01 5:12 PM, GOMEZ Henri [EMAIL PROTECTED] wrote: In my opinion, if you haven't contributed anything, then you are just leeching off the hard work of the many individuals behind the Jakarta project Everybody could disagree with someone but the generally accepted rule is to stay correct with the person. There is many forums on the web to do run such dialogs. Better, I suggest people who want to flam Jon, to do it directly and leave this list a bit more quiet. The list is named [EMAIL PROTECTED] and not [EMAIL PROTECTED] How about we set up that list, and use PayPal to collect donations for some worthy cause (chosen by jon, of course) for people that want to publicly flame jon... He's busy these days, so we can all take turns proxying for him, with the caveat that you have to work hard on Jakarta stuff like he does to be a proxy. Anyone with $$ can flame, of course. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard Change Log and ToDo
We use XML format via Anakia in velocity-land and don't have any problems... I don't really mind. On 12/12/01 5:14 PM, Kevin A. Burton - burtonator [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Spencer [EMAIL PROTECTED] writes: Is their a standard or common Change Log and To Do format for Jakarta projects? I would like to add a change log to the Jetspeed project. No. I have seen a lot of people use XML changelogs. This is WAY overkill IMO. Just use text an a GNU style format. Version x.x - --- * changed foo so that it is now bar It appears the Cocoon project uses Stylebook. Jakarta projects use Anakia, but I have not found any macros in Jakarta-site2 that reference a Change Log or To Do list. I predict that they will become sick of working with an XML format :) Kevin -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard Change Log and ToDo
On 12/12/01 6:19 PM, Kevin A. Burton - burtonator [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir Magnusson Jr. [EMAIL PROTECTED] writes: We use XML format via Anakia in velocity-land and don't have any problems... I don't really mind. snip Enlighten me... what are the benefits of an XML based changelog... besides the ability to XSLT it into html (I don't think this is necessary). In our case, the changelog is documentation, so it goes with the rest, which is in XML. Don't invert the causality - we didn't decide we needed an XML changelog, we needed a changelog for a project that has its docs in XML, so XML it was... My point was that its not painful at all, which I think was your contention. geir - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ Technology is the catalyst for Utopia. -- Me -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8F+UPAwM6xb2dfE0RAoxfAJ9c5Ooeq9XYlF5R+piZ1U/gNFCifwCgy+14 cv9DapSlYOiC0ETC8hTSufo= =c5DV -END PGP SIGNATURE- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Standard Change Log and ToDo
On 12/14/01 7:28 AM, Ted Husted [EMAIL PROTECTED] wrote: We have a rudimentary XML format for a TODO list at Struts, but it needs work. Here's a sample task name=Action info pUnit tests for the codeorg.apache.struts.action/code package./p /info assigned a href=mailto:[EMAIL PROTECTED];Rob Leland/a /assigned /task Right now, we put release notes into the documentation, which acts as a Change Log. That's been a real pain though, and I'm not sure if it's effective. What would be handy if we had compatible TODO and Changelog XML formats, so when something was done, we could update the TODO and then paste it into to the Changelog. Or one XML doc containing the todo info, and then generate a TODO doc and Changelog doc from it based on a status attrib or something... #set($todolist = $node.selectNodes( todo[@status='todo']) ) Or some such. ( Give a guy some basic Xpath knowledge...) We don't need no steenkeeng pasting... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta source code documentation
On 12/14/01 8:13 AM, Walentiny Carlo [EMAIL PROTECTED] wrote: All the developer support tools that apache uses are ones that we can control, modify and adapt to our needs. Like javadoc? :) Juliet looks to be a commercial tool and doesn't really satisfy our needs. Thanks anyway. A shame (Java cross referencing not needed :(). Juliet is commercial, but there will be a free version. Thanks for the reply, carlo Actually, isn't that one of the goals of Alexandria? Maybe wth your expertise you might want to help out there? :) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Coding style addition
On 12/15/01 7:53 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On 15 Dec 2001, Kevin A. Burton - burtonator wrote: Perhaps. It might be a good idea to have a default recommendation or a global standard. ... anyway... The most entertaining flamewars I've ever seen are atempts to gain consensus on whether to use tabs or not, and then how many characters an indent is :-). No, and 4 :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Newsletter
On 12/27/01 7:21 PM, Rob Oxspring [EMAIL PROTECTED] wrote: -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 8:51 PM To: [EMAIL PROTECTED] Subject: Re: Jakarta Newsletter Hi Rob, It is indeed a great idea. However, the two editors given credit at the bottom of the url you posted are Sun employee's who get paid to do the job so they don't really count as 'volunteers'. The example given was just through a google search on newsletter site:netbeans.org and not much thought was given to the contents (although the fact that it mentions Ant is nice). The point of this is that I really hadn't noticed that te editors were sun employees and I certainly got the impression that more recent editors have been volunteers in a truer sense - perhaps I have been nieve :( . In the mean time I'll look into the RSS agregator approach and Reptile (will investigate in the morning). Otherwise; point taken - doing is a damn site better than talking - I guess I may take this over to ant-dev (ie where I may be able to do a half decent job) and try it on a smaller scale to see how well it goes down to begin with and expand later... Don't give up too easily :) I'll help if you want. We can co-opt others by simply asking them to write a short note about what's going on in the various projects. Everyone likes to write about themselves, and we can just glom the stuff together, wordsmith here and there, and then we have a nice little newsletter that tells what's going on where So if you are game for an approach like this, I'll help, and we can get started immediately... Geir The Jakarta project has plenty of great minds and thus great ideas. What we are lacking is great volunteers. Everyone is too busy bitching about what an asshole I am. So, my suggestion is that if you would like to see this done, you start working on it yourself...not worrying about how bad an editor you are...and just post *something*. That will encourage others to help you edit and create it (it is hard to complain about something without helping out). Discussing how things should be done won't get you anywhere. This is the same tactic that I used when I created Anakia [1] which is now used to create most of the Jakarta websites as well as www.apache.org and httpd.apache.org. It isn't the most perfect tool [2], but it does the job well, people adopted it quickly and the bitching about Styleweb (the previous tool) stopped. thanks! -jon -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Newsletter
On 12/27/01 7:51 PM, Rob Oxspring [EMAIL PROTECTED] wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 12:25 AM To: Jakarta General List Subject: Re: Jakarta Newsletter Don't give up too easily :) I'll help if you want. We can co-opt others by simply asking them to write a short note about what's going on in the various projects. Everyone likes to write about themselves, and we can just glom the stuff together, wordsmith here and there, and then we have a nice little newsletter that tells what's going on where This sounds like a sensible starting point to me - giving a flavour of what is going on is all I'm really after. So if you are game for an approach like this, I'll help, and we can get started immediately... Sounds good to me, I'm fairly sure I could come up with something appropriate for ant-dev and commons-dev but anything on any other list would be appreciated, and I guess an open letter to the other mailing lists might get a few projects to write about themselves. How often should such a newsletter go out though? every week seems a bit of a commitment (yeah I know I'm lazy) maybe monthly would be more approptiate... either way it seems that not too much has been going on over xmas so I guess that mid to end of January might be a good target for issue 1. Anyway, I think i'll get some sleep before getting too carried away... Rob This is good. I think monthly would be great to start. You write up ant and commons, I'll do Velocity and I'll solicit something from the other groups. If there is nothing to report, then there is nothing to report. No biggie. We'll see how the first one goes, and tweak as we go along. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Newsletter
On 12/28/01 7:40 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: Rob Oxspring wrote: I realise that I'm probably making a rod for my own back suggesting this and as such am happy to help in the setting up of the letter but by profession I'm a software engineer not a journalist so would want to get others interested from an early stage... Any thoughts? One way to gather info for the newsletter would be to subscribe an email account to all of the different jakarta project announce lists. Include all of those in the newsletter. The problem there is that you have to pay attention to it and grok all that is going on. :) Also, each group might have something they want to emphasize or advertise... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 12:57 PM, Vincent Massol [EMAIL PROTECTED] wrote: What would be nice would be to have a JJAR/CJAN project coupled with GUMP. This application would have both an Ant task (for developers) to retrieve versions of dependent jars (latest or specified version or date) and a GUI/Applet in the download area so that end user could use it to download dependent jars. What is needed is : 1/ a repository for the jars where GUMP would copy nightly builds and where releases would be put 2/ dependency information (what Jason is building or what the Commons JJAR project has) so that dependent jars can be easily downloaded I think it might be a good idea for JJAR/CJAN to be a subproject of Alexandria. I disagree. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:general- [EMAIL PROTECTED] For additional commands, e-mail: mailto:general- [EMAIL PROTECTED] -- 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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:33 PM, Ted Husted [EMAIL PROTECTED] wrote: Vincent Massol wrote: I'm not sure what you mean. I've had a look and the dependent jars are _not_ put with the gump build (or the release build). I mean that if we all start offering our JARs as a separate download, like Lucene and some others are doing, then people who need these JARs can get them without downloading the entire distribution. Once that happens, someone could build an automated process on top of that. Or, even without an automated process, you can just provide a hyperlink to the download direcory and let people choose whether they want the JAR or the distribution. Right now, most often, you have to download a 3mb archive just to get a 150kb JAR. I'm just thinking of doing a page about How to make a Jakarta release, and thought we might suggest this as a convention. If we start suggesting this now, then by the time we get through the next release cycle, we would all have JARs out where an automated process can get at them. (Or where they can at least be quickly downloaded the old-fasioned way.) Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:43 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I agree that it would be nice if the GUMP results were put somewhere publicly accessible (they may be but I have no idea where). However, the second step is to automatically fetch the correct dependent jars (and possibly in a validated working state, proved by unit testing of each project). You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I believe that the operative words were validated working state, proved by unit testing of each project. That still doesn't mean anything other than the CVS-du-jour is self-consistent with it's own unit tests, and says nothing about behavior expected by something dependent upon it. To pick a random example... the http://jakarta.apache.org/gump/ is produced by anakia . Which version of anakia? The one built by gump. How am I confident that it is going to work? For starters, there is the unit tests of velocity itself. Then there are other projects which use velocity that build and unit test successfully. That's fine. That still is no guarantee that the functionality can be depended upon. I mean, what gump really tells you is that the API contracts of a project that are used by dependent projects are being preserved (because you can build using the gump-produced jars), but there are no functional contracts that you can dependably test. Further, you don't have a provably complete API contract test because you depend on other projects, which I bet just use a subset, to tell you if something changed. (Food for thought for Gump moving forward, I guess...) So it wouldn't be right to base JJAR fetches of those jars - except when you specify the non-released latest. (JJAR lets you choose which version of a jar you want...) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 2:54 PM, Ted Husted [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Putting aside *all* the stuff we are talking about for a moement, and looking at the simple notion of just having release jars available w/o docs, source, etc I don't think this is a bad idea :) However Any license issues? Wouldn't we want to package the jar w/ a license ? This simple notion -- and my putting together a Jakarta release HOWTO -- is why I opened this particular thread. The license issue is well taken. I think it would be a good practice for us to include a license in all of our JARs. Even when we don't distribute them seperately ourselves, they are intended to be distributed seperately by our licensees. Point noted. It was more of a question than a point :) I was painting a bathroom (sort of like a bike shed, but my wife dictated the color :) and started wondering about binary distribution issues... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 3:08 PM, Vincent Massol [EMAIL PROTECTED] wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: 01 January 2002 19:26 To: Jakarta General List Subject: Re: Just the JARs You don't want to use the results of Gump for JJAR. Gump isn't bulding releases - it's building CVS-tree-du-jour... There is no reason to believe anything built by Gump works. I hope I'm just confused on what you are advocating. For me, GUMP is doing much more than building the CVS-tree-du-jour, whatever this means. It is building releases every day of all projects and produces project outputs. But is that what it does? I don't think so. As I understand it, it takes the CVS HEAD from each project and builds - the purpose being to be an early warning system to detect when API's change through alteration of interfaces or classes. CVS HEAD is generally not considered the current release of a given project, but the ongoing development efforts of the project. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 6:04 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: My rationale was that the goal of GUMP as I understand it now, is to ensure that all projects play well with each other in term of compatibility. It seems natural to extend it so that it can also be asked to retrieve all dependent jars for a given project. Not to me. Gump to me is an early warning tool to ensure API stability across dependent projects, and must, by definition, always work on the current bleeding edge of all projects. It must do this because once you test a set of released versions, nothing changes :) So gump doesn't even have the dependent jars for the released versions - it uses more bleeding edge jars it makes itself to satisfy the dependencies. Gump can and does use jars checked into cvs: http://jakarta.apache.org/builds/gump/latest/cvsjars.html Ok - these seem to be jars you can't or don¹t want to build yourself? Gump can and does use jars installed on the machine: http://jakarta.apache.org/builds/gump/latest/packages.html Which appear to be things you can't build either. I don't understand what you are trying to say here. Many of the nightly builds for various subprojects are published based on what gump produces in the manner desired by the communities for these subprojects. Many of these include in bundled form the jars referenced by the build. But a nightly build isn't a release, right? Wasn't this discussion motivated by Ted looking into getting projects to offer release build jars alone w/o the whole source/docs distro to make for convenient downlaod? For more information on what the goal of Gump is (or more precisely, why it was written), please see http://jakarta.apache.org/gump/why.html That's good. Here's your summary : * It is easier to get a patch accepted against the most current version of a project than some previous baseline. * It is much more effective to express your opinion on a change that will affect you before that change is released than afterwards. So since this is indeed the goal of gump ( actually, I think they are reasons rather than a goal...) then I think that my understanding relative to this discussion is correct, isn't it? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 7:12 PM, Ted Husted [EMAIL PROTECTED] wrote: AFAIK, all the Jakarta sub-projects try to ensure (but cannot guarantee) that the nightly builds remain usuable. The idea being you build and test it on your own machine before committing it to the CVS. Of course, since we are human and our tests are imperfect, the nigthly builds sometimes break. But I believe that is the exception rather than the rule, especially for products that already have a release under their belt. I believe we all hope and expect that a good number of people will be putting the nightly builds to use, so we know if what we are developing is working for everyone else. Error isn't the only issue - I think that the projects have the right to do whatever they want with their CVS HEAD. Gump tells them that they are straying from previous API commitments if that's the case, or functionality changes or whatever... The nightly (for many, anyway) is just a convenience for those that are unable to get the CVS tree (because of corporate firewall policy) or don't want to (for whatever reason). My only point is that some products are developing against another product's nightly build, and to build product A you need the JAR from product B's nightly build. Yep - that's a good thing - I am long overdue for committing my JJAR changes, and would be happy to add CVS HEAD as a version choice when available, to be supplied by gump. That's a great thing. However, I will continue the riff that released versions are important and different. So, in addition of providing JARs alongside the formal releases, I would say it's a good idea to provide nightly JARs alongside the nightly builds, so long as it is not difficult to make this part of the automatic process. Yep - it shouldn't be hard with JJAR if Sam puts things in the same place all the time - after all, it's always going to be the same version... -Ted. Vincent Massol wrote: I would say it depends on the project and the meaning you give to the word release. For the Cactus project, a nightly build produces exactly the same files as a release and can be used with a great deal of confidence. The only difference with a release is that a release has a goal, i.e. we have voluntarily decided that when such and such features are put in, then it would warrant a release. I like to use GUMP for 2 purposes : * Early detection of contentions with dependent projects, * Automated builds/integration, leading to a daily release (in the agile way). Users are encouraged to use the nightly builds and not wait for releases. It may be different for other projects though but I tend to like this philosophy ... :-) [snip] -Vincent -- 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] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Just the JARs
On 1/1/02 8:43 PM, Sam Ruby [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: However, I will continue the riff that released versions are important and different. Just curious, why does the December 9th release of jakarta-velocity contain a milestone version of commons-collections.jar dated May 11th, when there was a release of commons-collections dated July 14? Because I made a mistake in not updating the collections jar for that release. Thanks for pointing that out. It will be corrected. I'll leave it to others to decide whether this is important, or merely different. I'll be the first to say that it's important to me (as I can't speak for others), and will be corrected ASAP. Meanwhile, if there are any byproducts of the things I build from public cvs that other find useful, I will endeavor to support their requests. Why does it appear that it is not wanted? I'm confused... I was just pointing out that keeping the distinction between 'released' and 'gump' is important. Both are useful, and in Vincent's case, they seem to be equivalent, but not in all cases here in Jakarta. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
On 1/2/02 7:47 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Please, keep me copied since I'm not currently subscribed to general@jakarta Why not ? :) Andrew C. Oliver wrote: I don't see any convincing reason to bring POI to Jakarta, unless I see that you have a Jakarta PMC member champion your cause. Stefano's recommendation to you isn't enough, he or someone else needs to be a committer and interested in working and overseeing your project. I do. I see. Thank you, for taking the time to consider the prospect and provide feedback. Did you read: http://jakarta.apache.org/site/newproject.html -jon Yes I did. The guidelines lay out how to propose/approve a project, they do not seem to preclude proposing that members/commiters look at the project, comment and consider a possibly supporting a proposal. We initially talked about moving this code to xml.apache because I think it would give us a great technical advantage, expecially for migrating all the existing legacy data encoded in Office formats to the web. Having the ability to edit XML content directly from M$ Office is something that many of our users would *scream* to be able to do. At the same time, I suggested Andrew to talk about it here instead of xml.apache.org because importing/exporting Office formats back and forward from XML is only one of the possible uses of such a technology (indexing office formats using Lucene is another darn good example of use that currently requires big bucks commercial software!) So why not to XML.apache? My apologies if I've gone about that the wrong way. What would you suggest is the more appropriate way to do so? Interpreting Jon's words with the provided context as I know him, he is afraid of you guys lacking the necessary community management skills that are required in all Apache projects in order to keep the process going and probably didn't see the importance of such a codebase under the jakarta mission. Whether or not this codebase is big/strong/good/sane/future-proof enough to be a full jakarta subproject, I don't know, up to you to decide, but we have: 1) a working codebase licensed under an ASF-compatible license and willing to be donated to the ASF along with copyright and all that. 2) another Apache community (Cocoon's) *very* excited about integrating this technology 3) two very active developers (the sourceforge logs tell us about it) 4) a sponsoring ASF member (myself) willing to take care about helping bootstrapping the community. Reading the current guidelines, community-wise, I see no obstacles in the creation of such a subproject. Technically speaking, since POI is more or less a codec library (not useful by itself), it could probably be better placed under jakarta-commons. In that case, even less community requirements would be needed, even if I would still like to appear as a sponsoring member for that codebase. Sorry if this wasn't clear from the start. Comments? Why is it appropriate for Jakarta? That's the missing piece for me. You said that the Cocoon community is excited about it, it could be important for data conversion in XML land... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
On 1/3/02 9:02 AM, Gerhard Froehlich [EMAIL PROTECTED] wrote: hi, following idea for the jakarta startpage: how about adding a short description of each jakarta subproject on the startpage. something like that: TEXT TEXT TEXT TEXT NAV Lucene: NAV A java based text search enginge. NAV ORO: A set off... because now you have to click in every subproject to find out what they are doing. with this proposal it would be much easier to find the correct subproject Good idea. We were going to do that at one point. Maybe we'll ask each newsletter contributor to make up a *one* sentence blurb and do it that way. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
On 1/3/02 8:21 AM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Comments? Why is it appropriate for Jakarta? That's the missing piece for me. You said that the Cocoon community is excited about it, it could be important for data conversion in XML land... The missing piece might be that this library is general enough to be useful for other non necessarely XML-related subprojects. Sure, but the flip side of that is it's really more of a client-ish tool, as from what I gather it's focus is desktop-software documents (MSFT). Important, and rather cool that someone did it, but not strictly serverside. Of course, Jakarta isn't strictly server-side either. geir Stafano - can you subscribe please ? :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On 1/4/02 3:48 AM, Endre Stølsvik [EMAIL PROTECTED] wrote:
On Thu, 3 Jan 2002, Jon Scott Stevens wrote:
| It is amazing to me...with all the discussion about coding styles and
| following them, we still have people committing code that doesn't follow
| what rules we do have...
|
| on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
|
| Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging
| SimpleLog.java
|
| +if(_showtime) {
|
| http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
|
| Variable names should not start with underscore _ or dollar sign $
| characters, even though both are allowed.
The _instanceVariable and also the __staticVariable idea makes real good
sense to me nowadays. Do you have any arguments against it? (btw; this is
a genuine question!)..
I used to do that all the time in C++ developent, although I put it at the
end
membervar_
It really helps, I think.
And while talking about code conventions; people writing like this:
if (something)
{
}
should be shot right there on the spot, in the act of typing it.
The ONLY way to write blocks is like this:
if (something) {
}
;)
You left out my 'favorite'
if ( something ) { }
:)
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Now what do we do?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
We will be judged not by the monuments we build, but by the monuments we
destroy - Ada Louise Huxtable
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:23 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: At 06:46 04.01.2002 -0500, you wrote: On 1/4/02 6:04 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: Jakarta does not have a benevolent dictator where the puck stops. Recognizing this fact, we either: [SNIP] 3) Keeps things as they are and hope for the best. For those of us (like me) that don¹t get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? Deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is *not* a threat to the ongoing health of Jakarta. It is just an example, albeit a symbolic one. Whew ;) The threat is to Jakarta's *nature* and it comes from our indecisiveness. Real problems I see is 1) lack of focus, I too worry about this. A lot. I don't know what to do about it yet. 2) duplication between projects, Too many damn loggers - thank goodness sun is providing us with on via JSR-47. I am sure that the Code Conventions will be followed to the letter too. (You know I'm kidding - I'm a huge log4j fan, but that one was *just* too easy...) Seriously, I don't know if that is a problem, as I think it drives development. We have two web frameworks, Turbine and Struts, and they are different in current implementation, and as far as I understand it, different in evolutionary roadmap. I think this is good and healthy. We have regexp and ORO. I always use ORO for the Perl stuff. No other comments. We have repetition in commons/commons-sandbox, which I think is great. Those are the top level ones. It's clear that there is repetition within projects (the database connection pools being my canonical example) but that too seems to be evidence of exploring the solution space rather than pure wheel re-invention (although there is some of that...) I think (and only 'I thin') the only thing we can do about this, as you can't mandate what project communities decide to work on, is to ensure that the top level projects remain clear in scope, and encourage cross-project cooperation and sharing, which I think the Commons was intended in part to do. 3) lack of common procedures for doing things. Mixed feelings, as this tends to be personal taste, and leads to operational totalitarianism which I think stifles innovation. There is something to be said for common build procedures, but with ant and a little documentation, it generally isn't a big deal I've found. Are these perceived as problems by others or is it just my imagination? -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:56 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
All excellent points. I don't have any good answers, just more
questions.
Yes, by imposing strict code conventions there is a real danger of
acting like a PHB. Yes, code conventions infringe on artistic freedom
and might even curtail creativity.
The debate about code conventions is just an excuse to ask the
following question, and it is a question:
Do we want to instate rules for the good of the larger community?
I think yes, but the prepositional phrase for the good of the larger
community is going to be the trouble spot... Historically always has :)
We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently?
Because they really can't act *totally* independently, additional projects
can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
pressure (as well mechanical things like Gump) that enforce some
consistency, and lots of cross pollenation. I mean, Jon is everywhere ;)
From my personal experience, I do think of it as one big community but
different 'departments'. I talk to people from many of the subprojects when
I need something or have a question, and I certainly feel welcome and like
it's one big group.
Another thought I have on this is that we are sort of like sourdough bread
made with a starter :) We add new projects, but it's (usually) initiated,
championed and/or participated in by someone steeped in the Apache/Jakarta
'gestalt', so the traditions and practices continue.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?
(I thought you were going to the scene : Lisa, get away from that Jazz
man! )
Well, that's the difference between the teacher having to do something about
it, and Principal Skinner listening in over the intercom and getting Lisa to
leave Within the community, the community is the teacher, and can
legislate itself (modulo Principal Skinner, of course...)
Questions, questions...
:)
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Now what do we do?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
On 1/4/02 12:39 PM, Sam Ruby [EMAIL PROTECTED] wrote: Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? Funny. I've been waiting for it to become a top level project (or at least an Alexandrai project :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: On 1/5/02 7:28 PM, Ted Husted [EMAIL PROTECTED] wrote: I am not trying to be combative - I have watched this thread (and participated) with growing discomfort. I have to say that I think that bringing XML and Jakarta together might destroy the thing we are supposedly trying to 'save' (again, I don't get the problem...), namely the community that each group has. Larger isn't always better. I kinda agree with you on that. Ted didn't write that. I did. I also think we are more than ready for a POI vote, if someone were to post an actual proposal, including the list of committers. In that proposal, can it be argued why it belongs here? I have tried to sit on the fence, and I am glad Stefano will step up to champion the project, but I also think that if he scope of Jakarta is confusing now, adding a vendor-specific desktop document API (granted, with server-side uses) will add to it. There was recent talk for other clearly client projects to be added, with the same apparent quality of code and health of community - why not bundle the two as a seed for a new Apache client-focused project to be a peer to jakarta and XML and ...? If you have used any of the pure Java IDE's lately, it's clear that Java has indeed matured enough for use on the desktop, and initiatives on other client-side devices such as phones, PDA's, etc make for a very rich opportunity for Apache. Further, meta-API initiatives like Liberty which span both server and client (of all types) are clearly in Apache's interest, so I believe that a client-focused Apache project is appropriate for that reason as well. I also wrote that, not Ted. Maybe its not yet time for a vote. Let me state this again and make it very clear. POI has many users and many uses. No one I know of is using POI on the client. Maybe you have some marketing problems? :) POI is as client-side as Tomcat is. Why do you say that? It is used on the server side, and that's fantastic, but in my opinion (note that I recognize I am a complete outsider to your project who would be defined as a user) it seems client side. If I had a need for something like this (and I bet I will at some point), and I had the choice to look at either a) jakarta, the apache java server-side focused project or b) floccinoccinihilipilificator*, the apache java client-side project I would choose b), as I think of word and excel as a client-side thingy. No matter that my use is server-side... (Tomcat is used by Netbeans a pure Java-IDE on the client!). HTML is for use on the client right? Yep. But its a markup definition, not an API implementation. So is a library that outputs in HTML is clientside or serverside? Serverside generally, as the canonical model of HTML use is the web, with a clear delineation of server and client. However, it indeed has clientside uses - take for example any help system that outputs HTML within a monolithic desktop application. Conversely, I would argue that Excel is a totally client-side technology, and therefore a library that works with XLS files is clientside generally as the canonical model of Excel is on the desktop. However, it indeed has serverside uses Cocoon publishes documents that are generally read on the client right? Yes, but it's more than an API, right? (I don't know much about cocoon...) From what I read, POI is an API that accesses data in XLS files... Theres a huge difference. And Cocoon isn't part of Jakarta, is it? :) I don't necessarily think that xml.apache.org is the right place either, although I am not a member of that community in any way shape or form, so that opinion is worth the bits through which it was transmitted. I think that a client project peer to jakarta is still the right place, at least worth discussing, as we have the interesting temporal convergence of the proposal of multiple client side projects when java on the client side is becoming a much more interesting space to work. Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html I will. POI::HSSF reads or generates XLS files and is nearly always used on the server . OF all POI's users not one person is using it on the client. Please check out http://poi.sourceforge.net. The page describes its usage I will. Note I spent years supporting Excel 'stuff' in the financial industry as part of a project I led, and every user I knew was client-side. You may just be ahead of your time :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html No comment, as it's an agreeable followup to the above. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On 1/5/02 11:22 PM, Steve Downey [EMAIL PROTECTED] wrote: In what way does it make it acceptable for them to write poor code? For example, the JSP spec reserves _jsp, jsp, _jspx and jspx for identifiers used in the classes generated by the page compiler. What other way do you propose to guarantee that the compiler won't generate names that conflict with ones I declare in a page? As a SWAG, I would think you could parse out the ones you declare, keep a list, and ensure you don't generate anything that conflicts? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Cultural homogeneity
I was leafing through my copy of A Pattern Language by Alexander, Ishikawa and Silverstein, which is really about architecture of human habitat (buildings and environs), and ran across some interesting assertions about society and groups. I haven't read the book end to end, as I just pick it up and read bits and pieces, but I am generally struck by the validity of the basic insights expressed. I thought I would share, as my thinking about removing community containers here in Jakarta, XML et al resonates well this. There is nothing which says the following is any more valid than any other point of view expressed here, so this shouldn't be read as an appeal to some kind of 'authority' (like we *never* do that here...) - just interesting as it comes from another intellectual discipline studying the exact problems we are trying to grapple with. The summary for me is that I think that the Apache sub communities are valuable, and should be kept. The homogeneous and undifferentiated character of modern cities kills all varieties of life styles and arrests the growth of individual character. (p43) Kind of general as the assertion, the text then talks about three kinds of structure, heterogeneous (bland and conformist), ghetto (organized by economic or physical characteristics, traps and isolates groups), and mosaic of subcultures, the latter being the preference, with the conclusion : Do everything possible to enrich the cultures and subcultures of the city, by breaking the city, as far as possible, into a vast mosaic of small and different subcultures, each with it's own spatial territory, and each with the power to create it's own distinct life style. Make sure that the subcultures are small enough so that each person has access to the full variety of life styles in the subcultures near his own. I think the notion of power to create it's own distinct lifestyle is the important aspect that applies to the issue of disbanding the community boundaries distinguishing XML and Jakarta. Individuals have no effective voice in any community of more than 5,000 - 10,000 persons (p 71) While I don't think that the quantitative values are important, I think the fundamental idea is sound - in order for individual voices to be heard, the group has to be small enough. The conclusion : Decentralize city governments in a way that gives local control to communities [...]. As nearly as possible, use natural geographic and historical boundaries to mark those communities. Give each community the power to initiate, decide and execute the affairs that concern it closely. I think I don't need to explain how this applies to us :) There's more, but I'm beat. Happy weekend. :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 3:52 AM, Peter Donald [EMAIL PROTECTED] wrote: On Sun, 6 Jan 2002 16:10, Geir Magnusson Jr. wrote: I was leafing through my copy of A Pattern Language by Alexander, Ishikawa and Silverstein, which is really about architecture of human habitat (buildings and environs), and ran across some interesting assertions about society and groups. good book. The summary for me is that I think that the Apache sub communities are valuable, and should be kept. ok. I guess thats one reading of it but if anything the snippets you provided seem to me to encourage merging of XML and jakarta if anything ;) Effectively XML/Jakarta would become a single city with a mosaic of subcultures. Already we have different sub-cultures which are effectively defined by the committers - when a committer is a member of multiple projects they tend to imbue the projects with their own culture. Apache is a single city with a mosaic of subcultures, some of which might be really different in their interests and behaviors, and some are very much alike. Because we are all under one umbrella, and we have open, porous borders, we are free to visit and even belong to other subcultures as well. However I guess you were trying to support the exact opposit view so I will shut up now ;) Don't shut up, but yes indeed I was :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 8:06 AM, Ted Husted [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: I thought I would share, as my thinking about removing community containers here in Jakarta, XML et al resonates well this. Personally, I just think its mainly a matter of packaging. By definination, we are all trying to share the same ASF culture, though each codebase will have its own flavor. If you really believe this, then the right thing is to get rid of *all* containers : Jakarta + HTTPD + XML + TCL + PHP + APR + Perl Lumping everything together under one heading tends to confuse human beings. I think the projects, like XML and Jakarta, make for useful headings, mainly because that how people conceptualize entities like this. And there is no difference in culture? I don't know the answer, but watching the discussion about XML lately, I would think that there *are* differences, so there must be *something* to it. I think both XML and Java/Jakarta make for fine headings. This is overlap between them, but that happens. Moving forward, I might suggest that both Projects ask themselves what type of products they want to carry on their homepage. Should XML be just XML-based, or XML and document-based. Does it confuse people to find product like Batik listed there? Should Jakarta products all have strong ties to server-side technologies? Or is just being Java good enough? If we think of XML as a document-based technology, then it could make sense to see projects like Alexandria, Jetspeed, and Slide under XML -- especially since XML already hosts SOAP and RPC-XML. Likewise, it could also make sense for Batik, FOP, and Xang to be under the Jakarta umbrella. And, given an XML-Commons, should not the Digester live there, with other XML tools? Realistically, many of these placements have been the coincidence of where a committer was already involved. It's easier to bring things up on a list to which you are already subscribed. So we do. So two concrete actions I would suggest for now are: (1) That we petition the ASF to change our charter and remove the word server, so what we are simply charged with providing production quality solutions on the Java platform. I would like to see some opinions on the idea of working to form another apache subproject focused on the client side and if anyone thinks that makes sense. [I'd link to our charter, but can't find the ASF minutes any more, and don't know where else it was published.] (2) That we ask XML if they would like to merge our general lists, so we can more easily discuss matters like this. I'm happy to have POI here, but would really like to know how XML feels about it. Alternatively, perhaps we might consider something like a public apache-projects list, where all the PMCs would meet and discuss issues like this, and conduct the formal votes, and let the general lists revert back to a chat room. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 10:29 AM, Ted Husted [EMAIL PROTECTED] wrote: Ted Husted wrote: (1) That we petition the ASF to change our charter and remove the word server, so what we are simply charged with providing production quality solutions on the Java platform. [I'd link to our charter, but can't find the ASF minutes any more, and don't know where else it was published.] Found our copy at least -- http://jakarta.apache.org/site/pmc/01-03-19-meeting-summary.html at 2.1 So I'm thinking we might propose that our charter be amended to RESOLVED, that the Jakarta Project Management Committee be and hereby is responsible for the creation and maintenance of -1 commercial-quality, open-source, server-side solutions for the Java +1 commercial-quality, open-source solutions for the Java Platform based on software licensed to the Foundation; and be it further So that Ant, BCEL, and whatever would no longer be out of scope, and we could also consider client-side Java packages when they are proposed. I'll continue to swim upstream. Take POI, Ant, BCEL, Oro, Regexp and make that the core of a new client-side project... Not that I think little of Ant, Oro, BCEL and Regexp - actually the converse - I think that they are valuable assets, so I don't say this lightly. I lurk on the Ant list, and know for certain it's a vibrant, active, productive community, and I know that it would be a great anchor for a new project - it's full of people steeped in the jakarta tradition, would be an attractor to users because of the popularity of ant. However, I still worry about the effects on Jakarta. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 11:38 AM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 03:25, Ted Husted wrote: Sam Ruby wrote: I think Roy's reaction is highly predicatable, and should be anticipated. From http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html : Roy identified two potential showstoppers and (1) if there was overlap with other PMCs (example: Cocoon), and (2) if the new proposed PMC could not demonstrate that there is adequate coverage. Sam, when you do this cheshire cat thing, I'm never sure what you are insinuating. Im glad I'm not the only one that happens to ;) Drives me up the wall :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/6/02 12:18 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Here we go again, Alas. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 4:45 AM Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? WHY for presentation? Most of the time you would batch convert Word and Excel docs to HTML if needed, and there are specialized tools for that. 'presentation' in the sense of 'reading data out to show in some manner', not 'on the desktop'. However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? As mentioned in my previous posting, it is JUST like Velocity writing HTML. Huh? You have to explain that a little more - I don't quite get it. http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... Are there many uses for writing Word/Excel documents in a client-side device that has not Word or Excel installed??? You might find this unbelieveable, but not everyone works on a computer that runs an operating system that has Word or Excel available. And AFAIK, if you have Word and Excel, you have at least some Basic scripting... but maybe you do not have Java. ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 12:48 PM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 04:01, Geir Magnusson Jr. wrote: Maybe we could just start having sub-catgories within Jakarta. So basically Jakarta is still the top level project but we have a software map underneath it that categorizes project (ie tools, xml parserns, servers, whatever). How then would this work? What about the non-Java stuff in XML land? Where does that go? You mean there is non-java stuff in xml land? much like there is non-java stuff in jakarta-land? Why does it have to go anywhere? I noted earlier there in non-java stuff here. I bring this up because this thread is *specifically* (at this point) about modifying the charter to strike the word 'server' to open the scope to include non-server technology. Now, since you agreed this was a good thing with your +1 I assumed that you think that the specific of the charter means something. Therefore 'Java' is something we should consider, as we are then again automatically out of scope with out own charter. I personally don't care as much about legalistic conformance to the charter per se - its an important guideline, but the community is what really matters. You can't force volunteers anyway. Again, you might think the above is flip, but you are talking about modifying the charter here... The charter was modified ages ago. Sure the words haven't changed but it has been a long time since jakarta project was actually true to the words in its charter ... see Ant the server-side project And I keep bringing that up for consideration every few months. Even just at the level of organizing the site better to help people visiting us to see what we do. So instead of accepting that we violate scope with more than half the jakarta projects people took to inventing reasons to keep them at jakarta. ie Ant became acceptable because it was a tool that could be used to build serverside projects. How silly is that reason? I am not disagreeing. I have always been of the opinion that scope is a STUPID way to manage this sort of thing because it will inevitably lead to stifling of community or arbitrary violation. Rather than delluding ourselves wouldn't better to disregard scope and instead have a focus. We focus on java products. Traditionally they are serverside and would likely to remain so (because you need a PMC sponsor/champion for new projects and most PMC members are serverside peeps). However I would have no problem if someone wanted to have other similarly focused projects - even if they were clienside or written in c or whatever. And with the recent suggestion to get rid of the PMC and just do it via group consensus, then what? No more PMC champion. And without the PMC, I suspect no more Jakarta if Roy hasn't changed his mind. For instance if IBM wanted to donate jikes to Apache and there was enough community to support it - would you knock it back because it was C? or would you reclassify it as a compiler used to build serverside java apps? No, I think it would be great. However, it's not clear that we dump everything with a .java file into Jakarta though. That would be another great 'anchor project' to build a new project around. What happens if the Jext or JEdit editors (or the merge if it ever occurs) wanted to join in Jakarta and had a like-minded community - would you knock it back because it was clientside? or would you reclassify it as something used to write serverside apps? I would again try to get is to consider that we have a great chance to use a strong community to anchor a new project. Jakarta can't grow forever. When do you decide to actually step up and try to make a change? I hope it's *before* the outside perception of Jakarta changes from that of a place of high-quality projects with strong communities and colorful characters, to Apache Sourceforge for Java. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 1:26 PM, Sam Ruby [EMAIL PROTECTED] wrote: Peter Donald wrote: Again, you might think the above is flip, but you are talking about modifying the charter here... The charter was modified ages ago. Sure the words haven't changed but it has been a long time since jakarta project was actually true to the words in its charter ... see Ant the server-side project So instead of accepting that we violate scope with more than half the jakarta projects people took to inventing reasons to keep them at jakarta. ie Ant became acceptable because it was a tool that could be used to build serverside projects. How silly is that reason? Slightly revisionist. Ant was part of the original charter for Jakarta. There was a sister project named Java which contained a number of other projects Just to have a little fun (and this time, it is very intentional)... the project I consider most out of scope is dvsl. There is nothing server specific about it, and has everything in the world to do with XML. Check it out for yourself: http://jakarta.apache.org/velocity/dvsl/index.html . I do too, and I wrote it. I was going to put DVSL at sourceforge, but was strongly encouraged by people I talked to to make it a part of the Velocity community. Note that it isn't considered 'core' to velocity. I even bought the dvsl.org domain name, so you know that I am being honest here. To that end, gump is just susceptible to the same observation. Until recently, it wasn't even written in java, was it? Wasn't it shell scripts and xsl? Maybe we should use it as an anchor project for an Apache shell script and xsl community :) And I thought that my belief that sam picks on me was my delusion... I still maintain that scope is a distraction. Community is what is important. I think I wrote that a message or to ago as well. More crossing the ether I suppose. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cultural homogeneity
On 1/6/02 1:59 PM, Peter Donald [EMAIL PROTECTED] wrote: With the the high threshold of entry I doubt jakarta will ever be in the same category as sourceforge - I can't see that as anything but a strawman that is brought up every now and again ;) Here is the threshold of entry as stated by Sam today : On 1/6/02 11:50 AM, Sam Ruby [EMAIL PROTECTED] wrote: Similarly, if POI or any other code base actively wanted to join Jakarta and we felt it was compatible with the community, then I would fight to make whatever adjustments to the charter that were required to make this happen. First, I don't necessarily disagree. The point of discussion in Sams statement is the phrase we felt it was compatible with the community. As the community grows, I think the notion of 'compatible' gains a larger surface area, which means that by waiting around long enough, any project is acceptable as the surface area will eventually grow such that your location in 'parameter space' is near enough. It's stepwise in a way : the best argument about POI so far is that Lucene can use it, so now we extend from Lucene to POI. (Again, welcome POI :) That assumes that the community can be sustained to an arbitrarily large size. I wonder if it can (I don't know), I wonder if the risk is worth the possible upside, and I wonder if now isn't an appropriate time to consider this issue :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Now what do we do? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
On 1/6/02 2:21 PM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 06:10, Sam Ruby wrote: Shouldn't... Velocity and Jasper be in the same category? Watchdog and Tomcat be in the same category? Jmeter and Cactus be in the same category? Lucene and Oro be in the same category? Shouldn't JMeter and Watchdog be in the same category? Shouldn't Avalon and Log4j be in the same category? Shouldn't Avalon and Commons be in the same category? Shouldn't Avalon and Tomcat be in the same category? Shouldn't Turbine and Commons be in the same category? Shouldn't Cactus and JMeter be in the same category? Shouldn't Cactus and Watchdog be in the same category? Shouldn't tomcat and httpd be in the same category? Shouldn't Cocoon and PHP be in the same category? Shouldn't APR and Commons and Avalon be in the same category? Shouldn't TCL and Perl be in the same category? -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
On 1/6/02 3:54 PM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 07:27, Geir Magnusson Jr. wrote: Shouldn't tomcat and httpd be in the same category? different technologies (ie c vs java). So what? You didn't think that mattered before. Shouldn't Cocoon and PHP be in the same category? different technologies (ie c vs java) So what? You didn't think that mattered before. Shouldn't APR and Commons and Avalon be in the same category? Commons + Avalon = yes APR is different technology So what? You didn't think that mattered before. Shouldn't TCL and Perl be in the same category? No idea what they actually consist of but I suspect the communities are not compatible ;) Apache is generally broken by technology boundaries. While sometimes there is overlap (ie xerces-c xerces-j) but it is mostly the case that committers stick to one technology - except for some oddballs like Sam ;) - and thus thats where the community is. Occasionally you will some people bridge between different technology (ie PHP in cocoon, connectors in TC, ...) but that is the exception rather than the norm. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI Â @apache]
On 1/6/02 9:10 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 6:55 PM On 1/6/02 12:58 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: ... If you start at the top of the thread, I declare I am playing devils' advocate, and addressing the three URLs that andrew gave. The Devil's advocate gets flamed as any other one or more, didn't you know? =;o) hehe I don't think it should be used for anything - that's up to the users and I would never try to make an assertion to that end. YYYs!!! When I said should I was expressing a personal opinion. Like when I say people should NOT use Windows. That would be my personal opinion. Being wrong is a human right of sorts ,so everyone is free to disagree with me. :-D You never said 'should' and this is a bit out of context, isn't it? I don't understand what you are doing with this. You left out the actual statement from Paulo where he was asking if I thought something should be... He said : Of course, but are you sure it is so clear that POI should mostly be used for presentation and indexing? I never said should. What I said was : Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? I think we should keep this clear. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POIÂ @apache]
On 1/6/02 9:51 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: My apologies. I'll shut up now until my brain un-freezes. :-D -Andy Sheesh. Give southerners a dusting of snow and all goes pear shaped... :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Now what do we do? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: OT: northern drivers and their snow...was: Re: On unityandcoherence [was Re: [Request For Comment] POIÂ @apache]
On 1/6/02 11:14 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Yeah RIGHT. Northern cars don't even HAVE blinkers! Of course not - then you would know when we are about to cut you off... When up north I drive real slow in the just left of the right lane (avoid northern style kamikaze merges) with my hazard lights on going about 70 (which must be below the minimum speed limit). So that was you? I think just left of the right lane is a strange way to describe straddling the center. LOL. Yes, doing 70 anywhere but the right lane is a traffic hazard. BTW the north to me starts just a little above Richmond. I grew up in Florida precipitation is called normal. Its the cold white stuff that I don't like. (that might also be a result of driving a Miata) That actually sounds like a fun car for the snow... -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
On 1/6/02 5:26 PM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 08:05, Geir Magnusson Jr. wrote: On 1/6/02 3:54 PM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 07:27, Geir Magnusson Jr. wrote: Shouldn't tomcat and httpd be in the same category? different technologies (ie c vs java). So what? You didn't think that mattered before. what are you talking about ? When have I said merging incompatible communities never mattered ? Good try. You said that the technologies don't matter (you even say it above :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: crushed
On 1/7/02 11:03 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 1/7/02 7:27 PM, Tim Vernum [EMAIL PROTECTED] wrote: If the project won't deal with gump nags, and can't keep their builds from breaking then they probably won't fit into Jakarta. Bingo. Great point. However, forcing a project to have gump nags is not something Sam is willing to dictate. Having a project that 'fits into Jakarta' is also something no one is willing to dictate (except me of course...but that means nothing anymore...)... -jon I agree with Sam here - you have to buy into the Gump nags and understand the value, or you are going to think it's an intrusive fussyness, which it is, actually :) I think most people buy into it and get it. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
On 1/7/02 12:53 AM, Peter Donald [EMAIL PROTECTED] wrote: On Mon, 7 Jan 2002 15:39, Geir Magnusson Jr. wrote: Shouldn't tomcat and httpd be in the same category? different technologies (ie c vs java). So what? You didn't think that mattered before. what are you talking about ? When have I said merging incompatible communities never mattered ? Good try. You said that the technologies don't matter (you even say it above :) Sigh .. I need some of those Cheshire cat skills. The point I was trying to get across was this. I assumed you were being facetious ? no? In some ways, no - I think it was stefano that said something to the order of removing all artificial containers surrounding projects or groups of projects. I think that if we looked at that, we might discover that governance of something like that would be challenging (governance could be entirely self-governance : no implications of any sort intended...) I don't really care that tomcat has a native connector and daemon architecture, nor do I care whether xerces has a c version. Why ? Because they are the same community. Presumably you don't think Pier is not part of the tomcat project - yet he did write a c daemon architecture (and some of the connectors?) - does that mean his work should not be part of jakarta ? No - this paragraph above reaches back to my unanswered questions about the real meaning of the charter, of which a clarification was suggested which you agreed to (removing server), but then I noted we would still be out of scope (beaause of java). I don't care about the tech either - I mean, much of Gump is XSL, right? I was being a bit facetious earlier on the Alexandria list - note that The Law specifies that all code be documented according to javadoc coding conventions. If Sam wishes to remain in compliance with the law, his XSL Gump code needs to be documented that way (which I don't believe possible). My point is that the constant appeal to codified law sometimes misses the spirit of the law, and allows it to be used as a club, which I don't like. I admit it is my personality to err on the side of 'chaos' away from the law, but still. The PHP/Perl/TCL/Httpd people on average have little involvement in the java development scene is my guess - I certainly haven't seen any huge crosstalk between them and jakarta - have you ? Never. I also will say I haven't seen community crosstalk between XML and Jakarta, from the point of view as communities. I know there are individuals who contribute greatly to both communities, and many of us here in Jakarta depend on XML projects. But in the sense of us really having discussion of cross-community issues, the only one I can recall seeing is Stefano's request to disband PMCs because of his issues with XML's. Because they work on different technologies there is unlikely to emerge any great collaborative works between developers as often developers specialize in development approach (ie java). Technologies don't matter - communitys do. I agree - I think my statement was Charter doesn't matter - the community does... It would be pointless to merge disconnected communities when there is no community incentive to do so. The community is unlikely to form between groups of developers who work on different technologies if there is little common ground. xerces c developers presumably have common ground with their java counterparts, Pier presumably has common ground with the other tomcat developers. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: crushed
On 1/7/02 11:20 PM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 1/7/02 8:10 PM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I agree with Sam here - you have to buy into the Gump nags and understand the value, or you are going to think it's an intrusive fussyness, which it is, actually :) Or you could think of it this way... Part of the 'privilege' of being able to host your project on Jakarta is the requirement of needing to accept our way of doing things. Of course being dictators about everything isn't going to work...things like forcing everyone to use OSX and a certain IDE definitely won't fly... However, when there are areas where we know damn well that something is the right way to do things (such as using the ASF license, using Gump's nag features, having javadocs targets and being consistent in using documented code formatting), that is part of being part of the Jakarta Community and the group of people who 'get it'. It is part of being in a larger community collective and sharing some similar values and development principles. Yep - but you have to bring these things to the community by consensus. For example, new things were learned as Gump evolved. (And are still being learned today) Now, you added the nag.pl, but that was by fiat, wasn't it? Not in a bad way - you saw something and took the initiative - but others didn't understand right away. After a while, it became accepted, even cherished. (Who am I kidding - Gump is never cherished - that just made for good copy. It's a pain in the neck, annoying, written in ugly pointy bracket stuff, and insanely valuable :) That is what should make us different than Sourceforge... Fine, but it comes from consensus, doesn't it? I can't suppose that I can tell you about that - you were/are my 'mentor' in most of this - but I hope that you can step back and at least consider that the failure is our own if we can't rally around a set of common mores. Why are we failing? I am suspicious of our size :) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
