mirror of https://github.com/apache/maven.git
b813c3d430
Added specified stop-gap patch for issue: MNG-473 (affects settings-builder and registry-builder) Today I've made the following progress on this so far: - Added a new project, called maven-plugin-registry, to house the model for this new file. - Developed/debugged/tested PluginVersionManager/DefaultPluginVersionManager to isolate the plugin-version checks/management code away from the PluginManager - Added interactiveMode (<interactiveMode>true|false</interactiveMode> directly under the root element of settings.xml, or -B short CLI option or --batch-mode CLI option, where the CLI options turn OFF interactiveMode). This will allow things like the maven-plugins build to register new plugins (and, for now, new versions of plugins) automatically. - Added user input handler for when interactiveMode = true, to get a yes/no on whether to use the discovered version over the installed version and/or no version at all. If there is no installed version, and the user selects 'n', then the discovered version is used FOR THAT SESSION ONLY, and won't be recorded in the registry. - Added checks/recording rejected versions against the registry, before attempting to use the discovered version. Pending: - Still need to add update-policies, to determine two things: 1. how often to check for updates 2. what to do when updates are found (autoUpdate, etc.) git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@190854 13f79535-47bb-0310-9956-ffa450edef68 |
||
---|---|---|
.. | ||
it0000 | ||
it0001 | ||
it0002 | ||
it0003 | ||
it0004 | ||
it0005 | ||
it0006 | ||
it0007 | ||
it0008 | ||
it0009 | ||
it0010 | ||
it0011 | ||
it0012 | ||
it0013 | ||
it0014 | ||
it0015 | ||
it0016 | ||
it0017 | ||
it0018 | ||
it0019 | ||
it0020 | ||
it0021 | ||
it0022 | ||
it0023 | ||
it0024 | ||
it0025 | ||
it0026 | ||
it1000 | ||
it1001 | ||
it1002 | ||
it1003 | ||
it1004 | ||
it1005 | ||
README.txt | ||
integration-tests.txt | ||
maven-core-it.bat | ||
maven-core-it.sh |
README.txt
------------------------------------------------------------------------------- it0000: The simplest of builds. We have one application class and one test class. There are no resources, no source generation, no resource generation and a the super model is employed to provide the build information. it0001: Builds upon it0000: we add an application resource that is packaged up in the resultant JAR. it0002: Builds upon it0001: we add the download of a dependency. We delete the JAR from the local repository and make sure it is there post build. it0003: Builds upon it0001: we add a jar installation step. We delete the JAR from the local repository to make sure it is there post build. it0004: The simplest of pom installation. We have a pom and we install it in local repository. it0005: The simplest of pom installation. We have a snapshot pom and we install it in local repository. it0006: Integration test for the verifier plugin. it0007: We specify a parent in the POM and make sure that it is downloaded as part of the process. it0008: Simple goal decoration where a plugin binds to a phase and the plugin must be downloaded from a remote repository before it can be executed. This test also checks to make sure that mojo parameters are aligned to the project basedir when their type is "java.io.File". it0009: Test plugin configuration and goal configuration that overrides what the mojo has specified. it0010: Since the artifact resolution does not use the project builder, we must ensure that the full hierarchy of all dependencies is resolved. This includes the dependencies of the parent-pom's of dependencies. This test will check this, by depending on classworlds, which is a dependency of maven-component, which is the parent of maven-plugin, which is an explicit dependency of this test. # TODO: must correct the assumptions of this test it0011: Test specification of dependency versions via <dependencyManagement/>. it0012: Test simple POM interpolation it0013: Test plugin-plugin, which tests maven-plugin-tools-api and maven-plugin-tools-java. This will generate a plugin descriptor from java-based mojo sources, install the plugin, and then use it. it0014: Test POM configuration by settings the -source and -target for the compiler to 1.4 it0015: Test marmalade-driven mojo support. This will compile supporting java classes (mmld tag & taglib), generate plugin descriptor from mmld script, install the plugin, and finally use the new plugin. it0016: Test a WAR generation it0017: Test an EJB generation it0018: Ensure that managed dependencies for dependency POMs are calculated correctly when resolved. Removes commons-logging-1.0.3 and checks it is redownloaded. it0019: Test that a version is managed by pluginManagement in the super POM it0020: Test beanshell mojo support. it0021: Test pom-level profile inclusion (this one is activated by system property). it0022: Test profile inclusion from profiles.xml (this one is activated by system property). it0023: Test profile inclusion from settings.xml (this one is activated by an id in the activeProfiles section). it0024: Test usage of <executions/> inside a plugin rather than <goals/> that are directly inside th plugin. it0025: Test multiple goal executions with different execution-level configs. it0026: Test merging of global- and user-level settings.xml files. ------------------------------------------------------------------------------- ============================== NOTE: About it0023 and it0026 ============================== I am disabling these for now, because they depend on locally-supplied settings files, and need to know the location of the local repository where the plugin builds were deposited in order to work. This is why they will result in ArtifactResolutionException's...they literally cannot find the plugins in the local repository, because they wind up using the default local repository. ============================= - generated sources - generated resources from sources - generated resources from generated sources - filtered resources - build that requires a plugin download - transitive dependencies - goal attainment not requiring depedency resolution - goal attainment where a POM is not required: this is a case where we are using mgen to create new applications and project structures which is used by the m2 geronimo plugin and tools like the "setup" goal which brings a project to life from scratch using something like: m2 --setup xstream --version 1.0 - write a small program to generate a massively nested build which which use the reactor and inheritence. we need to have integration tests that go far beyond what the average user would ever setup. - project with a cyclic dependency ------------------------------------------------------------------------------- These are a set of builds that contain known errors. The errors should be captured and reported in a useful manner to the user. We will start at it1000 for intentially flawed builds. ------------------------------------------------------------------------------- it1000: A build which contains a malformed pom.xml. We have intentionally created a mismatch in the first element. We have: <projectX>...</project> ------------------------------------------------------------------------------- it1001: A build whose pom.xml does not contain a <groupId/> element. ------------------------------------------------------------------------------- it1002: A build with a syntax error in the first field declaration. ------------------------------------------------------------------------------- it1003: A build with a simple test failure. ------------------------------------------------------------------------------- - checksum mismatch ------------------------------------------------------------------------------- it1005: A build with two mojo java sources that declare the same goal. -------------------------------------------------------------------------------