All Downloads are FREE. Search and download functionalities are using the official Maven repository.

Download JAR files tagged by avoid with all dependencies

Search JAR files by class name

dkpro-lab-core from group de.tudarmstadt.ukp.dkpro.lab (version 0.11.0)

Group: de.tudarmstadt.ukp.dkpro.lab Artifact: dkpro-lab-core
Show documentation Show source 
 

2 downloads
Artifact dkpro-lab-core
Group de.tudarmstadt.ukp.dkpro.lab
Version 0.11.0
Last update 18. June 2014
Organization not specified
URL Not specified
License not specified
Dependencies amount 18
Dependencies commons-math, commons-io, commons-lang, spring-core, spring-context, spring-expression, spring-tx, jug, jfreechart, opencsv, poi, batik-svggen, batik-dom, batik-gvt, fop, avalon-framework-impl, jsr311-api, ant,
There are maybe transitive dependencies!

dkpro-lab from group de.tudarmstadt.ukp.dkpro.lab (version 0.11.0)

DKPro Lab is a lightweight framework for parameter sweeping experiments. It allows to set up experiments consisting of multiple interdependent tasks in a declarative manner with minimal overhead. Parameters are injected into tasks using via annotated class fields. Data produced by a task for any particular parameter configuration is stored and re-used whenever possible to avoid the needless recalculation of results. Reports can be attached to each task to post-process the experimental results and present them in a convenient manner, e.g. as tables or charts.

Group: de.tudarmstadt.ukp.dkpro.lab Artifact: dkpro-lab
There is no JAR file uploaded. A download is not possible! Please choose another version.
0 downloads
Artifact dkpro-lab
Group de.tudarmstadt.ukp.dkpro.lab
Version 0.11.0
Last update 18. June 2014
Organization not specified
URL http://code.google.com/p/dkpro-lab/
License The Apache Software License, Version 2.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!

shared-ldap-codec-standalone from group org.apache.directory.shared (version 1.0.0-M13)

This module was created to fix issue DIRSHARED-91 where the embedded Felix instance inside the default LdapCodecService implementation was making it very problematic to deploy the ldap-codec inside an RCP (OSGi) environment and hence Apache Directory Studio could not use it. This module is most likely temporary and will disappear once we are fully OSGi enabled. This module is a plain old jar, not a bundle to avoid accidental reuse as an OSGi module because it contains the version of the LdapCodecService that embeds Felix to make controls and extended ops pluggable in the codec.

Group: org.apache.directory.shared Artifact: shared-ldap-codec-standalone
Show all versions Show documentation Show source 
 

0 downloads
Artifact shared-ldap-codec-standalone
Group org.apache.directory.shared
Version 1.0.0-M13
Last update 08. October 2012
Organization not specified
URL Not specified
License not specified
Dependencies amount 3
Dependencies shared-ldap-net-mina, shared-ldap-codec-core, mina-core,
There are maybe transitive dependencies!

rupy from group com.google.code.p (version 0.2.4)

Weighing less than 50KB, Rupy is probably the smallest Java NIO application server in the world. Rupy is inherently non-blocking asynchronous, which makes it the ideal candidate for high concurrency real-time applications pushing dynamic data. Tested with acme, rupy performs on average ~1500 requests per second. To put that figure in perspective; acme doesn't use keep-alive, so that means 1500 unique TCP connections serving dynamic content per second! Thanks to NIO and an event queue to avoid selector trashing, this figure degrades gracefully under high concurrency.

Group: com.google.code.p Artifact: rupy
Show documentation Show source 
 

0 downloads
Artifact rupy
Group com.google.code.p
Version 0.2.4
Last update 27. September 2008
Organization not specified
URL http://code.google.com/p/rupy/
License GNU Lesser General Public License
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!

data-distribution-api-vivo_1_08 from group edu.cornell.library.scholars (version 1.1.1)

--------------------------------------------------------------------------- Version for VIVO 1.8 This uses the source and test code from the Version for VIVO 1.10, edited to make it compatible with VIVO 1.8. It also borrows some code from VIVO 1.10 itself, changes the package name to avoid conflicts, and adds it here. * Vitro 1.8 uses Jena 2, not Jena 3, and Commons Lang 2, not 3, so modify the "import" statements in the Data Distribution code accordingly. * Vitro 1.8 does not have a "...webapp.utils.sparqlrunner" package, so borrow the source from Vitro 1.10, move it to a different package (just for compatibility with the 1.9 version), modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this sparqlrunner package. * Vitro 1.9 has an earlier version of "...webapp.utils.configuration" package, so borrow the source from Vitro 1.10, move it to a different package so it won't conflict with the 1.9 version, modify it to use Jena 2 and Commons Lang 2, and modify the Data Distribution API code to use this configuration package. Make these modifications, compile, JAR it up, and deploy. --------------------------------------------------------------------------- Because VIVO 1.8 is not available as a Maven package, we have extracted the class files, JARed them up, and stored them in a file-based repository within this project. But that doesn't include any transitive dependencies, so any package that this code requires must be explicitly listed as a dependency. ---------------------------------------------------------------------------

