Logo Search packages:      
Sourcecode: maven2 version File versions  Download package

Todo List

Member org::apache::maven::artifact::metadata::ArtifactMetadata::merge (ArtifactMetadata metadata)
this should only be needed on the repository metadata

Member org::apache::maven::artifact::metadata::ArtifactMetadata::storeInLocalRepository (ArtifactRepository localRepository, ArtifactRepository remoteRepository)
this should only be needed on the repository metadata

Class org::apache::maven::artifact::transform::AbstractVersionTransformation
try and refactor to remove abstract methods - not particular happy about current design

Class org::apache::maven::project::artifact::ActiveProjectArtifact
I think this exposes a design flaw in that the immutable and mutable parts of an artifact are in one class and should be split. ie scope, file, etc depend on the context of use, whereas everything else is immutable.

Class org::apache::maven::artifact::Artifact
do we really need an interface here?

Class org::apache::maven::artifact::Artifact
get rid of the multiple states we can have (project, parent, etc artifacts, file == null, snapshot, etc) - construct subclasses and use accordingly?

Member org::apache::maven::artifact::Artifact::setArtifactHandler (ArtifactHandler handler)
remove, a quick hack for the lifecycle executor

Member org::apache::maven::artifact::Artifact::setBaseVersion (String baseVersion)
would like to get rid of this - or at least only have one. Base version should be immutable.

Class org::apache::maven::artifact::metadata::ArtifactMetadata
merge with artifactmetadatasource

Class org::apache::maven::artifact::metadata::ArtifactMetadata
retrieval exception not appropriate for store

Class org::apache::maven::artifact::resolver::ArtifactResolver
possibly fix the signatures, it's unfortunate that in some methods the local repo is listed first and second in others.

Class org::apache::maven::script::beanshell::BeanshellMojoAdapter
should log be passed in, or rely on getLog() ?

Class org::apache::maven::project::overlay::BuildOverlay
why delegate? this is asking for trouble when there are additions.

Class org::apache::maven::artifact::DefaultArtifact
this should possibly be replaced by type handler

Member org::apache::maven::artifact::DefaultArtifact::baseVersion
should be final

Class org::apache::maven::lifecycle::DefaultLifecycleExecutor
because of aggregation, we ended up with cli-ish stuff in here (like line() and the project logging, without much of the event handling)

Member org::apache::maven::lifecycle::DefaultLifecycleExecutor::findArtifactTypeHandlers (MavenProject project, Settings settings, ArtifactRepository localRepository)
Not particularly happy about this. Would like WagonManager and ArtifactTypeHandlerManager to be able to lookup directly, or have them passed in

Member org::apache::maven::DefaultMaven::resolveParameters (Settings settings)
[BP] this might not be required if there is a better way to pass them in. It doesn't feel quite right.

Member org::apache::maven::DefaultMaven::resolveParameters (Settings settings)
[JC] we should at least provide a mapping of protocol-to-proxy for the wagons, shouldn't we?

Member org::apache::maven::execution::DefaultMavenExecutionRequest::localRepository
[BP] is this required? This hands off to MavenSession, but could be passed through the handler.handle function (+ createSession).

Member org::apache::maven::project::DefaultMavenProjectBuilder::assembleLineage (Model model, LinkedList lineage, ArtifactRepository localRepository, File projectDir, List parentSearchRepositories, Set aggregatedRemoteWagonRepositories, ProfileManager externalProfileManager, boolean strict)
We need to find an effective way to unit test parts of this method!

Member org::apache::maven::project::DefaultMavenProjectBuilder::assembleLineage (Model model, LinkedList lineage, ArtifactRepository localRepository, File projectDir, List parentSearchRepositories, Set aggregatedRemoteWagonRepositories, ProfileManager externalProfileManager, boolean strict)
Refactor this into smaller methods with discrete purposes.

Member org::apache::maven::project::DefaultMavenProjectBuilder::buildWithDependencies (File projectDescriptor, ArtifactRepository localRepository, ProfileManager profileManager, TransferListener transferListener)
move to metadatasource itself?

Member org::apache::maven::project::DefaultMavenProjectBuilder::processProjectLogic (String pomLocation, MavenProject project, ProfileManager profileMgr, File projectDir, boolean strict)
can this take in a model instead of a project and still be successful?

Member org::apache::maven::project::DefaultMavenProjectBuilder::processProjectLogic (String pomLocation, MavenProject project, ProfileManager profileMgr, File projectDir, boolean strict)
In fact, does project REALLY need a MavenProject as a parent? Couldn't it have just a wrapper around a model that supported parents which were also the wrapper so that inheritence was assembled. We don't really need the resolved source roots, etc for the parent - that occurs for the parent when it is constructed independently and projects are not cached or reused

Class org::apache::maven::project::inheritance::DefaultModelInheritanceAssembler
generate this with modello to keep it in sync with changes in the model.

Class org::apache::maven::artifact::DependencyResolutionRequiredException
it may be better for artifact.getFile() to throw it - perhaps it is a runtime exception?

Class org::apache::maven::artifact::resolver::filter::ExcludesArtifactFilter
I think this is equiv. to exclusion set filter in maven-core

Class org::apache::maven::MavenArtifactFilterManager
this should probably be a component with some dynamic control of filtering

Member org::apache::maven::project::artifact::MavenMetadataSource::createArtifacts (ArtifactFactory artifactFactory, List dependencies, String inheritedScope, ArtifactFilter dependencyFilter, MavenProject project)
desperately needs refactoring. It's just here because it's implementation is maven-project specific

Member org::apache::maven::project::MavenProject::createArtifacts (ArtifactFactory artifactFactory, String inheritedScope, ArtifactFilter dependencyFilter)
the lazy initialisation of this makes me uneasy.

Class org::apache::maven::plugin::descriptor::MojoDescriptor
is there a need for the delegation of MavenMojoDescriptor to this? Why not just extend ComponentDescriptor here?

Member org::apache::maven::plugin::descriptor::PluginDescriptor::getGoalPrefixFromArtifactId (String artifactId)
move to plugin-tools-api as a default only

Class org::apache::maven::plugin::PluginParameterExpressionEvaluator
belong in MavenSession, so it only gets created once?

Class org::apache::maven::project::ProjectClasspathTest
relocate to maven-artifact in entirety

Class org::apache::maven::project::interpolation::RegexBasedModelInterpolator
Consolidate this logic with the PluginParameterExpressionEvaluator, minus deprecations/bans.

Class org::apache::maven::artifact::repository::metadata::RepositoryMetadata
not happy about the store method - they use "this"

Class org::apache::maven::artifact::repository::metadata::SnapshotArtifactRepositoryMetadata
split instantiation (versioning, plugin mappings) from definition

Generated by  Doxygen 1.6.0   Back to index