This is an incomplete fix and brings up a larger issue that I'll explain
below. Also, this breaks the customization of openBox/closeBox/separator
Strings.
First off, I know of no Collection that doesn't have a decent toString()
implementation. The java.util.Abstract* classes all do something
reasonable and most Collections are built from those.
Guava's Multiset has a defined way of representing itself as a String.
An example would be "[value1, value2 x 100]". This fix is mainly
addressed at fixing that, as this class would do the very dumb thing
if provided with a Multiset.
Do we really customize the openBox/closeBox/separator values? Should we?
The second issue comes from the way Log uses StringUtil to evaluate
the var-args it is passed. Check out the following code.
Iterator<Thing> it = Iterables.concat(_staticThings, newThings).iterator();
log.debug("About to iterate", "user", user, "request", req, "iterator", it);
while (it.hasNext()) {
...
If the logging level is above debug, this works fine. However if one day
you lower your logging level, the message will be logged and the Iterator
will be passed to String.toString(), which will suck all the elements out of it.
That's a problem.
Actually, perhaps the right thing to do is simply to change the Log class
to avoid using this, and instead just call String.valueOf() on all objects
except arrays, which can instead be String'd with the methods added to
java.util.Arrays in 1.5.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2884 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Velocity stuff actually works with a non-hacked Velocity implementation, and
specifically VelocityUtil and ClasspathResourceLoader are used all over the
place for great justice, so we want to support that.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2881 6335cc39-0255-0410-8fd6-9bcaacd3b74c
things, which ended up being infeasible. But I'll leave this test machinery
here as it may be useful in the future if we want to add more
com.samskivert.jdcb unit tests.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2880 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Instead of fixing this utterly ridiculous problem, some guy submitted a patch
to detect when someone was using spaces in the text of <compilerArgument> and
spit out a warning, directing them to a new FAQ entry explaining the
limitation, and telling them this retarded workaround:
http://jira.codehaus.org/browse/MCOMPILER-130
He then included a bunch of code to allow this warning to be turned off.
WTFFFFFFFFFFFFFFFFFFFFF!?
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2875 6335cc39-0255-0410-8fd6-9bcaacd3b74c
public interfaces and if you are making use of protected members, you should be
looking at the source.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2869 6335cc39-0255-0410-8fd6-9bcaacd3b74c
publishing to the public Maven repositories much simpler. Being published to
the public Maven repositories makes life easier for everyone who wants to
depend on samskivert.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2864 6335cc39-0255-0410-8fd6-9bcaacd3b74c
fucking arbitrary version you like". Fortunately, it is possible to instruct
Maven to do what would be the sensible default: use the latest release version
of the plugin.
Now that I have done so, the magical insertion of a -link argument for the Java
API is working. Much to my chagrin, the associated <detectLinks> option of the
javadoc plugin is a cruel joke.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2862 6335cc39-0255-0410-8fd6-9bcaacd3b74c
Sun "enhanced" the jar file specification to allow dependencies to be expressed
inside jar files, which cause the JVM to try to magically add dependent jar
files to the classpath. This is half-assed and wrong in too many ways to
enumerate here.
They then helpfully added activation.jar to mail.jar under the multiple
misguided assumptions that no one would ever possibly need to use mail.jar
without also having activation.jar in their classpath, with that exact name,
and located precisely in the same directory. I can't possibly imagine devating
from those implicit requirements.
Maven then upped the ante on this little fiasco by deciding that any time the
Java compiler generates a warning that they can't parse, they should fail the
build. Clearly it's critical that your build system be conversant in every
possible warning that might be emitted by your compiler. As a result, when I
fix their boneheaded default of suppressing warnings by default, the build now
fails with this demonstration of awesomeness:
could not parse error message: warning: [path] bad path element
"/home/mdb/.m2/repository/javax/mail/mail/1.4.1/activation.jar": no such file
or directory
Thank you Sun, and thank you Maven.
Fortunately, I can tell javac to not emit warnings for these bogus jar
dependencies, which I have done.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2860 6335cc39-0255-0410-8fd6-9bcaacd3b74c
1. Warnings and deprecations are not shown by default.
2. Documentation shows use of <compilerArgument> with mulitple arguments in a
single element:
<compilerArgument>-foo -bar</compilerArgument>
which is a bald-faced lie. Only a single argument is allowed inside a
<compilerArgument> element. Web search turns up "helpful" advice to use
multiple elements:
<compilerArgument>-foo</compilerArgument>
<compilerArgument>-bar</compilerArgument>
Fair enough, and also a bald-faced lie. After spending a bunch of time
debugging why my compiler arguments were not working, I discovered that Maven
was just (silently) using the last one and ignoring/overwriting all of the
previous arguments.
I had noticed while poring over the documentation that it was also possible to
use the so-called "Map version" (whatever that means), which uses this
completely fucking stupid syntax:
<compilerArguments>
<foo/>
<bar/>
</compilerArguments>
Why is that syntax completely fucking stupid, you might ask? Well, dear reader,
because the arguments that I'm actually passing end up looking like this:
<compilerArguments>
<Xlint/>
<Xlint:-serial/>
</compilerArguments>
which is a case study in how not to represent information in XML. I didn't even
try that originally because I was sure that it would not work, given the wacky
non-[a-zA-z]+ nature of the argument I needed to supply. The fact that it does
work gives me the fear.
You might wonder if the following form would provide satisfaction:
<compilerArguments>
<compilerArgument>-Xlint</compilerArgument>
<compilerArgument>-Xlint:-serial</compilerArgument>
</compilerArguments>
Other than being absurdly verbose, it seems right in line with The Maven Way
(tm). However, that results in -compilerArgument=-Xlint and
-compilerArgument=-Xlint:-serial being passed to the compiler. Hilarity
naturally ensues.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2859 6335cc39-0255-0410-8fd6-9bcaacd3b74c
line count of the build.xml file, but I suppose that's just because XML is
absurdly verbose (and Maven annoyingly chose to do things like
<quiet>true</quiet> instead of a quiet="true" attribute). I wonder if there's a
Maven plugin that allows you to specify your pom.xml in YAML or some less
verbose format and which automatically converts it to XML. That'd probably cut
the line count by 2/3.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2853 6335cc39-0255-0410-8fd6-9bcaacd3b74c
standard Maven layout.
I'm not a huge fan of that separation, particularly now that it's de rigueur to
ship your sources with your class files. In such circumstances, one could
imagine just copying the entire contents of src/main/java into target/classes
and being done with it. Class files, XML files, propert files, etc. are all
packaged up together into one happy jar file of goodness. Then you don't have
extra files off in src/main/resources being demure and hard to notice.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2849 6335cc39-0255-0410-8fd6-9bcaacd3b74c
our tests pass even when we haven't run them before. We were relying on
sub.sub3 having been set and persisted from a previous test invocation.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2848 6335cc39-0255-0410-8fd6-9bcaacd3b74c
publish our bits to the Maven central repository, which means we need to gird
our loins and wade into the ninth circle of hell: a Mavenized build.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2847 6335cc39-0255-0410-8fd6-9bcaacd3b74c
these differ from the "standard definitions", but I'm going to stick with my
usual approach of assuming that everyone else is crazy.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2834 6335cc39-0255-0410-8fd6-9bcaacd3b74c
ray.j.greenwell