The following document contains the listing of user tags found in the code. Below is the summary of the occurrences per tag.
| Tag | Total number of occurrences |
|---|---|
| @todo | 8 |
| TODO | 53 |
Each tag is detailed below:
Number of occurrences found in the code: 8
| org.apache.maven.DefaultMaven | Line |
|---|---|
| [BP] this might not be required if there is a better way to pass them in. It doesn't feel quite right. | 647 |
| [JC] we should at least provide a mapping of protocol-to-proxy for the wagons, shouldn't we? | 649 |
| org.apache.maven.MavenArtifactFilterManager | Line |
| this should probably be a component with some dynamic control of filtering | 31 |
| org.apache.maven.execution.DefaultMavenExecutionRequest | Line |
| [BP] is this required? This hands off to MavenSession, but could be passed through the handler.handle function (+ createSession). | 40 |
| org.apache.maven.lifecycle.DefaultLifecycleExecutor | Line |
| because of aggregation, we ended up with cli-ish stuff in here (like line() and the project logging, without much of the event handling) | 79 |
| Not particularly happy about this. Would like WagonManager and ArtifactTypeHandlerManager to be able to lookup directly, or have them passed in | 1184 |
| org.apache.maven.plugin.DefaultPluginManager | Line |
| would be better to store this in the plugin descriptor, but then it won't be available to the version manager which executes before the plugin is instantiated | 253 |
| org.apache.maven.plugin.PluginParameterExpressionEvaluator | Line |
| belong in MavenSession, so it only gets created once? | 40 |
Number of occurrences found in the code: 53
| org.apache.maven.DefaultMaven | Line |
|---|---|
| should all the logging be left to the CLI? | 173 |
| Really should fail if it was not? What if it is aggregating - eg "ear"? | 523 |
| should we now include the pom.xml in the current directory? String includes = System.getProperty( "maven.reactor.includes", "**/" + POMv4 ); String excludes = System.getProperty( "maven.reactor.excludes", POMv4 ); | 928 |
| org.apache.maven.MavenArtifactFilterManager | Line |
| configure this from bootstrap or scan lib | 60 |
| org.apache.maven.cli.AbstractConsoleDownloadMonitor | Line |
| can't use getLogger() because this isn't currently instantiated as a component | 45 |
| can't use getLogger() because this isn't currently instantiated as a component getLogger().debug( message ); | 86 |
| org.apache.maven.cli.BatchModeDownloadMonitor | Line |
| can't use getLogger() because this isn't currently instantiated as a component | 39 |
| org.apache.maven.cli.CLIManager | Line |
| introducing a space here...not sure what else to do but collapse whitespace | 229 |
| org.apache.maven.cli.ConsoleDownloadMonitor | Line |
| can't use getLogger() because this isn't currently instantiated as a component | 42 |
| [BP]: Sys.out may no longer be appropriate, but will \r work with getLogger()? | 57 |
| org.apache.maven.cli.MavenCli | Line |
| we need to do some more work here. Some plugins use sys out or log errors at info level. Ideally, we could use Warn across the board | 221 |
| Additionally, we can't change the mojo level because the component key includes the version and it isn't known ahead of time. This seems worth changing. | 224 |
| [BP]: do we set one per mojo? where to do it? | 425 |
| [BP]: doing this here as it is CLI specific, though it doesn't feel like the right place (likewise logger). | 469 |
| release | 489 |
| something in plexus to show all active hooks? | 490 |
| org.apache.maven.execution.MavenSession | Line |
| make this the central one, get rid of build settings... | 49 |
| org.apache.maven.extension.DefaultExtensionManager | Line |
| this could surely be simpler/different on trunk with the new classworlds | 183 |
| org.apache.maven.lifecycle.DefaultLifecycleExecutor | Line |
| This is dangerous, particularly when it's just a collection of loose-leaf projects being built within the same reactor (using an inclusion pattern to gather them up)... | 116 |
| probably don't want to do all this up front | 139 |
| shouldn't hit this, investigate using the same resolution logic as otheres for plugins in the reactor | 410 |
| check ID is correct for reports if the POM configured no reports, give all from plugin | 701 |
| this is all kind of backwards from the POMM. Let's align it all under 2.1. We should create a new lifecycle executor for modelVersion >5.0.0 | 899 |
| if moved to the plugin manager we already have the descriptor from above and so do can lookup the container directly | 1164 |
| if moved to the plugin manager we already have the descriptor from above and so do can lookup the container directly | 1199 |
| org.apache.maven.plugin.DefaultPluginManager | Line |
| since this is only used in the lifecycle executor, maybe it should be moved there? There is no other use for the mapping manager in here | 152 |
| this should be possibly outside All version-resolution logic has been moved to DefaultPluginVersionManager. | 167 |
| this might result in an artifact "RELEASE" being resolved continuously FIXME: need to find out how a plugin gets marked as 'installed' and no ChildContainer exists. The check for that below fixes the 'Can't find plexus container for plugin: xxx' error. | 185 |
| Should we error out, or simply warn and skip?? | 386 |
| the mojoDescriptor should actually capture this information so we don't get this far | 615 |
| plexus changes to make this more like the component descriptor so this can be used instead PlexusConfiguration mergedConfiguration = mergeConfiguration( pomConfiguration, mojoDescriptor.getConfiguration() ); | 650 |
| I defy anyone to find these messages in the '-X' output! Do we need a new log level? ideally, this would be elevated above the true debug output, but below the default INFO level... [BP] (2004-07-18): need to understand the context more but would prefer this could be either WARN or removed - shouldn't need DEBUG to diagnose a problem most of the time. | 961 |
| this should be built in to the configurator, as we presently double process the expressions | 978 |
| Is this the right thing to do? | 1126 |
| recessive seems to be dominant here? | 1206 |
| shouldn't be necessary | 1233 |
| could the configuration be passed to lookup and the configurator known to plexus via the descriptor so that this meethod could entirely be handled by a plexus lookup? | 1270 |
| such a call in MavenMetadataSource too - packaging not really the intention of type | 1403 |
| we don't need to resolve over and over again, as long as we are sure that the parameters are the same check this with yourkit as a hot spot. Don't recreate if already created - for effeciency, and because clover plugin adds to it | 1407 |
| the packaging could be different, but the exception doesn't contain that info most likely it would be produced by the project we just found in the reactor since all the other info matches. Assume it's ok. | 1468 |
| org.apache.maven.plugin.DefaultPluginMappingManager | Line |
| use constant | 71 |
| org.apache.maven.plugin.MavenPluginCollector | Line |
| see comment in getPluginDescriptor | 57 |
| throw an (not runtime) exception if there is a prefix overlap - means doing so elsewhere we also need to deal with multiple versions somehow - currently, first wins | 66 |
| include version, but can't do this in the plugin manager as it is not resolved to the right version at that point. Instead, move the duplication check to the artifact container, or store it locally based on the unresolved version? | 78 |
| see comment in getPluginDescriptor | 86 |
| org.apache.maven.plugin.PluginParameterExpressionEvaluator | Line |
| don't catch exception | 219 |
| don't catch exception | 245 |
| don't catch exception | 273 |
| without #, this could just be an evaluate call... | 317 |
| org.apache.maven.plugin.PluginParameterExpressionEvaluatorTest | Line |
| used to be SCOPE_COMPILE, check | 295 |
| org.apache.maven.plugin.version.DefaultPluginVersionManager | Line |
| [jc] Revisit to remove this piece of state. PLUGIN REGISTRY MAY BE UPDATED ON DISK OUT-OF-PROCESS! | 77 |
| Revisit to remove this piece of state. PLUGIN REGISTRY MAY BE UPDATED ON DISK OUT-OF-PROCESS! | 84 |
| check the GUI-friendliness of this approach to collecting input. If we can't port this prompt into a GUI, IDE-integration will not work well. | 392 |
