pment outside of Apache. The vote
> would lead to a consensus, no?
>
>
> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On 2 August 2013 16:32, Paul Benedict wrote:
> >
> > > Furthermore, I'd like
Committers... but keep in mind that none of us
enjoy that!!!
>
> Regards,
> Curtis
>
> P.S. For those interested, Stephen's changes are more clear when reading
> the side-by-side diff:
>
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-rol
On 2 August 2013 16:32, Paul Benedict wrote:
> Furthermore, I'd like to see explicit procedural rules on Maven Core and
> forking. For example, if there's a critical component needing development
> for Core, and a PMC expresses that such development will be done outside of
> Apache and then used
ly the core of the concerns... the extra diligence required to
> consume large bodies of work is bigger. That doesn't mean that code
> contributions are inherently bad just because they were developed
> elsewhere, it's just harder to pull in.
>
Correct.
>
> On Fri,
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=150959
On Friday, 2 August 2013, Stephen Colebourne wrote:
> On 2 August 2013 01:10, Stephen Connolly
> > wrote:
> > The use of wildcard-like behaviour is not a good plan, so being slightly
> > more cumbersome on the CLI is a bonus from my PoV.
> >
> > I prefer to enco
ice by making non-best practice harder...
Making it impossible is not a good idea IMHO.
- Stephen
>
> Stephen
>
>
> On 2 August 2013 00:10, Stephen Connolly
> wrote:
> > Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT
> >
> > I now have test cases and I
Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT
I now have test cases and I have verified that there are no regressions.
Just have to decide if there is anything else I will add before cutting a
release
On 1 August 2013 18:54, Stephen Connolly wrote:
>
>
> On Thursday,
lease plugin does during prepare... If that isn't preserved we need
to fall back to "magic" comments which is sub- optimal to say the least
>
> Alejandro Endo | Software Designer/Concepteur de logiciels
>
>
>
>
> From: Stephen Connolly >
> To: Ma
n
> at org.codehaus.mojo.versions.SetMojo.applyChange(SetMojo.java:258)
> at org.codehaus.mojo.versions.SetMojo.execute(SetMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
> BuildPluginManager.java:101)
>
project is private so its hard to
> describe/publish logs.
>
> Stephen
>
>
>
> On 1 August 2013 16:25, Stephen Connolly
> wrote:
> > Please try 2.2-SNAPSHOT
> >
> > It may or may have wildcard support that works and doesn't cause any
> > regres
l - versions:set-aggregated - which sets
> every matching version within an aggregated pom structure when called
> from the root.
>
> Would you want such a thing included in the versions plugin? Or does
> it need to be a separate plugin?
>
> I have to have something, as the alter
ion, but I'd have no
> idea to implement it.
>
> I simply want a goal that allows a multi-module build, where the
> modules are versioned in lock-step, to be updated. Is that too much to
> hope for?
>
> Stephen
>
>
> On 1 August 2013 13:50, Stephen Connolly
> wro
run versions:set on R it will only update R, and not A/B/C/D/E
>
> If you manually set the version of A, and then run versions:set on R,
> projects R/A/B/D/E will be updated, but not C. (which is pretty weird)
>
> The patch in MVERSIONS-131 sounds reasonable. Could it be evaluated?
>
How I want this to work is to have versions-maven-plugin have a way to undo
versions:resolve-ranges (
http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) -
it would need to ensure that the lower bound of any unresolved range is the
resolved version... [see below]
We'd need to
On Monday, 29 July 2013, patrick krekelberg wrote:
> Hi all,
>
> I am thinking the problem I am trying to solve has to be a common one, so
> I'll throw this out there to see what you think:
>
> We have an application that ultimately needs to get pushed to one or more
> servers, we happen to be usi
Eric V wrote:
> I didn't pick the build system unfortunately.
> I'm just using what came with the productŠ
> And cursing their developers for using something that doesn't seem to mesh
> with high security environments.
>
>
> On 7/29/13 8:18 AM, "Stephen C
On 29 July 2013 15:04, Bahmer, Eric V wrote:
> I was just hoping that maybe maven could use the local version numbers
> without renumbering everything as a command line option, especially for my
> environment where I can't have the maven going online and have to use the
> packages that I built fr
://maven.apache.org/guides/mini/guide-using-toolchains.html which can
be used to simplify using a different JDK for compiling and running unit
tests.
Thank you.
-Stephen Connolly on behalf of the Maven Developers.
s us back to what does the community expect from its PMC?
> I ask rhetorically,
> to solicit answers, of course... and I see where this is going and what
> historical processes within Maven are being addressed.
>
>
> On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly <
> ste
; As a Maven user I think that everybody who is working on a project should
> > behave the same. Hence, I would say, PMC members should rather certainly
> > demonstrate how to live the community rules.
> >
> > -Ursprüngliche Nachricht-
> > Von: Stephen Connolly [
you are in a great position. Get more code readers!
>
> If someone is generating more ideas for improvement than the team can
> evaluate, then add more marketing/analyst types to the committee.
>
>
> Ron
>
> On 25/07/2013 12:56 PM, Jason van Zyl wrote:
>
> On Jul 25, 2013, a
@tesla.io]
> Sent: Thursday, July 25, 2013 9:56 AM
> To: Maven Users List
> Subject: Re: [DISCUSS] Should the Maven PMC be an example of how we want
> the Maven Community to behave (was Re: svn commit: r1506778 -
> /maven/site/trunk/content/markdown/project-roles.md)
>
>
> On Jul 25,
ut if someone posits that all work related to an Apache project has to be
> done at Apache, then I will say that is a ridiculous supposition and you
> can find ten counter examples in ten minutes if you went looking.
>
> On Jul 25, 2013, at 10:31 AM, Stephen Connolly <
> stephe
bit like saying "boo-hoo, those that are doing the
> > actual work might go work in their own sandpit if we won't play ball,
> let's
> > ex-communicate them" ?
> >
> > Unless (as some have suspected for a while) Apache isn't about software
> > an
k and white... The answer can be grey... And everyone is
human so can make mistakes...
So community, what are you expecting?
- Stephen Connolly
On Thursday, 25 July 2013, wrote:
> Author: jdcasey
> Date: Wed Jul 24 23:21:58 2013
> New Revision: 1506778
>
> URL: http://svn.apach
You could do something with maven-invoker-plugin and have something else
generate the "filtered" pom file for you... you'd have to do some dancing
games though.
I would suspect, though, that you have some anti-patterns in your pom in
the first place. Perhaps you should re-evaluate how and why you
+1
On Saturday, 20 July 2013, Dennis Lundberg wrote:
> Hi,
>
> Now that we have Maven 1 at End-Of-Life, I think it's time to retire
> Maven One Plugin as well. It has been almost six years since the last
> release. I therefor propose that we retire maven-one-plugin.
>
> http://maven.apache.org/pl
+1 (binding)
On Friday, 19 July 2013, Dennis Lundberg wrote:
> Hi
>
> It has been almost five years since I made the last release of
> maven-idea-plugin. The features in IDEA to integrate Maven has been greatly
> improved since then, making our own plugin obsolete. I therefor propose
> that we re
---Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Thursday, July 18, 2013 7:10 AM
> To: Maven Users List
> Subject: Re: executing release:prepare with release-sign-artifacts
>
> I have the following in my ~/.m2/s
I have the following in my ~/.m2/settings.xml
sonatype-oss-release
steph...@apache.org
That means that any time I make a release which has the sonatype-oss-parent
as its parent, then it gets signed with my personal key.
For other projects which nee
or plugin developers to go astray and perform
> activities that have negative downstream consequences to other plugins.
>
> Best regards,
>
> Richard
>
>
>
>
>
>
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com
> ]
was unintentional.
>
> -Richard
>
> Sent from my iPhone
>
> On Jul 15, 2013, at 2:01 PM, "Stephen Connolly" <
> stephen.alan.conno...@gmail.com > wrote:
>
> > Please refrain from referring to your plugin as the maven plugin.
> > Maven and Apac
Please refrain from referring to your plugin as the maven plugin.
Maven and Apache Maven are trademarks of the Apache Foundation and as such
their use requires some clarity.
We (the Maven project) have sought guidance as to how others can use our
mark and the guidance we got is that if the ot
Is the parent pom being resolved?
One of the legacies of the maven repo that sun set up is that you can have
a few hoops to jump through.
I'd ask the Hudson project (is it anyone besides Winston these days? -
asked from somebody very firmly on the Jenkins side of the split)
On Friday, 12 July 20
apache.org/alternate-descriptors.html
JBoss seems to have some way... but it is beyond what I can grok in 30sec
Glassfish doesn't seem to let you do that...
On 11 July 2013 10:29, Stephen Connolly wrote:
> It's not an EJB 3.1 thing... checking the 3.2 spec now
>
>
> On 11 Ju
k it should be possible to do this an a JavaEE
> application (Perhaps I should find this out somehow and extend my
> tutorial). If someone here knows how to do so, I would be glad for some
> Input on this ;-)
>
> Chris
>
> ________
> Von
That looks like a Spring only solution I wonder is there a pure JavaEE
counterpart
On 11 July 2013 09:56, christofer.d...@c-ware.de
wrote:
> You could have a look at my Wiki article about multiple persistence.xml
> files:
> https://dev.c-ware.de/confluence/display/PUBLIC/Multiple+persistence
On 10 July 2013 15:52, Ron Wheeler wrote:
> On 10/07/2013 10:06 AM, Stephen Connolly wrote:
>
> Well if it is an interactive installer then it can do the configuration
> for you...
>
> It needs to be interactive in some way if you want to handle a variety
> of environm
designed to tweak packages during deployment.
>
> They can be set up very easily to be very smart about using input from the
> Application Deployer and Administrator or from the environment directly, to
> customize the installed application.
>
> Ron
>
>
>
> On 10/07/2013 4:23
Well the first thing I would look towards is whether you can use an
application server specific deployment descriptor to tweak the effective
persistence.xml at deployment time.
I am not saying that the above is possible, but if it is, then that is
obviously "the way to go" as you then can just bun
On 8 July 2013 16:37, Alan Buck wrote:
> I'm beginning to get the hang of Maven but I just ran into an issue that
> I'm not sure how to rectify it.
>
> com.p1s:mps] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy)
> on project mps: Failed to retrie
On Friday, 5 July 2013, Mirko Friedenhagen wrote:
> Hello,
>
> now after some trial and error with custom packaging and lifecycles I
> ask myself whether I should proceed or do something completely
> different.
>
> What I want to achieve:
> - We have loads of web-applications (WARs with a homegrow
File the bug request against enforcer and let that move it *if* necessary
as initial evidence points to enforcer's issue
On 3 July 2013 13:40, Wolf Geldmacher wrote:
> Hi list.
>
> I just got hit by a weird interaction between two plugins, namely the
> maven-enforcer-plugin and the maven-assemb
it is all moot anyways
On Friday, 28 June 2013, Jörg Schaible wrote:
> Stephen Connolly wrote:
>
> > MAVEN_HOME is for Maven.
> >
> > If M2_HOME is set, then that will be used by Maven 2+ and MAVEN_HOME will
> > be ignored.
>
> Well, then download M305 an
MAVEN_HOME is for Maven.
If M2_HOME is set, then that will be used by Maven 2+ and MAVEN_HOME will
be ignored.
When Maven 3 was being initially released we were going to drop M2_HOME
completely, but decided to keep support for it.
Going forward, I would just pick MAVEN_HOME and ensure M2_HOME is
Scope import only applies to dependencyManagement, or at least that is my
understanding... If it has changed I'd appreciate the links
On Sunday, 23 June 2013, Baptiste MATHUS wrote:
> +1, but you may want to also insist on using scope=import.
>
> Because if you don't, for example, you won't test
On 19 June 2013 22:31, Laird Nelson wrote:
> On Wed, Jun 19, 2013 at 2:14 PM, Thomas Broyer wrote:
>
> > With copy, you declare the needed artifact in the plugin configuration.
> > From Maven's PoV there's no dependency between the module that copies and
> > one being copied.
>
>
> Right. OK.
>
Don't use it for that use case. That goal's use case is templating java code
On 18 June 2013 16:05, Arnaud bourree wrote:
> Hi,
>
> OK, I don't used templating:filter-sources for this original goal: Java.
> My use case is to run shUnit2 test scripts to validate Bash script.
> I've make context
n 12 June 2013 07:59, James Green wrote:
> > Many thanks for filing this - I do assure you that I was not under the
> > impression the GitHub plugin was official or even endorsed but I agree
> that
> > the trademark requires work to enforce. And I just love their resp
n states everything is included)?
>
> On the right track at least!
>
> Thanks,
>
> James
>
>
> On 11 June 2013 22:27, Stephen Connolly >wrote:
>
> > On 11 June 2013 22:03, James Green wrote:
> >
> > > See responses inline.
> > >
>
On 11 June 2013 22:27, Stephen Connolly wrote:
> On 11 June 2013 22:03, James Green wrote:
>
>> If you search for maven-download-plugin you should reach a project on
>> GitHub.
>
>
> Please advise them to rename their plugin as the current name is in
> violation
On 11 June 2013 22:03, James Green wrote:
> See responses inline.
>
>
> On 11 June 2013 21:47, Wayne Fay wrote:
>
> > > Nexus is used to host the .exe file. As the exe originates from a
> > separate
> > > Maven project, and it needs to live somewhere, I folded the exe
> > generation
> > > into a
it a
> spin on my project, it munged the leading whitespace for each major
> section, replacing a single leading tab with a single leading space. Of
> course, it's alpha; I'll give it a try again when there is another release.
>
> Regards,
> Curtis
>
>
> On Mon
r1491738 fixes the broken link. I need to investigate how to fix the site
without releasing the plugin. The correct link is
http://ant.apache.org/manual/Tasks/ant.html
On 11 June 2013 10:31, James Green wrote:
> I'm reading from http://maven.apache.org/plugins/maven-antrun-plugin/ that
> I shou
on in your project's plugin
configuration:
org.codehaus.mojo
tidy-maven-plugin
1.0-alpha-1
This is the first release of Mojo's Tidy Maven Plugin.
Share and enjoy[1],
The Mojo team.
Stephen Connolly.
[1] Or go stick your head in a pig if you have issues with the complaints
de
t, isn't it?
>
> I seem to remember some threads about it in the past.
> Or someone having fun trying to look slightly in the field of the answer
> but just dragging people into things they will just lose time with?
>
> Cheers
>
>
> 2013/6/7 Stephen Connolly 'cvml
Ok, I'll bite...
Martin, I know your responses are usually, to my mind at least, slightly
off with respect to the question asked, but i can usually find some
connection.
In this case, however, i have to ask how on earth do you think this has
*any* relevance to the question about Subversion?
On T
in a profile you could define the configuration for the plugin and specify
the `properties` (see
http://mojo.codehaus.org/versions-maven-plugin/update-properties-mojo.html#properties)
and then reference another property to define the range of valid values.
really rather hacky if you ask me... bett
.
>
> I can order my proxies in my group. Which seems to be the same as
> referencing them directly.
>
> No? (not that I don't want to change it. I'm just trying to understand)
>
>
>
>
>
> On 5 June 2013 14:34, Stephen Connolly >wrote:
>
> >
pom
that stops the "deploying a jar when you don't have one" problem
As for your second issue I would use
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
On 5 June 2013 13:26, Andy wrote:
> Hi All,
>
> I have searched to death the jni project solutions and would j
> > peuvent facilement être sujets à la manipulation, nous ne pouvons
> > > accepter
> > > > aucune responsabilité pour le contenu fourni.
> > > >
> > > >
> > > > > From: henri.tremb...@gmail.com
> > > > > Date: Wed, 5 Jun 2013
lling that it "Forces a check for updated releases and snapshots
> on remote". It's a bit weird that rekeases are checked but why not. BUT why
> is staxex maven-metadata.xml file the only one the keeps being downloaded?
> (with groovy-eclipse-batch that also is)??? Some time
Maven has a couple of default packaging types that have defined lifecycles.
e.g. `jar`, `war`, `ear`, etc.
If you don't specify `` then Maven assumes that your project is
`jar` by default.
Maven will then consult its registry of lifecycles and see the lifecycle
for the `jar` (or whatever packagi
eg
...
...
...
...
...
On 4 June 2013 16:46, Stephen Connolly wrote:
> plugins are not executed unless the packaging for the specified project
> injects an execution OR you specify an execution for the plugin yourself
>
>
> On 4 June 2013 16:01, alesky
plugins are not executed unless the packaging for the specified project
injects an execution OR you specify an execution for the plugin yourself
On 4 June 2013 16:01, alesky wrote:
> 1. Please use a propper mail agent that does not strip the code from you
> email
> ok i will do the next time so
1. Please use a propper mail agent that does not strip the code from you
email
2. Try `mvn it.spaghettisource.plugin:pojo:1.0:log` as Maven does not know
where to look for your plugin
On 4 June 2013 15:30, alesky wrote:
> Hi guys
>
> i'm try to implement my first plugin
>
> so i did just a plu
the packaging is `jar` not `test-jar` there is only one artifact with
`test-jar` packaging, namely the `test-jar`
You want to use
org.apache.juddi:**uddi-tck:jar:test-sources
org.apache.juddi:**uddi-tck:jar:test-javadoc
Not a bug
On 4 June 2013 14:02, Kurt T Stam wrote:
> I'm assuming it is
Now just to clarify... this remote server you want to deploy to...
Is it:
a) A Maven Repository
or
b) Something else (e.g. an application server, a website hosting service,
etc)
Thanks
On 31 May 2013 14:50, proverbio wrote:
> Hi all!
>
> Someone can give me some intructions to deploy artifac
You can just package the custom lifecycle in a jar and declare the jar as a
/project/build/extensions/extension
Note:
1. You cannot both produce and consume a build extension from the same
reactor, as the extension that is being produced will affect the build
plan, and the effects will not be know
ependency tree? Aren't dependencies
> always fixed values?
>
> How can I check that?
>
>
> On 29 May 2013 14:34, Stephen Connolly >wrote:
>
> > I would guess you might have a version range in your dependency tree
> >
> >
> > On 29 May 2013 1
I would guess you might have a version range in your dependency tree
On 29 May 2013 13:30, Henri Tremblay wrote:
> Hi,
>
> Some of metadata.xml files are downloaded for every build done from
> Jenkins.
>
> I don't know why. One example is org.jvnet.staxex:stax-ex:1.7.1
>
> -X doesn't tell me an
On 28 May 2013 20:22, Baptiste MATHUS wrote:
> 2013/5/28 Mike Wilson
>
> > > Is this what you are seeing?
> >
> > Sort of. But it seems you have assigned relativePath to a non-
> > empty value, something I think is incorrect in this kind of
> > setup.
> > I believe my setup was described in enou
I think the simplest thing to do is to
write a plugin
This gives you a multitude of advantages.
You get to create the xml file yourself.
You get to package everything out the way you want.
Then create a ZIP of the whole lot and attach that to the reactor.
The ZIP is what your build produc
Sorry wrong link... you want http://bit.ly/18wuQUc
On 28 May 2013 15:41, Stephen Connolly wrote:
> http://bit.ly/18wuJIj
>
>
> On 28 May 2013 15:33, Alberto Ivo wrote:
>
>> Any idea on JBoss 7 AS?
>>
>>
>> Ivo
>>
>>
>> On Tue, May 28, 2
http://bit.ly/18wuJIj
On 28 May 2013 15:33, Alberto Ivo wrote:
> Any idea on JBoss 7 AS?
>
>
> Ivo
>
>
> On Tue, May 28, 2013 at 11:14 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > jetty's is more fun... though you can
jetty's is more fun... though you can hack it with one of the override
methods
On 28 May 2013 15:05, Mark H. Wood wrote:
> On Tue, May 28, 2013 at 02:49:26PM +0100, Stephen Connolly wrote:
> > On 28 May 2013 14:37, Mark H. Wood wrote:
> >
> > > On Mon, May
On 28 May 2013 14:37, Mark H. Wood wrote:
> On Mon, May 27, 2013 at 02:20:15PM -0300, Alberto Ivo wrote:
> > The differences between the web.xml is
> >
> >
> > javax.faces.PROJECT_STAGE
> > *Development | Production*
> >
>
> Shouldn't that sort of information be supplied by the container rathe
what I prefer to do is have developers use an on-demand servlet container,
e.g. jetty or tomcat and then configure web.xml overrides for the app when
deployed using e.g. jetty:run or tomcat:run
but YMMV
On 27 May 2013 16:58, Russell Gold wrote:
> I believe this is quite reasonable. Developers
I think you have hit a bug. Please file a JIRA. If you can provide a test
case or a patch with a test case I can take a look at applying it and
rolling the required releases
On 21 May 2013 15:43, Laura Llewellyn wrote:
> I am having difficulty setting multiple environment variables in my invoke
Closest I can think is add a dependency of type "pom" to fix the build
order and use dependency:copy to grab the jar
On Sunday, 19 May 2013, Benson Margulies wrote:
> I'm faced with a situation I've met before.
>
> I have a multi-module project.
>
> 'Module A' builds a jar file. That jar file is
being marked with @IgnoreJRERequirement)
Most useful for the JRE runtime library, but could also be useful targeting
different versions of the servlet spec, etc.
On 17 May 2013 17:40, Jeffrey E Care wrote:
> Stephen Connolly wrote on 05/17/2013
> 11:49:36 AM:
>
> > That is not
That is not a use case for animal sniffer.
http://mojo.codehaus.org/clirr-maven-plugin/
Or
http://mojo.codehaus.org/jdiff-maven-plugin/
On Friday, 17 May 2013, Jeffrey E Care wrote:
> William Eason > wrote on 05/17/2013
> 11:21:37 AM:
>
> > Yes I've used it. I thought it worked great!
> >
> > On
Aside: in my experience using version ranges in released poms is a serious
anti-pattern. I can just about accept arguments for their use in
development poms, but at release time it is my experience that they should
be pinned to the specific version that the release is performed with
(otherwise the
! I don't suppose someone could try using the
> latest update of JDK 1.7 for me? Otherwise I'll try 1.7u21, when I get a
> chance.
>
> On 14/05/2013, at 10:48 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Not an is
Not an issue for me:
$ mvn -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
13:51:28+)
Maven home: /usr/share/java/maven-3.0.5
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home:
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Def
try the two valid values.
should be possible to configure it via the CLI
e.g.
mvn -DmavenExecutorId=forked-path -Ddry-run=true release:prepare
mvn -DmavenExecutorId=invoker -Ddry-run=true release:prepare
Though if the for the release plugin in your pom.xml or a
parent pom.xml is setting the va
pom.
>
>
> On 05/14/13 10:48, Stephen Connolly wrote:
>
>> Well without seeing your parent tree's xpath:/project/dependencies and
>> your
>> project's xpath:/project/dependencies we cannot say anything as what you
>> have provided there should *never* e
>
> I did not define an explicit dependency to javadoc, but in "mvn
> dependency:tree" I can see it.
>
> Thanks, Sven
>
>
> On 05/14/13 10:18, Stephen Connolly wrote:
>
>> I think you are doing it wrong if you are adding for plugins.
>>
Try the other
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#mavenExecutorIdrather
that the value you are currently using (there are two values
`forked-path` and `invoker`) it may be that a parent pom is setting it
different from the default... in any case it is someth
I think you are doing it wrong if you are adding for plugins.
The xpath:/project/dependencies are about specifying the classpath
dependencies during different scopes. The
xpath:/project/build/plugins/plugin entries are about specifying what build
tools to use when building the artifact... such bui
Why not just create a shell script called mvn that passes through to your
mvn3?
On 14 May 2013 08:31, José Manuel Castroagudín Silva <
chavescesu...@gmail.com> wrote:
> Hi all,
>
> I've started doing some testing about maven-release plugin, and everything
> went fine until the moment of trying i
Yes it uses ANT syntax but when writing out the answer I thought regex
might be easier to understand... Then I changed my mind after sending ;-)
On Monday, 13 May 2013, Jörg Schaible wrote:
> Stephen Connolly wrote:
>
> > Surefire only runs the tests from classes that follow Suref
Be sure you know regex syntax before interpreting the regexes I provided
On 13 May 2013 17:10, Stephen Connolly wrote:
> Surefire only runs the tests from classes that follow Surefire's naming
> convention, i.e. file must match one of the following regexs
>
> Test.*
>
Surefire only runs the tests from classes that follow Surefire's naming
convention, i.e. file must match one of the following regexs
Test.*
.*Test
.*TestCase
On 13 May 2013 17:05, Sven Bauhan wrote:
> Hi,
>
> I am new here with a question I could not a solution yet.
>
> I have about 6 test cla
The local repository cache is by default stored in ~/.m2/repository
In the users or global settings this default can be changed to some other
location. (See in
http://maven.apache.org/settings.html#Simple_Values)
Keep in mind that the cache is not concurrent safe, and is definitely not
designed
On 10 May 2013 12:12, Daniel Pocock wrote:
> On 10/05/13 12:21, Stephen Connolly wrote:
> > On 10 May 2013 10:09, Daniel Pocock wrote:
> >
> >> On 09/05/13 17:21, Manfred Moser wrote:
> >>> Correct. The other thing you want to ensure is your acquisition of
On 10 May 2013 10:09, Daniel Pocock wrote:
> On 09/05/13 17:21, Manfred Moser wrote:
> > Correct. The other thing you want to ensure is your acquisition of the
> > jar. With Nexus (and other repo managers probably) you can connect to the
> > https secured version of Central and enforce checksum v
Stop. Don't do that. ${basedir} means different things depending on whether
the pom is being resolved from the reactor or from the local repository
See this (a long read but you will be rewarded with the shining light of
understanding by the end, we hope)
http://developer-blog.cloudbees.com/2013/
On 9 May 2013 10:44, Stephen Connolly wrote:
> On 9 May 2013 10:15, Daniel Pocock wrote:
>
>> Hi,
>>
>
[snip]
> b) stop if any source JAR contains binary artifacts or if a
>>
> dependency/plugin source is not available?
>>
>
> You could write an
401 - 500 of 2426 matches
Mail list logo
