Hi Brian,
Thanks for adding that rule, I have incorporated into the best
practices guide for the client I'm working with and it stands
generally I believe as something any good build should do.
There are a couple things to note just so I convey the goal, and I
think the work that John is
Just looking at that enforcer again, that's crazy that you need all
those components in there to do again what Maven just already did
internally. You have to, and I'm not faulting you. You probably
learned more about the internals then you wanted to. We can't do
anything in 2.0.x but this
On 15 Aug 07, at 1:36 AM 15 Aug 07, Brett Porter wrote:
Yes, that's what I meant by supercede. Nobody would use the
downloader any more.
Yes, I understood that part. The part I wasn't clear about is that
Jan's facade makes it far easier for someone to use the functionality
of the
This was definitely a learning experience in some areas I hadn't
explored before. As I was going through all the lifecycle muck, I kept
thinking now I know why John redid this in 2.1. When I load the
DefaultLifecycleExecuter and view it in the debugger, lots of the info I
need is there, I just
This broke the build:
http://maven.zones.apache.org/continuum/buildResult.action?
buildId=14486projectId=380projectGroupId=2projectName=Maven
+Enforcer+Plugin
- Brett
On 15/08/2007, at 6:23 PM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Wed Aug 15 01:23:39 2007
New Revision: 566060
I just committed a fix in the mojo sandbox for the shade plugin:
instead of removing the dependencies, it marks them provided.
That should make sure all versions line up if a transitive
dep brings in a 'removed' artifact.
I'm not sure where the removal of provided scoped deps takes place;
Maven artifact is still in
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact
does it need to be deleted and change the references?
I also have some changes made in trunk, should I merge to the new location?
On 8/15/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 15 Aug 07,
Fixed.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 15, 2007 8:39 AM
To: dev@maven.apache.org
Subject: Re: svn commit: r566060 - in
/maven/plugins/trunk/maven-enforcer-plugin/src: it/pom.xml
One thing to note is that the build plan will be constructed _prior_
to any mojos executing, so modding that build plan implies you're
also getting in there ahead of the first mojo's
execution...otherwise, you don't have complete access to modify the
plan. This takes us out of the realm of
Hi,
I'd like to propose that for Maven trunk/2.1 we capture all plugin-
facing APIs and facades inside a single maven-api artifact. This
would enumerate in a very clear fashion the public APIs that we need
to support. We're approaching a turning point in Maven, where we'll
have plugins
Looks like it...this looks like the consequences of using public API
methods from within other public API methods within a class.
I'll look into it further.
-john
On Aug 14, 2007, at 10:57 PM, Brett Porter wrote:
John - is this your isSnapshot change?
On 15/08/2007, at 2:55 AM, [EMAIL
yah, it's a nuisance. I tried to fix this one before and got sick of
random things breaking and decided to wait for 2.1 :)
On 16/08/2007, at 12:44 AM, John Casey wrote:
Looks like it...this looks like the consequences of using public
API methods from within other public API methods within a
Hi John,
At this point I'm not even thinking about modifying the build plan. I
just need to get at the lifecycle and the plugins bound (I don't even
care about the execution info...I just need to find out which plugins so
I can make sure they are resolved (go-offline) or have locked down
versions
I'm definitely +1 on the idea.
I'm not sure whether aggregating them in one artifact makes sense
though (it sounds a bit like the embedder API too). It could be a
good way (in the interim) to start exposing safe functionality,
though I feel in the long term the public API of the individual
That would be really nice. The hardest part about writing mojos is
trying to figure out what you _can_ do and get access to. We'll probably
never be able to enumerate all the available components, but being able
to have a list of the standard ones would be handy. The
expressionEvaluator already
I suppose maven-artifact is a bad example here, since it's now
officially moving into its own structure in SVN. Perhaps a better one
would be the build planner/lifecycle APIs, or even the plugin-
resolution/management features. These aren't likely to separate from
the main Maven release
The only problem here is that the expression evaluator is meant to
give access to build state, not components in the system...which is
why the @component annotation is handled in a completely parallel
subsystem.
Obviously, plugins _can_ access basically any component in the
container
Is that patch still pending, or has it been applied? I can grab it
and process it if necessary...
-john
On Aug 14, 2007, at 3:34 PM, Jason van Zyl wrote:
On 14 Aug 07, at 9:30 PM 14 Aug 07, Paul Gier wrote:
Kenney Westerhof wrote:
Brian E. Fox wrote:
Sure. I've been thinking that the
Jason van Zyl wrote:
On 14 Aug 07, at 9:30 PM 14 Aug 07, Paul Gier wrote:
Kenney Westerhof wrote:
Brian E. Fox wrote:
Sure. I've been thinking that the standard rules should come out of the
plugin into a separate module too. The thing I'd ultimately like to do
is be able to release the
But that is only for the transitive plugin dependencies right? What
about if I
want to exclude or override one of the plugin's direct dependencies?
I would like to be able to do something like this:
plugin
artifactIdsome-plugin/artifactId
dependencies
exclusions
exclusion
On 15 Aug 07, at 3:30 PM 15 Aug 07, Carlos Sanchez wrote:
Maven artifact is still in
https://svn.apache.org/repos/asf/maven/components/trunk/maven-artifact
does it need to be deleted and change the references?
I also have some changes made in trunk, should I merge to the new
location?
On 15 Aug 07, at 4:42 PM 15 Aug 07, John Casey wrote:
Hi,
I'd like to propose that for Maven trunk/2.1 we capture all plugin-
facing APIs and facades inside a single maven-api artifact. This
would enumerate in a very clear fashion the public APIs that we
need to support. We're
The last release (1.1) of die maven-antrun-plugin was in January 2006. In
Jira there are 3 tickets open for the 1.2 and 6 are resolved.
At this time the documentation at the plugin website is inconsistent with
the actual version - for instance MANTRUN-44 No way to skip antrun when
I am waiting a new release too.
-D
On 8/15/07, Robert Kopco [EMAIL PROTECTED] wrote:
The last release (1.1) of die maven-antrun-plugin was in January 2006. In
Jira there are 3 tickets open for the 1.2 and 6 are resolved.
At this time the documentation at the plugin website is inconsistent
Brian E. Fox wrote:
But that is only for the transitive plugin dependencies right? What
about if I
want to exclude or override one of the plugin's direct dependencies?
I would like to be able to do something like this:
plugin
artifactIdsome-plugin/artifactId
dependencies
exclusions
Welcome back Lukas!
So, we seem to be in agreement that the handling of ids should be as it
is right now. That is we allow these characters -_:.
That should mean that DOXIA-131 is solved right?
I suggest that we publish snapshots of what we have in svn now, to make
sure that things are
Thanks for looking into this Kenney.
Are you saying that that the problem is really in maven itself, and
version 2.0.7 in particular as it uses the shading thingy?
Or is there something that we can do in doxia to fix it? Should we
update to a version of plexus-velocity that uses the latest
+1
Arnaud
On 14/08/07, John Tolentino [EMAIL PROTECTED] wrote:
+1
On 8/14/07, Fabrice Bellingard [EMAIL PROTECTED] wrote:
+1
Fabrice
On 8/13/07, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
I'd like to give to Olivier commit access to Continuum.
He provided lot of
Nice tip Kenney !!
It should be documented somewhere.
I defined it in my .profile
Thx
Arnaud
On 14/08/07, Kenney Westerhof [EMAIL PROTECTED] wrote:
Ssh into minotaur and:
if your shell is bash, do: touch .bashrc echo umask 002 .bashrc
if your shell is tcsh: touch .tcshrc echo
I was planning to let this discussion mature a little bit before I
wrote up anything formal. This is just something that occurred to me
this morning (maybe a little slower than others), and I wanted to
start a real discussion.
-john
On Aug 15, 2007, at 12:36 PM, Jason van Zyl wrote:
On
+1
--
Olivier
-Message d'origine-
De : Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Envoyé : mardi 14 août 2007 16:57
À : [EMAIL PROTECTED]
Objet : [vote] Release Continuum 1.1-beta-2
Hi,
Continuum 1.1-beta-2 is ready for release
The highlights are
- lot of bug fixes
-
Hi guys,
Im studying the problem of attached artifact resolving in reactor mode
mentionned in MNG-2398. Im affected by this issue and am trying to see if I
could find a working solution but I have difficulties getting
maven-2.0.8-SNAPSHOT set up. I have checked out trunks as mentioned in
Dennis Lundberg wrote:
Thanks for looking into this Kenney.
Are you saying that that the problem is really in maven itself, and
version 2.0.7 in particular as it uses the shading thingy?
Yes, the problem is in maven itself. It uses a shaded embedder but that's okay.
2.0.7 uses
On 16/08/2007, at 8:42 AM, Kenney Westerhof wrote:
Or is there something that we can do in doxia to fix it? Should we
update to a version of plexus-velocity that uses the latest plexus-
container-default?
That would work; or add a depMgt section specifying p-c-d and p-c-a
as scope
Hey guys,
It seems that the functional tests for the maven-assembly-plugin are not
being used. There is nothing in the pom file that gets them to run and
they are not being compiled.
Just like to know whats happening so I can test my additional
functionality.
Cheers
--
James William Dumay
Done!
On 14/08/2007, at 12:27 PM, Maria Odea Ching wrote:
Brett Porter wrote:
What do folks think about me moving out the following issues? Is
anyone intending to work on them in the next couple of weeks?
MRM-37 (discover deletion of artifacts)
MRM-265 (artifacts still seen after a
As I was working on the metadata stuff for MRM-463 I discovered an
interesting thing in the repository, wanted to know what you all think
about this.
Case sensitivity:
See http://repo1.maven.org/maven2/logkit/
How should we handle this?
Think about the proxy request for it.
M2_HOME was changed in ci_continuum.sh but it wasn't in .profile.
I'm changing it and will see if it's better
Emmanuel
Brett Porter a écrit :
is this just a bad env on the zone? might be a hint that the release
stuff could have a problem with certain environments too - worth checking.
On
+1
I gave it the basic run through - added a project, some profiles,
checked the licenses. All is well.
Very nice work everyone that's done stuff. It's starting to shape up
well!
- Brett
On 15/08/2007, at 12:56 AM, Emmanuel Venisse wrote:
Hi,
Continuum 1.1-beta-2 is ready for release
Files as 1389 and 1390, with some additional comments about the
alwaysSend bit.
On 11/08/2007, at 2:59 AM, Emmanuel Venisse wrote:
Yes they are improvments requests to file. I'm not sure about 2)
because we already have the alwaysSend parameter that can be set
I won't look at it for
Thanks.
Emmanuel
Brett Porter a écrit :
Files as 1389 and 1390, with some additional comments about the
alwaysSend bit.
On 11/08/2007, at 2:59 AM, Emmanuel Venisse wrote:
Yes they are improvments requests to file. I'm not sure about 2)
because we already have the alwaysSend parameter that
I see too often project's getting stuck in error state, and it's
quite hard to diagnose what's wrong. They don't automatically
recover, and there is no build result for the actual error (so
clicking the icon takes you to the last successful one)
Anyone have any thoughts on how we can
I'm also seeing where there is a real error, like the SVN server
not being reachable, and it not trying to build ever again.
On 16/08/2007, at 1:40 PM, Brett Porter wrote:
I see too often project's getting stuck in error state, and it's
quite hard to diagnose what's wrong. They don't
43 matches
Mail list logo
