Download JAR files tagged by avoid with all dependencies

[] (https://drone.io/bitbucket.org/tidalwave/thesefoolishthings-superpom-src/latest) A feature-rich SuperPOM for building Java projects. It features: * explicit version configuration for a number of plugins; * easy configurability by means of pre-defined properties to avoid cut & copy of plugin sections. A number of profiles, that can be easily activated, are available for: * Spring-AOP configuration; * different kinds of Continuous Integration tasks, including a full run of QA tools such as JaCoCo, FindBugs, PMD, etc... * deploying WARs and locally running them with Tomcat or Jetty; * creating a Mac OS X bundle for JavaFX applications; * creating .deb packages for both application and services; * a customized release cycle, including all requirements for the Maven Central such as signing, with a 'transactional' behaviour (all artifacts, both the DSCM and the Maven artifacts are prepared on the local disk, so they can be uploaded in a second moment); Remember to customise it ------------------------ If you use it, please remember to change the ```description```,```url```, ```organization```, ```developers```, ```license```, etc... to override those related to the development of this POM.

Performs a grid search of parameter pairs for the a classifier (Y-axis, default is LinearRegression with the "Ridge" parameter) and the PLSFilter (X-axis, "# of Components") and chooses the best pair found for the actual predicting. The initial grid is worked on with 2-fold CV to determine the values of the parameter pairs for the selected type of evaluation (e.g., accuracy). The best point in the grid is then taken and a 10-fold CV is performed with the adjacent parameter pairs. If a better pair is found, then this will act as new center and another 10-fold CV will be performed (kind of hill-climbing). This process is repeated until no better pair is found or the best pair is on the border of the grid. In case the best pair is on the border, one can let GridSearch automatically extend the grid and continue the search. Check out the properties 'gridIsExtendable' (option '-extend-grid') and 'maxGridExtensions' (option '-max-grid-extensions <num>'). GridSearch can handle doubles, integers (values are just cast to int) and booleans (0 is false, otherwise true). float, char and long are supported as well. The best filter/classifier setup can be accessed after the buildClassifier call via the getBestFilter/getBestClassifier methods. Note on the implementation: after the data has been passed through the filter, a default NumericCleaner filter is applied to the data in order to avoid numbers that are getting too small and might produce NaNs in other schemes.

This is the main aggregator for all gwt submodules. All gwt-specific code resides here. Submodules should avoid inheriting from each other unless necessary. This goes for maven structure and gwt.xml structure. The super module is where our jre emulation layer and super-source live; all modules should inherit super, and a minimum of other modules. Some modules, like injection, are fulfilling an api in the core module, and should be accessed only through core service interfaces. Other modules, like reflection, are capable of being standalone inherits, but can benefit from core utilities like injection, so, two (or more) .gwt.xml modules may be provided. As XApi nears 1.0, all submodules will be routinely stitched together into an uber-jar, in order to have a single jar with a single gwt module that can provide all of the services at once. Internal projects will never use the uber jar, to help maintain modularity, but external projects that want to use more than one service will certainly prefer inheriting one artifact, instead of twelve. When distributed in uber-jar format, it will likely be necessary for either the uber jar, or just xapi-gwt-api.jar to appear before gwt-dev on your compile-time classpath. If using gwt-maven-plugin, the gwtFirstOnClasspath option may become problematic. If so, we will provide a forked gwt-plugin to make sure our compiler enhancements are included in the build process. There is also work going on to make a super-source-everything plugin, which will use maven to find source files, and generate synthetic .gwt.xml for you, as part of an effort to create a wholly unified programming environment. In addition to java-to-javascript, we intend to compile java-to-java and possibly other languages, like go; imagine implementing gwt deferred binding to eliminate cross-platform differences between server environments, or operating systems, or versions of a platform, or anywhere else a core api needs to bind to multiple implementations, depending on the runtime environment.