You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2006/03/29 20:24:19 UTC
Suggestion for all of Commons
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).
The problem is, it was one of those aggrevating problems to track down
because the stack trace didn't reveal the actual line where the failure
occured, and catching Exception didn't get triggered. I wound up catching
Throwable, and I was then able to figure it out.
I know that missing dependencies is always a b**ch, and they tend to be
these annoying problems with no error messages or anything (sure, a
debugger helps, but that doesn't seem like the best answer to me). So, I
have a suggestion that could well go all across Commons, or any other
project for that matter.
In Java Web Parts, we've gotten into the habit of putting this in all
classes:
/**
* This static initializer block tries to load all the classes this one
* depends on (those not from standard Java anyway) and prints an error
* meesage if any cannot be loaded for any reason.
*/
static {
try {
Class.forName("org.apache.commons.logging.Log");
Class.forName("org.apache.commons.logging.LogFactory");
} catch (ClassNotFoundException e) {
System.err.println("CacheControlFilter" +
" could not be loaded by classloader because classes it depends" +
" on could not be found in the classpath...");
e.printStackTrace();
}
}
It's just echoing the import list, minus classes found in the SDK (if
that's missing, you aren't getting *this* far!). This saves a lot of time
and headache when you are missing a dependency. I know that adds
something additional to maintain in the class, but it seems a fair
trade-off to me.
Does anyone see this as being something that might be helpful for Commons?
If there is a better way to get the same effect I'm all ears too (I could
see setting a string to the name of the class being checked so that it
could be output as part of the error message, but I'm talking about a
whole other way to check for dependencies).
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Suggestion for all of Commons
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
It did, but because of the way the code around it was structured it got
masked in the stack trace and wasn't obvious right away. It looks like
what happened is that the method that made use of FileUpload was called
reflectively, and because I was catching TargetInvocationException, the
NoClassDefFoundError got "converted" to TargetInvocationException.
Frank
Dakota Jack wrote:
> Out of curiosity, didn't this throw a NoClassDefFoundError? If not, that
> indicates a coding choice someone might want to change..
>
> On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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).
>>
>> The problem is, it was one of those aggrevating problems to track down
>> because the stack trace didn't reveal the actual line where the failure
>> occured, and catching Exception didn't get triggered. I wound up catching
>> Throwable, and I was then able to figure it out.
>>
>> I know that missing dependencies is always a b**ch, and they tend to be
>> these annoying problems with no error messages or anything (sure, a
>> debugger helps, but that doesn't seem like the best answer to me). So, I
>> have a suggestion that could well go all across Commons, or any other
>> project for that matter.
>>
>> In Java Web Parts, we've gotten into the habit of putting this in all
>> classes:
>>
>> /**
>> * This static initializer block tries to load all the classes this one
>> * depends on (those not from standard Java anyway) and prints an error
>> * meesage if any cannot be loaded for any reason.
>> */
>> static {
>> try {
>> Class.forName("org.apache.commons.logging.Log");
>> Class.forName("org.apache.commons.logging.LogFactory");
>> } catch (ClassNotFoundException e) {
>> System.err.println("CacheControlFilter" +
>> " could not be loaded by classloader because classes it depends" +
>> " on could not be found in the classpath...");
>> e.printStackTrace();
>> }
>> }
>>
>> It's just echoing the import list, minus classes found in the SDK (if
>> that's missing, you aren't getting *this* far!). This saves a lot of time
>> and headache when you are missing a dependency. I know that adds
>> something additional to maintain in the class, but it seems a fair
>> trade-off to me.
>>
>> Does anyone see this as being something that might be helpful for Commons?
>> If there is a better way to get the same effect I'm all ears too (I could
>> see setting a string to the name of the class being checked so that it
>> could be output as part of the error message, but I'm talking about a
>> whole other way to check for dependencies).
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM: fzammetti
>> Yahoo: fzammetti
>> MSN: fzammetti@hotmail.com
>> Java Web Parts -
>> http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Suggestion for all of Commons
Posted by Dakota Jack <da...@gmail.com>.
Out of curiosity, didn't this throw a NoClassDefFoundError? If not, that
indicates a coding choice someone might want to change..
On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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).
>
> The problem is, it was one of those aggrevating problems to track down
> because the stack trace didn't reveal the actual line where the failure
> occured, and catching Exception didn't get triggered. I wound up catching
> Throwable, and I was then able to figure it out.
>
> I know that missing dependencies is always a b**ch, and they tend to be
> these annoying problems with no error messages or anything (sure, a
> debugger helps, but that doesn't seem like the best answer to me). So, I
> have a suggestion that could well go all across Commons, or any other
> project for that matter.
>
> In Java Web Parts, we've gotten into the habit of putting this in all
> classes:
>
> /**
> * This static initializer block tries to load all the classes this one
> * depends on (those not from standard Java anyway) and prints an error
> * meesage if any cannot be loaded for any reason.
> */
> static {
> try {
> Class.forName("org.apache.commons.logging.Log");
> Class.forName("org.apache.commons.logging.LogFactory");
> } catch (ClassNotFoundException e) {
> System.err.println("CacheControlFilter" +
> " could not be loaded by classloader because classes it depends" +
> " on could not be found in the classpath...");
> e.printStackTrace();
> }
> }
>
> It's just echoing the import list, minus classes found in the SDK (if
> that's missing, you aren't getting *this* far!). This saves a lot of time
> and headache when you are missing a dependency. I know that adds
> something additional to maintain in the class, but it seems a fair
> trade-off to me.
>
> Does anyone see this as being something that might be helpful for Commons?
> If there is a better way to get the same effect I'm all ears too (I could
> see setting a string to the name of the class being checked so that it
> could be output as part of the error message, but I'm talking about a
> whole other way to check for dependencies).
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: [all] Suggestion for all of Commons
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by sebb <se...@gmail.com>.
On 30/03/06, Phil Steitz <ph...@gmail.com> wrote:
> On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > > On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> > > > On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > > > > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Phil Steitz <ph...@gmail.com>.
On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> > > On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > > > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Henri Yandell <fl...@gmail.com>.
On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Sandy McArthur <sa...@apache.org>.
On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by sebb <se...@gmail.com>.
On 29/03/06, Martin Cooper <ma...@apache.org> wrote:
> On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
> >
> > On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Martin Cooper <ma...@apache.org>.
On 3/29/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> > On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Suggestion for all of Commons
Posted by Henri Yandell <fl...@gmail.com>.
On 3/29/06, Sandy McArthur <sa...@apache.org> wrote:
> On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Michael Heuer <he...@acm.org>.
Sandy McArthur wrote:
> On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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
<code>pom.xml</code>:
<source>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-xxx</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
</source>
</p>
<p>
To include commons-xxx as a dependency for your maven 1.x project use the
following in your <code>project.xml</code>:
<source>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-xxx</artifactId>
<version>1.0</version>
</dependency>
<!-- dependencies for commons-xxx -->
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-xxx-dependency0</artifactId>
<version>2.5</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-xxx-dependency1</artifactId>
<version>3.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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Sandy McArthur <sa...@apache.org>.
On 3/29/06, Rahul Akolkar <ra...@gmail.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Rahul Akolkar <ra...@gmail.com>.
Please prefix with [all], yup, its a bit tricky ;-)
On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Henri Yandell <fl...@gmail.com>.
On 3/29/06, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Suggestion for all of Commons
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Suggestion for all of Commons
Posted by Martin Cooper <ma...@apache.org>.
On 3/29/06, Frank W. Zammetti <fz...@omnytex.com> 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).
You did. See:
http://jakarta.apache.org/commons/fileupload/dependencies.html
This is the standard location for the dependency list for all Commons
components.
The problem is, it was one of those aggrevating problems to track down
> because the stack trace didn't reveal the actual line where the failure
> occured, and catching Exception didn't get triggered. I wound up catching
> Throwable, and I was then able to figure it out.
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.
I know that missing dependencies is always a b**ch, and they tend to be
> these annoying problems with no error messages or anything (sure, a
> debugger helps, but that doesn't seem like the best answer to me). So, I
> have a suggestion that could well go all across Commons, or any other
> project for that matter.
>
> In Java Web Parts, we've gotten into the habit of putting this in all
> classes:
>
> /**
> * This static initializer block tries to load all the classes this one
> * depends on (those not from standard Java anyway) and prints an error
> * meesage if any cannot be loaded for any reason.
> */
> static {
> try {
> Class.forName("org.apache.commons.logging.Log");
> Class.forName("org.apache.commons.logging.LogFactory");
> } catch (ClassNotFoundException e) {
> System.err.println("CacheControlFilter" +
> " could not be loaded by classloader because classes it depends" +
> " on could not be found in the classpath...");
> e.printStackTrace();
> }
> }
Aside from the fact that Class.forName is generally not a good idea in a
J2EE environment, I personally have a strong dislike for static
initialisers, so I'm not inclined to do something like this for components I
work on. Other folks may like it, though. ;-)
--
Martin Cooper
It's just echoing the import list, minus classes found in the SDK (if
> that's missing, you aren't getting *this* far!). This saves a lot of time
> and headache when you are missing a dependency. I know that adds
> something additional to maintain in the class, but it seems a fair
> trade-off to me.
>
> Does anyone see this as being something that might be helpful for Commons?
> If there is a better way to get the same effect I'm all ears too (I could
> see setting a string to the name of the class being checked so that it
> could be output as part of the error message, but I'm talking about a
> whole other way to check for dependencies).
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [fileupload] Suggestion for all of Commons
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Wed, March 29, 2006 4:36 pm, Stephen Colebourne said:
> Frank W. Zammetti wrote:
>> 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).
>
> We've seen a few fileupload/io issues come through. I think maybe I
> should have stuck to my guns on not adding an [io] dependency to
> [fileupload]... ;-)
We came to the same conclusion as Henri when it comes to dependencies with
Java Web Parts, that's why things like Commons Lang is included. We
actually took it a bit further and put those classes in our package
structure, but that was to avoid even having to have more JARs floating
around, i.e., you include javawebparts-core.jar all the time, then just
include the JARs you are interested in beyond that... the only external
depenendency we left was JCL, just to hopefully avoid any classloader
issues that might arise.
IO doesn't at all strike me as an unreasonable dependency, so don't fret
it too much :) I think simply making sure it is well-known is enough, and
that just means prominently on the web site (whether on the download page,
front page, or whatever, but it should be very hard to miss).
> Stephen
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [fileupload] Suggestion for all of Commons
Posted by Martin Cooper <ma...@apache.org>.
On 3/29/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
>
> Frank W. Zammetti wrote:
> > 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).
>
> We've seen a few fileupload/io issues come through. I think maybe I
> should have stuck to my guns on not adding an [io] dependency to
> [fileupload]... ;-)
And I, on the other hand, am quite happy that, as about the only developer
who ever works on FileUpload, I got to do what I felt was right, rather than
having an opposing view imposed on me. ;-)
--
Martin Cooper
Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [fileupload] Suggestion for all of Commons
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Frank W. Zammetti wrote:
> 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).
We've seen a few fileupload/io issues come through. I think maybe I
should have stuck to my guns on not adding an [io] dependency to
[fileupload]... ;-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org