Group: edu.cornell.library.scholars Artifact: data-distribution-api-vivo_1_08
Show all versions Show documentation Show source 
 

0 downloads
Artifact data-distribution-api-vivo_1_08
Group edu.cornell.library.scholars
Version 1.1.1
Last update 25. April 2018
Organization not specified
URL Not specified
License not specified
Dependencies amount 9
Dependencies vivo_classes, jena-core, jena-arq, commons-logging, commons-io, commons-lang, jackson-core, jackson-databind, jackson-annotations,
There are maybe transitive dependencies!

maven-glassfishbuild-extension from group org.glassfish.build (version 3.2.2)

GlassFish build depends on properly functioning several custom lifecycle mappings and artifact handlers. Because these are necessary to resolve dependencies and to run "gf:run" goal and etc., it is critical that these extensions be made available to Maven early on during Maven execution. This definition was originally in maven-glassfish-plugin, which was integrated into Maven POM through <plugin>/<extensions>true marking, but after a series of debugging to resolve artifact resolution failure problems, it turns out that that doesn't cause Maven to load components early enough. I tried to circumbent the prolem by also registering the maven-glassfish-plugin as an extension module (via <build>/<extensions/<extension>), but that apparently confuses Maven to no end --- I get build errors like this: [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin' This is obviously one of the problematic areas of Maven, so to avoid doing hack over hack, I'm simply moving the component definitions to its own module.

Group: org.glassfish.build Artifact: maven-glassfishbuild-extension
Show all versions Show documentation Show source 
 

0 downloads
Artifact maven-glassfishbuild-extension
Group org.glassfish.build
Version 3.2.2
Last update 14. September 2011
Organization not specified
URL Not specified
License not specified
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!

maven-glassfish-extension from group org.glassfish.build (version 10.0-alpha-4)

GlassFish build depends on properly functioning several custom lifecycle mappings and artifact handlers. Because these are necessary to resolve dependencies and to run "gf:run" goal and etc., it is critical that these extensions be made available to Maven early on during Maven execution. This definition was originally in maven-glassfish-plugin, which was integrated into Maven POM through <plugin>/<extensions>true marking, but after a series of debugging to resolve artifact resolution failure problems, it turns out that that doesn't cause Maven to load components early enough. I tried to circumbent the prolem by also registering the maven-glassfish-plugin as an extension module (via <build>/<extensions/<extension>), but that apparently confuses Maven to no end --- I get build errors like this: [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar': Unable to find the mojo 'org.apache.maven.plugins:maven-jar-plugin:2.1:jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin' This is obviously one of the problematic areas of Maven, so to avoid doing hack over hack, I'm simply moving the component definitions to its own module.

Group: org.glassfish.build Artifact: maven-glassfish-extension
Show all versions Show source 
 

0 downloads
Artifact maven-glassfish-extension
Group org.glassfish.build
Version 10.0-alpha-4
Last update 30. April 2008
Organization not specified
URL Not specified
License not specified
Dependencies amount 1
Dependencies maven-core,
There are maybe transitive dependencies!

superpom from group it.tidalwave.thesefoolishthings (version 5.0-ALPHA-15)

[![Build Status](https://drone.io/bitbucket.org/tidalwave/thesefoolishthings-superpom-src/status.png)] (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.

Group: it.tidalwave.thesefoolishthings Artifact: superpom
Show all versions 
There is no JAR file uploaded. A download is not possible! Please choose another version.
0 downloads
Artifact superpom
Group it.tidalwave.thesefoolishthings
Version 5.0-ALPHA-15
Last update 19. December 2021
Organization Tidalwave s.a.s.
URL http://tidalwave.it
License Apache-2.0
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!

gridSearch from group nz.ac.waikato.cms.weka (version 1.0.12)

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.

Group: nz.ac.waikato.cms.weka Artifact: gridSearch
Show all versions Show documentation Show source 
 

1 downloads
Artifact gridSearch
Group nz.ac.waikato.cms.weka
Version 1.0.12
Last update 30. October 2018
Organization University of Waikato, Hamilton, NZ
URL http://weka.sourceforge.net/doc.packages/gridSearch
License GNU General Public License 3
Dependencies amount 2
Dependencies weka-dev, partialLeastSquares,
There are maybe transitive dependencies!

xapi-gwt-parent from group net.wetheinter (version 0.5)

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.

Group: net.wetheinter Artifact: xapi-gwt-parent
Show all versions 
There is no JAR file uploaded. A download is not possible! Please choose another version.
0 downloads
Artifact xapi-gwt-parent
Group net.wetheinter
Version 0.5
Last update 30. May 2015
Organization not specified
URL WeTheInter.net
License not specified
Dependencies amount 0
Dependencies No dependencies
There are maybe transitive dependencies!



Page 23 from 24 (items total 231)


© 2015 - 2021 Weber Informatics LLC