On 26/07/17 20:13, Karl Heinz Marbaise wrote:
>> and the link to git repo is 404
>
> https://github.com/apache/maven-plugin-testing
>
> but it's out of date correct...
>
> I have created an appropriate INFRA ticket to fix this[1].
>
>
> [1]: https://issues.apache.org/jira/browse/INFRA-14716
Is there life is in this testing harness still?
I'm looking at
https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/
The link to JIRA returns 503 -
http://jira.codehaus.org/browse/MPLUGINTESTING
and the link to git repo is 404
I can imagine there is a big population of maven
On 26/07/17 11:49, ahardy42 wrote:
> Is there life is in this testing harness still?
>
> I'm looking at
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/
Hi All,
while I've made a lot of progress with my plugin testing with the
maven-plugin-testing-harness, I'm
I've got another question about mojo development.
Sorry for cross-posting, but I've put it here too:
https://stackoverflow.com/questions/45552953/how-do-i-get-a-plugin-dependency-in-my-mojo
I created a maven plugin and I implement my plugin in the projects where I
need it like below.
Note
After a concentrated stint of experimentation, I have setup my tests using
the maven-plugin-testing-harness so that the tests run with a live remote
repository and have all the resources provided in the target/test-classes
directory.
The solution is here:
Karl Heinz Marbaise-3 wrote
>>I thought I could just enter it once as a plugin dependency in
>> the user project pom - assuming it would be the only one.
>
> You can give this via the plugin configuration and which means your
> plugin must resolve it's dependencies and make a required download
maven-invoker-plugin looks very useful, but it just adds to the frustration
that the maven website guided me down this path with
maven-plugin-testing-harness without a single mention of
maven-invoker-plugin.
you might want to put a link in there in the "my first mojo resources"
section.
I'll try
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
I don't want to use snapshot versioning at all.
These projects are microservices so every code commit is a release
candidate. My goal is to get maven to increment the build number on each
build - the build
V. interesting, thanks.
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job.
These projects are microservices so every code
V. interesting, thanks.
I'm using TeamCity so controlling an infinite loop using trigger configs
should be easy.
However I don't want to use snapshot versioning at all, so the
maven-release-plugin is essentially not the right tool for the job.
These projects are microservices so every code
Robert Scholte-8 wrote
> Is ${settings.proxies[0].username} an options?
>
> Robert
Thanks Robert but no, that doesn't work.
Seems that maven-resources-plugin can't dereference lists or arrays.
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
After a bit of creative thinking, I put the username:password into variables
in a profile in the settings file and let maven substitute them into the
file at build time. Now the security issue is a problem for the person
maintaining the CI server - which is me too but at least no-one will find it
The projects I'm working on are migrating towards a micro-services
architecture and my aim is to find a way to implement:
- auto-increment the version number
- semantic versioning (3.1.99, 3.1.100, 3.1.101 etc)
- using the maven pom version as the master or source version number
- running
I created, tested and packaged a java.nio.file.spi.FileTypeDetector
implementation in a utility jar for use by Files.probeContentType(path).
So it works beautifully in my utility project.
I'm now trying to use it in another project but despite hours of trying, I
can't work out why the JVM
I'm testing parts of my mojo in an integration test and for months this
worked fine locally and on the build server (Teamcity).
I specified our company's artifactory repository in the settings.xml
I created a test project in the src/test/resources/my-test-project directory
and referred to it
System.getSecurityManager().checkPermission(new
RuntimePermission("fileTypeDetector"));
is not possible.
System.getSecurityManager() returns null.
Regards
Adam
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
I tried checking in my code and lo, the tests pass on the CI server
(teamcity), i.e. on teamcity the classloader finds my FileTypeDetector in
the dependency jar.
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
Actually there is a third scenario that might be relevant.
It fails in Intellij's maven env.
It works in teamcity's maven run.
It fails in the maven plugin where it is used by my mojo, in Intellij.
The 4th scenario is the teamcity build using my mojo. Haven't tried that
yet.
--
Sent
Hi All,
as a loyal maven user I appreciate maven for all it does and give kudos to
all the people who helped build it. Thought I'd say that before I ask my
question in case you think I'm trolling.
My main problem with maven is colleagues. I constantly hear complaints about
maven being horrible.
That meets the definition of 'paradigm shift'. Comments from colleagues:
"That is so much clearer isn't it?"
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail:
Hi All,
I started working with a Jenkins pipeline and I am still building my mental
picture of how maven, git, groovy and Jenkins really work together - fyi I'm
using OpenShift / Kubernetes as the deployment platform.
Am I correct in thinking that actually maven could achieve 95% of the build
Hi maven-users,
it seems this issue was last discussed almost 10 years ago but despite
reading the docs and the email lists there is still an issue with
distribution management that I don't understand.
I do not wish to declare our company's internal release and snapshot
repositories in pom
Karl Heinz Marbaise-3 wrote
> The distributionManagement should be offered by a company parent pom
> which handles this...and it is a good idea to use placeholders here to
> have chance to change that in particular with CI environments which can
> control this...
OK that's workable. One layer
A week ago I asked about an issue where multiple builds were downloading to
the shared local repo and causing corruption in random jars.
My company's Jenkins team are offering the solution of running my own
private repo to avoid this, but this radically increases build times because
each build
Can I just verify the problem?
These affected jars are frequently used, and have been there for a long
time, e.g.
/home/jenkins/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar
There should be no writes going on to this or other affected jars by any
processes on the maven repo.
Are
I see from mvn --help that there's a way to specify alternate settings.xml or
toolchain.xml files.
Is there an equivalent for extensions.xml?
My use-case is on Jenkins. The Jenkins maven and freestyle job types seems
to pluck the pom.xml out of the project without any reference to anything
26 matches
Mail list logo
