more widespread.
For what it's worth, I think dependency type should only be the first plank
of the deployed POM that we should lock down better.
ᐧ
On Thu, Jan 22, 2015 at 12:13 PM, Jason van Zyl wrote:
>
> On Jan 20, 2015, at 6:03 PM, William Ferguson <
> william.fergu...@xand
- deployment to Maven central
@Jason where is the generated POM (think you had another name for it)
concept at?
Does this suggestion fit in with your thoughts on it?
William
ᐧ
On Sat, Dec 20, 2014 at 11:59 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> It's not th
Is there any reason not to use x.y.NN?
The z qualifier is really used for fixes to x.y. So I can't see how it is
different to a released x.y.NN
This would then keep the version numbers compatible with OSGi versioning.
And do we really want a fourth qualifier?
William
ᐧ
On Sat, Jan 3, 2015 at 8:
their problem.
[image: photo]
*William Ferguson*
Founder and CEO, XandarMob
m:+61 425 716 870 | e:william.fergu...@xandar.com.au |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://lexathon.com>
ᐧ
On Sat, Dec 20, 2014 at 9:13 AM, Igor Fedorenko wrote:
&g
ype of their project. But this would massively break
existing build (think of all the war POMs).
[image: photo]
*William Ferguson*
Founder and CEO, XandarMob
m:+61 425 716 870 | e:william.fergu...@xandar.com.au |
w:https://wylas-timing.com
http://lexathon.com <http://wylas-timing.com http://le
the problem?
>
> --
> Regards,
> Igor
>
>
> On 2014-12-07, 19:25, William Ferguson wrote:
>
>> ## Cross posting to Maven Dev list
>>
>> One solution to this would be to change the POM specification to require
>> the type element for dependencies.
>> That
## Cross posting to Maven Dev list
One solution to this would be to change the POM specification to require
the type element for dependencies.
That would allow Maven and MavenCentral to immediately fail POMs based upon
dependencies that are missing the type element.
Yes, it goes against convent
Because of the rise of Gradle usage to its inclusion as the build tool in
Android Studio, there are more and more artifacts making their way into
Maven Central whose POMs contain elements that do not conform to Maven
expectations.
A good example is this POM:
http://search.maven.org/#artifactdetail
ot/maven-timeline/blob/master/src/main/java/net/gageot/maven/buildevents/BuildEventListener.java
> >
> > This can be loaded from the POM.
> >
> > On Aug 31, 2014, at 12:11 AM, William Ferguson <
> william.fergu...@xandar.com.au>
> > wrote:
> >
> >&g
>
> https://github.com/dgageot/maven-timeline/blob/master/src/main/java/net/gageot/maven/buildevents/BuildEventListener.java
>
> This can be loaded from the POM.
>
> On Aug 31, 2014, at 12:11 AM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > If
If I wanted to decorate the calls to each of the Mojos in a plugin what
would be the best way of achieving that?
I'm considering a use case to use analytics to capture plugin usage so we
have a better understanding of which Mojos are of most value. And perhaps
to capture details on Mojo failures.
Is there a developer hangout this week? I can find any calendar reference.
On Fri, Jul 25, 2014 at 5:17 PM, Hervé BOUTEMY
wrote:
> I reworked the Wiki page to reflect this:
>
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Developer+Discussions
>
> Regards,
>
> Hervé
>
> Le vendredi 2
Bloody Kiwis ;-)
6am is fine for me.
On Fri, Jul 4, 2014 at 7:52 AM, Mark Derricutt wrote:
> On 4 Jul 2014, at 9:33, Robert Scholte wrote:
>
> If I'm correct, following have joined at least 2 times or are Maven PMC
>> 22:00-23:00 (CEST) Robert Scholte, Hervé Boutemy, Karl-Heinz Marbaise,
>> Ma
The original Java deprecation guidelines were to
1) Include a "since" statement indicating at point the API was deprecated
2) include a statement pointing to the replacement API (or non-replacement
and reason for same).
On Sat, Jul 5, 2014 at 10:34 PM, Robert Scholte
wrote:
> +1, I often hit de
Thanks Dan.
I didn't appreciate at first the impact of setResolveTransitively(true).
NB I needed to change request.setResolveRoot(false) to exclude the provided
artifact.
William
On Fri, Jun 20, 2014 at 11:44 AM, Daniel Kulp wrote:
>
> On Jun 19, 2014, at 6:36 PM, Willi
OK, so it will resolve from the reactor.
But is the ArtifactResolutionResult going to contain the dependencies of
the Artifact that I resolve?
On Fri, Jun 20, 2014 at 6:46 PM, Hervé BOUTEMY
wrote:
> Le vendredi 20 juin 2014 08:36:46 William Ferguson a écrit :
> > Hi Dan,
>
de.
> > > In this case I'm thinking of the maven-dependency-plugin, especially
> the
> > > code for dependency:tree.
> > > Or use the org.apache.maven.project.ProjectBuilder
> > >
> > > thanks,
> > > Robert
> > >
> > > Op Thu, 1
session.getRequest().getMirrors() );
> >>request.setProxies( session.getRequest().getProxies() );
> >>request.setLocalRepository(session.getLocalRepository());
> >>
> >>
> request.setRemoteRepositories(session.getRequest().getRemoteRepositori
tephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On Friday, 20 June 2014, William Ferguson
> wrote:
>
> > Stephen, I'm a little confused by the 3 POMs you have outlined.
> >
> > 1. The 4.0.0 flattened consumer pom
>
>
> This is the pom for a
Stephen, I'm a little confused by the 3 POMs you have outlined.
1. The 4.0.0 flattened consumer pom
2. The post 4.0.0 flattened consumer pom
3. The build pom
Maybe it's just a naming issue, I also see 3 POMs but they are these:
A) Consumer POM for non POM projects. Essentially an effective POM s
n.getRequest().getRemoteRepositories());
> repository.resolve(request);
> return artifact.getFile();
> }
>
> If you set “setResolveTransitively(true)” then the
> ArtifactResolutionResponse would have all the deps available in it.
>
> That seems to work for
-plugin, especially the
> code for dependency:tree.
> Or use the org.apache.maven.project.ProjectBuilder
>
> thanks,
> Robert
>
> Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson <
> william.fergu...@xandar.com.au>:
>
> I asked on maven-users but didn't get any viable responses
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies. How
can/should I do it?
If I can resolve
+1 to recording for posterity.
8am next Wednesday is queuing time at Google IO :-)
On Sat, Jun 14, 2014 at 3:36 AM, Jason van Zyl wrote:
> Ok, here's the link for next Wednesday. We'll try it once and see how it
> goes, if people like it we'll keep going. It's setup so that it records so
> peop
Interpreter
--
Can I suggest that a good first step towards an enhanced Maven POM
structure would be to introduce an element that declares the
interpreter to use to consume the remainder of the POM file.
Lack of such an element reverts to 4.0 interpreter.
Doing this would allow us to
his week.
>
> On May 27, 2014, at 8:12 PM, Hervé BOUTEMY wrote:
>
> > I don't have time to do it immediately, but I can do it in a few time. Or
> > anybody else.
> > Do you have some schedule (for android-manve-plugin, IIUC)?
> >
> > Regards,
> &g
Herve,
can we get a release of maven-dependecy-tree?
William
Argh .. I think I finally get it - thanks Igor.
On Sat, May 24, 2014 at 11:03 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> Thanks Igor.
>
>
>> A correct LifeCycleParticipant implementation should always scope
>> component lookups to the curren
>
> parameters and local variables are not considered final: there is nothing
> wrong
>
with modifying their value, and nothing good to get by forcing them to be
> final
>
But there *is* value is defining them to be final.
If you as the programmer know that a value should never change, then by
de
Thanks Igor.
> A correct LifeCycleParticipant implementation should always scope
> component lookups to the current project's classloader and should use
> the original classloader to allow lookup of the core components only.
But in a multi-module build the LifeCycleParticipant is only ever call
sible realms but Stuart knows exactly how
> this is done (he implemented it), so might have something to add/correct.
>
> On May 21, 2014, at 4:33 AM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > Thanks Igor. That fixes it :-)
> >
> > Is there
>
> I do not agree on this one, and that's the meaning of the coding style
>
Wouldn't you rather have the compiler catch the error as opposed to
manually introspecting the code each time?
forget to restore TCCL in finally block ;-)
>
> --
> Regards,
> Igor
>
>
> On 2014-05-20, 20:27, William Ferguson wrote:
>
>> Hi Herve,
>>
>> I am using MLCP#afterProjectsRead.
>> Unfortunately the extensions don't seem to be loaded at that point
GitHub user william-ferguson-au opened a pull request:
https://github.com/apache/maven-shared/pull/7
Ensuring that the multi-module-plugin is built before the multi-module-test
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
:41 AM, Hervé BOUTEMY wrote:
> Le mardi 20 mai 2014 09:59:24 Jason van Zyl a écrit :
> > On May 19, 2014, at 7:52 PM, William Ferguson
> wrote:
> > > One of the Maven Java code conventions (listed on that page) is to
> > >
> > >- Avoid using final modifie
Yes, you could set a low but effective bar and enforce that via build.
And in fact checkstyle can be used to enforce licence so it becomes a
superset of rat.
On Wed, May 21, 2014 at 9:49 AM, Hervé BOUTEMY wrote:
> Le mardi 20 mai 2014 09:52:26 William Ferguson a écrit :
> > On Tue, May
ould probably change the "TODO" into javadoc, since this shuld be
> documented limitation
>
> WDYT?
>
> Regards,
>
> Hervé
>
> Le lundi 19 mai 2014 11:31:42 William Ferguson a écrit :
> > So it boils down to ProjectDependenciesResolver being able to resolve an
>
On Tue, May 20, 2014 at 5:47 AM, Hervé BOUTEMY wrote:
> > 1) Is there no automatic checkstyle verification as part of the build? We
> > use it in the android-maven-plugin and I though it was standard practice
> > across the Maven projects.
>
> it's only done on site generation, and you can simpl
GitHub user william-ferguson-au opened a pull request:
https://github.com/apache/maven-shared/pull/6
maven-dependency-tree : Resolving reactor deps 2
Applied changes for https://jira.codehaus.org/browse/MSHARED-336 requested
by Herve.
You can merge this pull request into a Git
>> used to validate multi-module-test - Added ProjectReferenceKeyGenerator
> as
> >> there is currently no public method to generate the key for
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Se
Thanks Jason, appreciate it.
William
On Mon, May 19, 2014 at 11:39 AM, Jason van Zyl wrote:
>
> On May 18, 2014, at 9:31 PM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > So it boils down to ProjectDependenciesResolver being able to resolve an
>
?
Someone, anyone?
William
On Sun, May 18, 2014 at 9:23 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> OK, I'm really hoping someone can provide some more insight on this as I
> have reached my limit.
>
> To make things clearer, I have created a project c
est - Added ProjectReferenceKeyGenerator
> as
> >> there is currently no public method to generate the key for
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Separated the reflective invocation
> &
> >> MavenProject#projectReferences, MavenSession#projectMap or the Map of
> >> reactor projects that we will use. - Separated the reflective invocation
> >> out into the Invoker class.
> >> - Made maven-project dependency scope=provided as at runtime we want the
On Mon, May 19, 2014 at 8:49 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> Hervé Boutemy <https://plus.google.com/u/0/107251243568189719606?prsrc=4>
> said:
> in interface DependencyGraphBuilder, why expect a Map reactorProjects,
> when a List seems
> there is currently no public method to generate the key for
> > MavenProject#projectReferences, MavenSession#projectMap or the Map of
> > reactor projects that we will use. - Separated the reflective invocation
> > out into the Invoker class.
> > - Made maven-projec
present as being resolved.
>
> There is way, way too much of the guts of Maven exposed for these types of
> resolution activities.
>
> On May 8, 2014, at 6:30 PM, William Ferguson <
> william.fergu...@xandar.com.au> wrote:
>
> > Since MavenProject#getProjectReferences is
ithin
MavenLifeCycleParticipant) and well as integration tests showing that that
same deps are resolvable either using the std Maven dep resolution or
explicit resolution from within a Mojo,
https://github.com/william-ferguson-au/example-resolution-plugin.
Could someone please have a look and help me work out h
No one on the user's list wanted to have a go at this. How about someone
from the Dev list?
William
-- Forwarded message --
From: William Ferguson
Date: Mon, May 12, 2014 at 8:58 PM
Subject: Wagon extensions not available from
AbstractMavenLifecycleParticipant or
Since MavenProject#getProjectReferences is public why is
MavenProject#getProjectReferenceId (which is the only way of generating the
key for projectReferences without breaking encapsulation) private?
NB in maven-project-2.2 #getProjectReferenceId used to be public.
William
GitHub user william-ferguson-au opened a pull request:
https://github.com/apache/maven-shared/pull/5
Enhanced maven-dependency-tree to allow resolution of reactor dependencies
Added an overloaded method to DependencyGraphBuilder that accepts the
reactor projects and resolves
Just wanted to through 2c in.
Jason, you mentioned supporting other uses cases such an Android builds. I
thought I'd explain what's required from that perspective.
The Android team have defined an Android archive (AAR) that holds a JAR and
various Android resources. When the AAR is declared as a
roject,
> can actually have a much simpler set of format restrictions... such as you
> cannot depend on a parent builder pom that uses a newer modelVersion than
> yours.
>
>
> On 25 February 2014 05:16, William Ferguson
> wrote:
>
> > One of the common complaints I hear
One of the common complaints I hear about Maven is that the config is too
verbose, especially when compared to the attribute based dependency config
used by Ivy. Personally it doesn't worry me overly, but if the config for
dependencies/plugins where to become attribute based instead of element
base
Remove the phase element from the execution.
William
On Mon, Feb 10, 2014 at 11:12 PM, indira wrote:
> Added exec-maven-plugin pulgin in pom.xml
>
> .
>
> org.codehaus.mojo
> exec-maven-plugin
> 1.2
>
>
?
William
On Fri, Feb 7, 2014 at 1:58 PM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> :-) well unless you are doing Android dev there really isn't any need to
> know what the AAR structure is.
>
> An AAR contains the following:
>
>- assets folder - C
Does the build need any other AAR entries or
> classes.jar is the only entry needed by the build?
>
> --
> Regards,
> Igor
>
>
>
> On 2/5/2014, 20:56, William Ferguson wrote:
>
>> Wrt to the ArtifactHandler for AAR artifacts. Could you expand on that.
>&g
other idea is to extend ArtifactHandler API to directly support
> "AAR" usecase, i.e. when dependency is not added to classpath directly
> but something is extracted from the dependency first and that extracted
> file/directory is added to classpath instead.
>
> --
> Regards,
>
jects-aar1
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:302)
... 26 more
William
On Wed, Feb 5, 2014 at 8:47 AM, William Ferguson <
william.fergu...@xandar.com.au> wrote:
> Can you explain the need to establish the reactor build order? I had
> expected session.getProjects() to have retu
get back to it in a couple of months.
William
On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko wrote:
>
> On 2/4/2014, 1:06, William Ferguson wrote:
>
>> OK, I'm getting the dependencies to resolve and I can amend the classpath,
>> but I think I've hit a road bloc
x27;m not going to be able extract and add ModuleA and it's classes when the
LifeCycleParticipant executes because ModuleA will not have been built yet.
Is there some way to get the LifeCycleParticipant called for every module
of the build?
William
William
On Tue, Feb 4, 2014 at 12:46
7;t causing the projects dependencies to get
resolved. I'm not sure what I'm missing.
I've created a cut down project dep-resolution-plugin at
https://github.com/william-ferguson-au/dep-resolution-plugin.git
And a project that tests that plugin at
https://github.com/william-ferguson-au/dep
t's going on there.
>
> --
> Regards,
> Igor
>
>
> On 1/23/2014, 0:54, William Ferguson wrote:
>
>> Igor,
>>
>> I'm having some difficulty getting the LifecycleParticipant to resolve
>> Maven components.
>>
>> In particular, the or
?h=tycho-0.19.x
>
> --
> Regards,
> Igor
>
>
> On 1/20/2014, 8:21, William Ferguson wrote:
>
>> Thanks Igor,
>>
>> could you give me a link to an example or some code that
>>
>> - Utilises AbstractMavenLifecycleParticipant#afterProjectsRead
&g
n classes jar nested within this AAR
> archive".
>
> --
> Regards,
> Igor
>
>
> On 1/20/2014, 7:00, William Ferguson wrote:
>
>> Hi,
>>
>> I realise this question isn't exactly related to dev within the Maven
>> components, but it is about developi
Hi,
I realise this question isn't exactly related to dev within the Maven
components, but it is about developing a Mojo using components that have to
be pretty central and don't appear to be obviously documented anywhere. And
I ahve asked on maven-users without much luck.
As part of the android-m
As Benjamin points out at the end of that Jira, the current behaviour is there
to deal with use of libraries containing classes that extend classes in other
libraries.
Seems to me that we need a way to differentiate in our projects which
dependencies need to get *exported* as compile dependenci
> If 3.2 where (sic) expressed as a hard requirement, it should throw an
exception.
Yes, but not a NullPointer.
The reason for the failure needs to be clear and unambiguous.
William
> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 4 March 2008 7:52
I agree. It is imperative that we keep a clear succinct list of phases
for the different builds. Allowing ad hoc additions will make
understanding a POM less portable.
I also like the idea of doing away with the pre and post phases (but not
the functionality). I suggest abstracting out the curren
+1 (non binding)
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Olivier Lamy
> Sent: Friday, 11 January 2008 5:36 AM
> To: Maven Developers List
> Subject: [***POSSIBLE SPAM***] - [VOTE] Release Maven Jar
> plugin version 2.2 - Sender is forged (
OK, that embarrasing.
It had nothing to do with repository config.
I'd forgotten to change the version of the site-plugin in my pom to
2.0-beta-6
+1 [non binding]
William
> -Original Message-
> From: Dan Tran [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 27 November 2007 11:59 AM
> To: Ma
Hmm .. very frustrated now ..
I removed the mirror and still see it attempting to download the POM
from central (which it obviously can't).
It then downloads the plugin from the staging repository.
But then never looks for the POM in the staging repository and hence
fails with:
[ERROR] BUILD ER
OK, I'm trying to validate but I guess I have some bad config.
It looks like its attempting to retrieve the site-plugin POM from my
mirror of central and the site-plugin jar from the staging area.
D:\Modules\hubbub-log4j>mvn site
[INFO] Scanning for projects...
[INFO]
---
Jake,
I think this could be really useful. Some rough edges: I wouldn't use a
white font with a yellow background for instance.
But plenty of meat.
I think the best place for it would be as an Eclipse plugin.
Perhaps as an addendum of the M2Eclipse plugin??
http://m2eclipse.codehaus.org/
William
eta-6
William Ferguson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> > Yes, I know we discussed it briefly at the time, but I
> > wanted to look at the actual implications for 2.0.x users now.
> There are none, they aren't using it. And it's only
> implication is in conjunction with the release plugin and the
ouldn't be inherited, then that would probably be acceptable.
-Original Message-
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 10:01 PM
To: Maven Developers List
Subject: RE: 2.0.8 Release Candidate
It's a real shame that MNG-3244 had to be rever
It's a real shame that MNG-3244 had to be reverted.
Now there is no way for an inherited site#url to actually specify the
url for a project.
The current behaviour in which the child artifactId is always appended
is non-intuitive IMHO.
It only makes sense for inherited POMs in multi-modules POMs an
16 Oct 07, William Ferguson wrote:
> Could we at least resolve those issues that have patches waiting to be
> applied?
>
> Like http://jira.codehaus.org/browse/MNG-2123
>
It's really is not as simple as applying a patch. They need testing, and
verification and validating somethin
#x27;re getting too far away from the release early/ release often mantra
we try to follow.
-Original Message-
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 16, 2007 7:09 PM
To: Maven Developers List
Subject: Re: Maven 2.0.8 - any updates?
Looks like there ar
Looks like there are still 17 open issues scheduled for 2.0.8.
See
http://jira.codehaus.org/secure/IssueNavigator.jspa?fixfor=13139&sorter/field=priority&mode=hide&reset=true&pid=10500&sorter/order=ASC
William
-Original Message-
From: Mark Hobson [mailto:[EMAIL PROTECTED]
Sent: Tuesda
thout
pom, hey, it's your decision, but you are aware that it's a problem, as
all the warnings tell you
On 10/15/07, William Ferguson <[EMAIL PROTECTED]> wrote:
> Isn't the goal here to stop incessant warnings during a build about
> trying to downalod a missing POM?
>
Isn't the goal here to stop incessant warnings during a build about
trying to downalod a missing POM?
The way to do that is to that is to upload a POM for that artifact to
the repository.
But Nico is right is that the uploaded POM should not break existing
builds. Which means that the POM just ne
I don't want to nag, but could someone please apply the patches for
http://jira.codehaus.org/browse/MRESOURCES-47
and
http://jira.codehaus.org/browse/MJAR-83
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
Could some please apply the patch for
http://jira.codehaus.org/browse/MJAR-83
It's pretty simple.
Just ensures adequeate dependency resolution.
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mai
Could someone please apply the patch for
http://jira.codehaus.org/browse/MRESOURCES-47
It contains test cases and all those other good things.
William
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
I added the following proposal to User Proposals a while back
http://docs.codehaus.org/display/MAVENUSER/Binding+Mojos+to+custom+LifeC
ycles+or+inclusion+of+the+Release+Plugin+LifeCycle+into+Maven+Core
And was just wondering whether there are any plans along these lines for
Maven 2.1?
William
gets set to off if
the attached patch isn't sufficient (and the comments should be enough
to reflect it).
cheers,
Brett
On 19/09/2007, at 9:44 AM, William Ferguson wrote:
> OH, I thought Maven_Patch_Day was a one off.
>
> In that case can I suggest that the entries be split
OH, I thought Maven_Patch_Day was a one off.
In that case can I suggest that the entries be split into separate
tables or documents based on whether they
- are waiting to be applied
- have been applied
- require revision, ie bad or out of date patch.
BTW it seems strange that this information ne
Now that it seems a release of 2.0.8 is imminent.
What is the protocol for agitating for issues that have been patched to
be included in 2.0.8?
Eg http://jira.codehaus.org/browse/MNG-2123
William
-
To unsubscribe, e-mail: [EMAI
I agree that the ability to lock down a build is important for release
management, but part of the beauty of Maven is the ability to concisely declare
a build and at the same time benefit from incremental improvements in various
components of it.
Inhouse, we use a buildinfo-plugin (from "Better
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Monday, 27 August 2007 2:19 PM
To: Maven Developers List
Subject: Better access to custom life cycle phases
Are there any plans for to allow better access to custom life cycle
phases in maven-2.1?
In particular, I would like to be able to config
Are there any plans for to allow better access to custom life cycle
phases in maven-2.1?
In particular, I would like to be able to configure a plugin to execute
during some of the lifecycle phases of the maven-release-plugin. The
current mechanism of specifying goals to run during the preparation
OK, we've been running for the last week with the patch for
https://svn.apache.org/repos/asf/maven/wagon/branches/WAGON-73
And everything has been performing as expected.
Many thanks Brian!
Any chance we can get the patch folded into the trunk now?
Or do I need to enter it into Maven Patch Day?
As suggested by Eric, I've reposted this query to the developers list.
What lifecycle phase needs to have run in order to get provided scope
dependencies made available in a plugin.
http://maven.apache.org/ref/current/maven-project/apidocs/org/apache/mav
en/project/MavenProject.html#getA
Curious,
I only get 2 failures and one error (against 2.0.7 without the patch):
Results :
Failed tests:
testit0045(org.apache.maven.integrationtests.MavenIT0045Test)
testit0046(org.apache.maven.integrationtests.MavenIT0046Test)
Tests in error:
testit0104(org.apache.maven.integrationtests.
I've moved this discussion off JIRA.
Brian,
I have just checked out the core-integration-testing/trunk and was just
trying to execute the core-integration-tests myself. How did you execute
them for Maven-2.0.7 with the WAGON-73 patch applied?
Did you need to change something in the core-integrat
e process to make sure it works. I've
applied patches that seems minimal they end up inadvertently making
something else not work.
Don't get frustrated, the patch is simple yes but we all have day jobs
just like you.
> William
>
> -Original Message-
> From: William Fergus
different SMTP TO: and MIME TO: fields in the email
addresses
Wagon has its own mailing lists :
http://maven.apache.org/wagon/mail-lists.html
you can also join the team on the irc :
irc.codehaus.org #wagon
arnaud
On 06/08/07, William Ferguson <[EMAIL PROTECTED]> wrote:
> Come on guys.
meone
please pick it up and apply the patch?
William
-Original Message-
From: William Ferguson [mailto:[EMAIL PROTECTED]
Sent: Friday, 3 August 2007 11:39 AM
To: dev@maven.apache.org
Subject: Please apply the patch for WAGON-73
This issue is a real pain : http://jira.codehaus.org/browse/
1 - 100 of 106 matches
Mail list logo
