for better alignment with JSE, [lang], etc. Currently IllegalArgumentException is thrown.
hmm, that was actually supposed to be org.apache.commons.functor._lang3.__Validate
Yes; I would imagine that the IDEs would be fine to import if a user actually tried referencing the classes by these (albeit lightly) obfuscated names, but why would the user do this? We've accomplished the goal of protecting the user from accidentally importing these. It might be nice to make the relocator pluggable for the shade plugin, to make this easier, but I think at Commons we've gone long enough reinventing the wheel in every component just to avoid dependencies. Jar shading gives us the best of both worlds.
Committed revision 1234990.
nice to hear the trick worked! The nicer thing is IMHO that names are still valid Java identifier parts, but not all IDEs are good on recognizing them
Standard Eclipse, for example, doesn't resolve the Guice shaded internals, while Sonatype's MavenIDE (an Eclipse mod) does.
Thanks for the hint, Simo! Naming e.g. org.apache.commons.lang3.Validate to org.apache.commons.functor.lang3._Validate and confirmed that the resulting jar is fully functional.
We could shade the Validate class by renaming it in a way some IDEs (i.e. Eclipse) is not able to resolve; Google Guice's folks use to do it by shading the classes with $ as first class name char, it would look like: org.apache.commons.lang.$Validate
I tend to think that convenience for the end user is more important than convenience for the developer. In this case the code saved by the Validate class is marginal, I would rather code the null check manually.
Technically, yes, but should we avoid an available convenience in cases like this?
Doesn't this create a risk that people will use the Validate class shaded into [functor]? Auto import in modern IDEs is not always smart
using lang3 Validate.notNull + maven-shade-plugin