o get rid of the tycho profile, eugene has made his own eclipse plugin thingy and doesn't need the felix plugin which doesn't work properly or half-ass attempt at making a manifest
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@587571 13f79535-47bb-0310-9956-ffa450edef68
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
o the populator now has a clear populate() that shows how the request is being constructed, there should be nothing beyond the embedder now
the does any of this configuration and loading and it should remain this way. no processing of settings or profiles deep in the bowels
of Maven is all happens in the populator.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573783 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
o the profiles additions from settings are now process in the request populator and taken out of the default profile manager itself which has resulted in decoupling the Settings from the profile manager.
git-svn-id: https://svn.apache.org/repos/asf/maven/components/trunk@573435 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
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
Carlos Sanchez Gonzalez
Jason van Zyl
Herve Boutemy
John Dennis Casey
Brett Leslie Porter