Also, shading the embedder to hide the jdom classes, and adjusting the assembly appropriately.
Final thing: I'm rolling back some changes I accidentally made to the CLIManager the other day, which breaks the release plugin because the long options were removed for some reason (save action in Eclipse; don't ask).
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@585012 13f79535-47bb-0310-9956-ffa450edef68
so tough noogies for people still trying to use Maven 1.x repositories with Maven 2.x.
The next series of refactoring I will be doing with GIT.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@580609 13f79535-47bb-0310-9956-ffa450edef68
directly. eventually i will get it to be the session, along with the profile tools, then all the tools can also
share a common interpolator, which can then be shared by other components instead of having 5 interpolators lying
around causing a great deal of inconsistency.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573494 13f79535-47bb-0310-9956-ffa450edef68
while i transform the settings components to take a MavenSession. Any component executing within Maven should be able to use
a session. the session will contain everything required and any new component added to the system should only take the
session as a parameter. same pattern for all components. that's the goal. it will take a few hops.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573462 13f79535-47bb-0310-9956-ffa450edef68
here i am just collecting all the profile code into one place as it's scattered over several packages and is
hard to determine what the profile system as a whole is doing. the first task i would like to do is decouple
the profile system from the Settings. this can be done at the front-end i.e the profile information from Settings
can be fed into the profile manager up front.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573325 13f79535-47bb-0310-9956-ffa450edef68
o removing dead code
o examining how plugin version resolution is done, and we have a mix of a desire to use snapshots locally and pull releases
remotely. if the repositories are mixed a snapshot will be pull automagically. this doesn't happen in practice but snapshots
for plugin versions should be limited to a local search only.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@572872 13f79535-47bb-0310-9956-ffa450edef68
partially being use and we problems being emitted with messages like:
NOTE: One or more purely derived expression elements were detected in this expression.
If you continue to get this error after any other expression elements are specified correctly
please report this issue to the Maven development team.
I think we have to make a very concerted effort to make useful messages because I'm tired of standing behind Maven
users and being embarrassed when they look at me and ask "what does that mean?". "i actually have no idea."
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@572456 13f79535-47bb-0310-9956-ffa450edef68
MNG-3183
First cleanup of the logging code (it is still a mess), but all the console logging has been removed from the Maven component and pushed back
into the CLI code. As a result we now have a way to log to a file easily.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@572408 13f79535-47bb-0310-9956-ffa450edef68
in the readProjectWithDependencies method because it is not being done in the core unless projects are executed. So Milos' assertion
is correct. I'm now looking at a layered approach for project resolution and then execution so that the readProjectWithDependencies
(which is essential for IDE integration) will yield something that can be pushed into the lifecycle executor. Right now there
is much duplication which makes the IDE integration crappy.
Another result of this is trying to create a simple IDE import model that gives back client code the fully resolved, topo sorted
set of projects which point to binary dependencies outside the reactor, and to source folders inside the reactor. The result will
be a useful model for all IDE integration, right now everyone is doing their own thing. This model will need hooks for customization
to take into account turning "workspace resolution" on/off and allow easy overriding of this process.
o Fixed IT0035
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@572366 13f79535-47bb-0310-9956-ffa450edef68
to execute the lifecycle. Trying to do this validation shows in detail how tangled some of our code is as I need
to create the dispatcher in order to create the session which is required to make the reactorManager which
is required to get the project required to validate the goal name ... yah.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@572214 13f79535-47bb-0310-9956-ffa450edef68
Jason van Zyl
Carlos Sanchez Gonzalez
John Dennis Casey
Herve Boutemy
Brett Leslie Porter