doesn't just indicate leniency in the face of conflict. Jesus fucking christ.
Anyhow, we can't cope with velocity-1.7.1-beta, so we have to provide a "soft"
recommendation for velocity-1.6.4.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2967 6335cc39-0255-0410-8fd6-9bcaacd3b74c
dependencies. This will ensure that Maven does not erroneously omit a newer
dependency of some other library because we happen to specify an older version.
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2966 6335cc39-0255-0410-8fd6-9bcaacd3b74c
version numbers and then puzzle over why things don't work when we try to use
new plugin features and forget to check what version number said feature was
introduced into the plugin and be sure that we're using that version. Yay!
git-svn-id: https://samskivert.googlecode.com/svn/trunk@2925 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
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
Ray J. Greenwell