Re: [all] Suggestion for all of Commons
On 30/03/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar Yeah, +1. I tend to go to ibiblio to get downloads half the time now; sad :) Definitely valuable to be able to download just the jar, especially for Commons things. If you don't like ibiblio, you can of course always use http://www.apache.org/dist/java-repository/ Bundling dependencies is a last century waste of bandwidth, IMHO. I agree though that making it clear what they are is important. Might we worth a maven ticket to get them moved up in the default nav . I vaguely remember this being discussed before either here or on maven-user. +1 Why not include it in the Download section of the navigation - e.g: Download * Releases (mirrored) * Nightly snapshots + Dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 29/03/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: +1 I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. -1 if that is the only archive type made available Urk. No thanks. If I download a couple of Commons components, and they share a couple of dependencies, and the bundled versions of those dependencies are different, what should I, as a user, do? I think that would just cause more confusion within the user base. +1 As for having just a single distribution, I'm not in favour of that either. The vast majority of users don't give a dickey bird about the source, and it just bulks up the distribution, and therefore the size of the end user's distribution as well. I doubt our users will thank us for increasing the size of their own applications, potentially increasing their bandwidth usage for customers to download their products. +1 Seems to me the binary download should be the minimum needed to run the component; the source download should not include any jars that are in the binary download. Depending on the component, potentially put the javadoc in a separate jar. -- Martin Cooper 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
Please prefix with [all], yup, its a bit tricky ;-) On 3/29/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: Hey all, I just spent about 20 minutes working through a problem with FileUpload... turned out to be my fault entirely, I didn't include Commons IO (FYI, I'm not seeing a dependency list on the FileUpload site... maybe I missed it). snip/ Its here: http://jakarta.apache.org/commons/fileupload/dependencies.html snip-dependency-check-code-snippet/ Or maybe we should simply advertise the dependencies pages better? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 1:33 pm, Rahul Akolkar said: Please prefix with [all], yup, its a bit tricky ;-) Sorry, forgot :) Its here: http://jakarta.apache.org/commons/fileupload/dependencies.html Hmm, weird... I go to: http://jakarta.apache.org/commons/fileupload/ And I don't see a link to it... ah, I see... have to expand the Project Info branch first. Yes, I would suggest that being more front and center, i.e., visible right away. I know I'm the only person that has ever been burned by missing dependencies, it would be much better if that info was right there right away with no digging. snip-dependency-check-code-snippet/ Or maybe we should simply advertise the dependencies pages better? Certainly that would suffice. I think the code telling you when a dependency is missing is a little friendlier, but certainly it isn't necessary, as long as the information is quick and easy to find. -Rahul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 1:42 pm, Martin Cooper said: You did. See: http://jakarta.apache.org/commons/fileupload/dependencies.html This is the standard location for the dependency list for all Commons components. Yep, was pointed out to me. As I mentioned in the other thread, I'd personally like to see that not buried beneath a branch like it is... I for one didn't know that was the standard location for Commons, I can't imagine I'm the only one that didn't know that. The stack trace should have shown a NoClassDefFoundError indicating a class in Commons IO. I haven't seen a situation where that's not the case, and that's also been the case for all of the people who've asked about it on the list, at least that I can recall. It didn't... I think its because the method that uses FileUpload was called from a piece of code that was reflectively creating its class and calling it, so I was catching InvocationTargetException there, and that's what was showing up in the logs... that's what I was seeing in the logs, and the first line of the trace was the code inside the catch block, not any code in the class using FileUpload. It was a bit confusing for a few minutes. Aside from the fact that Class.forName is generally not a good idea in a J2EE environment I hadn't heard that. Why is that? , I personally have a strong dislike for static initialisers, so I'm not inclined to do something like this for components I work on. Fair enough, I just wanted to make the suggestion. I'm interested though, why don't you like static initializers? Just curious ;) Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, March 29, 2006 1:42 pm, Martin Cooper said: You did. See: http://jakarta.apache.org/commons/fileupload/dependencies.html This is the standard location for the dependency list for all Commons components. Yep, was pointed out to me. As I mentioned in the other thread, I'd personally like to see that not buried beneath a branch like it is... I for one didn't know that was the standard location for Commons, I can't imagine I'm the only one that didn't know that. snip/ OK, I will put the link in a more obvious place for one of the sandbox components [scxml]. If others like it, it might become a popular trend. Aside from the fact that Class.forName is generally not a good idea in a J2EE environment I hadn't heard that. Why is that? snip/ * Many more classloaders in J2EE environments * Atleast need to use the three argument version using the TCCL, even that isn't a given , I personally have a strong dislike for static initialisers, so I'm not inclined to do something like this for components I work on. Fair enough, I just wanted to make the suggestion. I'm interested though, why don't you like static initializers? Just curious ;) snap/ * Libraries may be in shared environments where some initializations may not work well * Users have numerous classloader delegation models, loading classes via static code can get tricky -Rahul Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On Wed, March 29, 2006 3:08 pm, Rahul Akolkar said: Aside from the fact that Class.forName is generally not a good idea in a J2EE environment I hadn't heard that. Why is that? snip/ * Many more classloaders in J2EE environments * Atleast need to use the three argument version using the TCCL, even that isn't a given Hehe, based on my experience with Websphere and the Classloaders From Hell that it is, I should have known that :) Good point about the 3-argument version... I don't want the checked classes to be initialized, so throwing false in there is fine (even though the specified classloader would be equivalent). Fair enough, I just wanted to make the suggestion. I'm interested though, why don't you like static initializers? Just curious ;) snap/ * Libraries may be in shared environments where some initializations may not work well * Users have numerous classloader delegation models, loading classes via static code can get tricky But if the intent is just to test if a given class is available for use by the loading class, aren't these points, if not irrelevant, than at least minimized? I totally see your point if we were talking about static initialization of members or actually loading/intializing a class (i.e., JDBC driver or similar). I'm not so sure I see the problem in the case of a simple is class X available to me check. Well, in any case, making the dependency list more visible addresses the concern, so that's cool, I hope others agree and pick up on it. Sandy's point about it being on the download page is a good one too, I'd be more than satisfied either way. Thanks! -Rahul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
Sandy McArthur wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. With the advent of maven (and the maven ant tasks to a lesser extent) and its central repository, I have found I almost never need to go through that exercise any more. A bit of doc something like... p To include commons-xxx as dependency for your maven 2.x project (and transitively, commons-xxx's dependencies) use the following in your codepom.xml/code: source dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx/artifactId version1.0/version scopecompile/scope /dependency /source /p p To include commons-xxx as a dependency for your maven 1.x project use the following in your codeproject.xml/code: source dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx/artifactId version1.0/version /dependency !-- dependencies for commons-xxx -- dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx-dependency0/artifactId version2.5/version /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-xxx-dependency1/artifactId version3.0/version /dependency /source /p (and a similar example using the maven ant tasks) ...would be quite useful to have on a download page, and could probably be generated via the maven 1.x or 2.x dependency plugin. michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar Yeah, +1. I tend to go to ibiblio to get downloads half the time now; sad :) Definitely valuable to be able to download just the jar, especially for Commons things. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. Urk. No thanks. If I download a couple of Commons components, and they share a couple of dependencies, and the bundled versions of those dependencies are different, what should I, as a user, do? I think that would just cause more confusion within the user base. As for having just a single distribution, I'm not in favour of that either. The vast majority of users don't give a dickey bird about the source, and it just bulks up the distribution, and therefore the size of the end user's distribution as well. I doubt our users will thank us for increasing the size of their own applications, potentially increasing their bandwidth usage for customers to download their products. -- Martin Cooper 1. Find the component's site. 2. Find the download link on the site. 3. See want they want to download (src/bin, tar/zip) 4. Unpack 5. Find the jar and add it to their project. Step #3 is where we have the most cranial activity available to us and we should take advantage of that. Any other step and the end user is just going through the motions trying to get their work done with as little effort as possible. Agreed. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: snip/ Well, in any case, making the dependency list more visible addresses the concern, so that's cool, I hope others agree and pick up on it. Sandy's point about it being on the download page is a good one too, I'd be more than satisfied either way. Thanks! snap/ OK, I did this [1]. A small step. -Rahul [1] http://jakarta.apache.org/commons/sandbox/scxml/ Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/29/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: snip/ Well, in any case, making the dependency list more visible addresses the concern, so that's cool, I hope others agree and pick up on it. Sandy's point about it being on the download page is a good one too, I'd be more than satisfied either way. Thanks! snap/ OK, I did this [1]. A small step. -Rahul [1] http://jakarta.apache.org/commons/sandbox/scxml/ The one thing I wish we could do on that page (well the dependencies one linked from it) is a nice link to ibiblio (or the asf repository) to download the jar there. Oh, and the m2 snippet that someone else mentioned, but the ibiblio link would be nice too. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Suggestion for all of Commons
On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/29/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Or maybe we should simply advertise the dependencies pages better? Dependencies should be listed on the download page. The mind set of someone wanting to to use a component is and I know this from having done it a dozen or so times: I've come to believe that dependencies should be included in the distribution. Also that we shouldn't bother with binary and source distributions anymore; be like tapestry/hivemind (I think they're the ones) and have just the one dist file. I'm almost cool with that. I'd be happy with a full download (binary.jar, sources, docs, etc) and just the raw binary.jar 85% of the time downloading the binary distrobution is just an extra step to get to what I want: the binary.jar Yeah, +1. I tend to go to ibiblio to get downloads half the time now; sad :) Definitely valuable to be able to download just the jar, especially for Commons things. If you don't like ibiblio, you can of course always use http://www.apache.org/dist/java-repository/ Bundling dependencies is a last century waste of bandwidth, IMHO. I agree though that making it clear what they are is important. Might we worth a maven ticket to get them moved up in the default nav . I vaguely remember this being discussed before either here or on maven-user. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
