Re: maven-plugin-testing-harness
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 As far as I can tell, the fix didn't work. I updated the JIRA issue but I was unable to re-open the ticket and I could only leave "internal comments" which aren't publicly visible, despite logging in. What would also be incredibly useful is a link to the wiki for maven-plugin-testing-harness I assume there is one, I just can't find any link to one anywhere. regards Adam -- View this message in context: http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556p5911838.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-plugin-testing-harness
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 users out there who look at it and give up, which is a shame because you can't beat a good test harness. I have managed to put some code together to make my tests run nicely in IntelliJ and I was wondering if you wanted any documentation or example code? I've still got issues and I've got a live question on StackOverflow: https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness Regards Adam -- View this message in context: http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-plugin-testing-harness
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 stumped now because the setup and startup
I've put in place isn't causing maven to set up the test project's classpath
properly, so my resources from the test project (in the actual project's
src/test/resources/my-test-project/src/main/resources dir) are missing.
Does that sound fixable?
Here's what I'm doing in my test:
MojoRule mojoRule = new MojoRule(this);
ClassLoader classLoader = getClass().getClassLoader();
URL url = classLoader.getResource(TEST_POM);
if (url == null) {
throw new MojoExecutionException(String.format(
"Cannot locate %s", TEST_POM));
}
File pom = new File(url.getFile());
MavenSettingsBuilder mavenSettingsBuilder = (MavenSettingsBuilder)
getContainer().lookup(MavenSettingsBuilder.ROLE);
Settings settings = mavenSettingsBuilder.buildSettings();
MavenExecutionRequest request = new DefaultMavenExecutionRequest();
request.setPom(pom);
request.setLocalRepositoryPath(settings.getLocalRepository());
MavenExecutionRequestPopulator populator =
getContainer().lookup(MavenExecutionRequestPopulator.class);
populator.populateDefaults(request);
DefaultMaven maven = (DefaultMaven)
getContainer().lookup(Maven.class);
DefaultRepositorySystemSession repoSession =
(DefaultRepositorySystemSession)
maven.newRepositorySession(request);
LocalRepository localRepository = new LocalRepository(
request.getLocalRepository().getBasedir());
SimpleLocalRepositoryManagerFactory factory =
new SimpleLocalRepositoryManagerFactory();
LocalRepositoryManager localRepositoryManager =
factory.newInstance(repoSession, localRepository);
repoSession.setLocalRepositoryManager(localRepositoryManager);
ProjectBuildingRequest buildingRequest =
request.getProjectBuildingRequest()
.setRepositorySession(repoSession)
.setResolveDependencies(true);
ProjectBuilder projectBuilder =
mojoRule.lookup(ProjectBuilder.class);
MavenProject project =
projectBuilder.build(pom, buildingRequest).getProject();
MavenSession session = mojoRule.newMavenSession(project);
session.setCurrentProject(project);
session.setProjects(Collections.singletonList(project));
request.setSystemProperties(System.getProperties());
testMojo = (GenerateConfig) lookupConfiguredMojo(session,
mojoRule.newMojoExecution("configure"));
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556p5911817.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
How do I get a plugin dependency from the project object in my mojo?
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 that I left the test project doesn't have any dependencies. But part of
the job the plugin has to do is to retrieve a zip dependency and extract a
couple of files.
I use
project.getDependencies()
and loop thro it to find that zip dependency.
If I put the dependency xml in the plugin dependencies, the plugin can't
find it.
If I move the dependency xml to the dependencies for the test project, it
works, but I don't think the dependency should be there. According to the
maven plugin docs
dependencies: Dependencies are seen a lot within the POM, and are an
element under all plugins element blocks. The dependencies have the same
structure and function as under that base build. The major difference in
this case is that instead of applying as dependencies of the project, they
now apply as dependencies of the plugin that they are under. The power of
this is to alter the dependency list of a plugin, perhaps by removing an
unused runtime dependency via exclusions, or by altering the version of a
required dpendency. See above under Dependencies for more information.
So I want the dependency isolated to the plugin. I might want to run the
plugin more than once and use a different dependency.
How can I get the build->plugins->plugin dependency, instead of relying on
the base project?
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
com.testproject
test
1.0.1-SNAPSHOT
com.my-new-plugin
my-maven-plugin
1.0.0-SNAPSHOT
package
configure
com.testproject
configuration
1.0.1
zip
common.properties
my-test.properties
my-test-env.yml
com.my-other-dep
configuration
config-test
.*/config/deployment/ansible/Dockerfile.*
false
${project.basedir}/src/main/config/deployment/ansible
${project.build.directory}/ansible
.*/config/deployment/docker_comm.*
true
${project.basedir}/src/main/config/deployment
${project.build.directory}/docker-commands
.*/config/deployment/ansible/.*
.*/config/deployment/ansible/Dockerfile.*
false
${project.basedir}/src/main/config/deployment/ansible
${project.build.directory}/ansible
.*/config/ds-workflow.properties.*
true
${project.basedir}/src/main/config
${project.build.directory}/ds-config
--
View this message in context:
http://maven.40175.n5.nabble.com/How-do-I-get-a-plugin-dependency-from-the-project-object-in-my-mojo-tp5912070.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-plugin-testing-harness
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: https://stackoverflow.com/questions/45241317/hard-time-mojo-testing-with-maven-plugin-testing-harness/45833419#answer-45833419 Sorry if the question title betrays my frustration. The limited feedback I got here on this user list was also surprising. Obviously with no feedback to speak of, I have no idea why no-one from the maven community wanted to communicate on this subject. I would of course be grateful now to get some feedback of any kind. I'm not asking for anyone to spend more than a minute to write a reply - I have essentially finished my work with the testing harness. Why was it so difficult? Are the inner workings all in the process of re-development for maven 4? -- View this message in context: http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556p5912964.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
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 for
> it...which can be easily done by using a maven-artifact-transfer[3].
>
> [3]:
> https://maven.apache.org/shared/maven-artifact-transfer/install-project.html
I wasn't able to get the maven-artifact-transfer to function in my mojo. I
resorted to Aether's RepositorySystem.resolveArtifact() method.
Karl Heinz Marbaise-3 wrote
Presumably I call something like
project.getPlugin(key).getDependencies()?
If the 'key' required for project.getPlugin(key) is of the form
myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2
can I get my mojo's own key programmatically in the mojo to avoid
hard-coding it?
This is the last issue I'm facing (famous last words.)
I currently hard-code my plugin's key so I can obtain it while the mojo is
in action:
Plugin plugin = project.getPlugin("com.megacorp.stuff:my-plugin");
plugin.getDependencies()..
but I'd like to avoid that in case my successor decides to rename it or
something similar.
How can I the key programmatically, by reaching deep into the mojo?
Regards
Adam
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-plugin-testing-harness
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 it out when we upgrade maven and my tests break. -- View this message in context: http://maven.40175.n5.nabble.com/maven-plugin-testing-harness-tp5911556p5913035.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Auto-increment semantic version number for CD pipeline with git and docker
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 number shouldn't be switched back and forth between -SNAPSHOT and non-snapshot. The CI server should run the tests and verify that they pass and if so, merge or rebase the checkin into the master. Apologies for the long pause before answering! Too much firefighting. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Auto-increment semantic version number for CD pipeline with git and docker
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 commit is a release candidate. My goal is to get maven to increment the build number on each build - the build number shouldn't be switched back and forth between -SNAPSHOT and non-snapshot. The main aim is to keep it simple, v2.1.3 -> v.2.1.4 -> v2.1.5 etc so dealing with -SNAPSHOT gets in the way. The CI server will run the tests and verify that they pass and if so, merge or rebase the checkin into the master somehow via maven. That blog post by Stephen hits it square between the eyes - although in my case to get rid of -SNAPSHOT, I'll probably need to write a plugin to run the git plugin through the required steps. Surprised it doesn't exist already, IMHO semantic versioning is clearly more desirable than the git commit hash. A maven plugin probably does, but is just not widely publicised. Sorry for the long pause before answering. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Auto-increment semantic version number for CD pipeline with git and docker
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 commit is a release candidate. My goal is to get maven to increment the build number on each build - the build number shouldn't be switched back and forth between -SNAPSHOT and non-snapshot. The CI server should run the tests and verify that they pass and if so, merge or rebase the checkin into the master. That blog post by Stephen hits it square between the eyes - although in my case to get rid of -SNAPSHOT non-versions, I'll probably need to write a plugin to run the git plugin through the required steps. Surprised it doesn't exist already. Probably does, but just not widely publicised. Apologies for the long pause before answering! Too much firefighting. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Handling password
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Handling password
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
by searching the code base for instances of 'username'.
However, maven-resources-plugin fails to substitute the last property
because it comes after the '@' sign:
Acquire::http::Proxy "http://${proxy.username}:${proxy.pw}@${proxy.host};;
Can I do anything about that?
Regards
Adam
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Auto-increment semantic version number for CD pipeline with git and docker
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 it in maven on the CI server builds
>From what I read online, this is beginning to sound like alchemy. There seem
to be several blockers.
How can I tell maven to increment the version and commit the edited pom
without the CI platform seeing the commit and kicking off again in an
infinite loop? I can't see any way of doing it without branching and
merging/rebasing.
My second main issue that I wonder about is: a developer commit may pass all
its tests and reach the maven deploy phase, at which point the automated CI
job wants to commit the updated pom with the incremented version - but it
might come after a second developer commits. This also points to branching
and then merging.
I can sympathise with all the continuous delivery / microservices / devops
bloggers who have posted their articles about version numbers with
${code.branch}.${commit.date}.${build.number}.${sha1} but I can't help
seeing that solution as a work-around which makes it impossible to remember
what version you're on.
Have I missed something when searching the net for the last couple of hours?
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
ServiceLoader not loading FileTypeDetector implementation in jar
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 can't find or load my implementation and keeps defaulting back to the JDK's RegisterFileTypeDetector. I have double checked that the utility jar is in my classpath with dependency:tree, contains the META-INF/services/java.nio.file.spi.FileTypeDetector file naming my implementation, and also the actual implementation class. The JDK javadoc documentation claims that it will seek it out anywhere on the application's classpath: https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html but I only see it searching on the system classpath during debugging. My efforts are hampered by the use of nested arrays of Enumeration with sun.misc.CompoundEnumeration. It's really convoluted and I haven't been able to see where it fails. What could I be doing wrong? -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Unexplained sudden loss of access to repository on build server
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 using the AbstractMojoTestCase#getTestProject() method.
I specified a particular dependency required only by the mojo in the plugin
dependency block in the test project pom.xml.
This all worked fine and maven retrieved the dependency and the tests ran.
Now suddenly, the tests break on the build server because maven is ignoring
the settings.xml configured for the build, and is searching
repo.maven.apache.org for the test dependency.
Locally it still works fine.
I have worked around it by adding the repository definitions from
settings.xml into the test pom.xmls directly, but obviously that's
undesirable from a maintenance perspective.
This is what it's doing:
/**
* Injected from Plexus container on start.
*/
@Component
private RepositorySystem repositorySystem;
/**
* The current repository/network configuration of Maven.
*/
@Parameter(defaultValue = "${repositorySystemSession}", readonly = true)
private RepositorySystemSession repositorySystemSession;
And then I'm resolving my desired artifact like this:
ArtifactResult result = repositorySystem.resolveArtifact(
repositorySystemSession,
new ArtifactRequest(
new DefaultArtifact(groupId, artifactId, null,
type, version),
project.getRemoteProjectRepositories(),
null));
configArtifact = result.getArtifact();
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: ServiceLoader not loading FileTypeDetector implementation in jar
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: ServiceLoader not loading FileTypeDetector implementation in jar
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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ServiceLoader not loading FileTypeDetector implementation in jar
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 from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Anything in pipeline to add functionality to read pom in different formats?
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. Instead of being bothered or dis-inhibiting themselves from seeing maven as it should be seen, they say "because it is XML". Sometimes I think they'd rather use ant or shell script to do their builds, or just go with gradle or ivy because someone cool mentioned them. This leads me naturally to ask, does anyone have any plans to write a maven pom reader that can read YAML or even JSON or any other potential non-XML format? Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Anything in pipeline to add functionality to read pom in different formats?
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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven jobs, groovy, git and jenkins pipelines
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 and deployment configuration and that Jenkins with its plugins is actually secondary, and in a 'pure' maven configuration could be any build platform like TeamCity, Bamboo etc? I can't see any great advantage to using Jenkins pipelines except to prettify the visuals on the build server. Have I missed something or is there a Jenkins killer plugin that does stuff which maven can't? Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Distribution management
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 files which are versioned, and I can't put the xml in the settings.xml. I only see two alternatives: - I declare the distributionManagement xml for my team in a parent pom which I deploy on an updateable repository where we do not have to increment the version - I provide everybody with the command line script snippet to do the deploy manually Both of these alternatives have drawbacks. If there is another way of keeping the distributionManagement out of the versioned poms? If not, why don't I understand the paradigm? It makes little sense to me that a change in the environment (the repository URLs) should force a version change in all projects under development. Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Distribution management
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 indirection won't hurt. Karl Heinz Marbaise-3 wrote >> If not, why don't I understand the paradigm? It makes little sense to me >> that a change in the environment (the repository URLs) should force a >> version change in all projects under development. > > Because it represents an different state of the environment in time > which is recorded in a version control... That's clear, but it doesn't explain why Maven was designed to allow unversioned download repositories changes, while making it difficult by default not to version distribution repository changes. i.e. I still don't understand why Maven does not allow the distributionManagement xml in the settings.xml It really does look like an oversight - if it hadn't been unchanged for a decade. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Not able to read jars in repo intermittently
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 has to download all required jars to the local repo from our proxy. The Jenkins team have set up their build servers to run on 4 hosts. I don't know much about Jenkins but I figure that it must be automated - is there a maven operation they could carry out to clone at least the most heavily used artefacts in the Artifactory repo to the local hard drive? That would eliminate the individual build job clashes on the jars in the local repo like commons-io. -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Not able to read jars in repo intermittently
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 these errors are caused by poor file handling by the underlying OS (Windows here), or is it maven itself? Is there a known issue for what's being discussed? Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Specify alternate extensions.xml?
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 else (esp. extensions.xml) In my case, the Jenkins job will crash because I'm using yaml in my pom with the io.takari.polyglot:polyglot-yaml extension - the Jenkins jobs seem to be oblivious to the extensions.xml file. I'm not totally sure about this but that's what it looks like from the exception: Parsing POMs ERROR: Failed to parse POMs hudson.remoting.ProxyException: hudson.maven.MavenModuleSetBuild$MavenExecutionException: org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Non-parseable POM /home/jenkins/workspace/adam/adam-maven-plugin/pom.yml: only whitespace content allowed before start tag and not m (position: START_DOCUMENT seen m... @1:1) @ line 1, column 1 at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1391) The work-around I'm using at the moment is to create Jenkins pipeline jobs instead of simple Jenkins maven jobs, so that Jenkins launches mvn in a full shell (I think), the difference being that stand-alone mvn will then read the extensions.xml. I have thought of putting io.takari.polyglot:polyglot-yaml.jar into maven/lib/ext - but I'm not sure the Jenkins sysadmins in my organisation would want to do that. My hope is that there is a command line option that will be passed to maven through the Jenkins/hudson plugin that will instruct the maven core to fetch that extensions.xml. Regards Adam -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
