RE: plugin for soapui
There is also a "mock" goal. The mock goal configuration is described here: http://www.soapui.org/Test-Automation/maven-2x.html#5-4-eviwaresoapuimock-settings -Original Message- From: Jorge Infante Osorio [mailto:jorg...@uci.cu] Sent: Wednesday, June 26, 2013 7:59 PM To: 'Maven Users List' Subject: RE: plugin for soapui Yes I know: eviware maven-soapui-plugin 3.6.1 myTests test test . But it´s for Integration test during the tests. It doesn´t fix in my requirement. Saludos, Ing. Jorge Infante Osorio. CDAE. Fac. 5. UCI. "En un mundo perfecto las pizzas serían una comida saludable, las laptops se cargarían desde una fuente de corriente inalámbrica y todos los JAR serían bundles de OSGI " -Mensaje original- De: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] En nombre de Anders Hammar Enviado el: miércoles, 26 de junio de 2013 15:35 Para: Maven Users List Asunto: Re: plugin for soapui There is already a soapUI maven plugin. Talk to the soapUI people! /Anders On Wed, Jun 26, 2013 at 8:01 PM, Martin Gainty wrote: > Guys- > > we used SOAPUI every day at the bank to test our web-services > > if we can get our hands on SOAPUI source we could create a plugin to > auto-launch 1)a configurable wsdl to > 2) a configurable SOAP endpoint using > 3)configurable SOAP Headers with > 4)user-supplied SOAP-Body > > definite potential for a maven-plugin! > Martin Gainty > __ > Jogi és Bizalmassági kinyilatkoztatás/Verzicht und > Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Ez az > üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy > jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának > készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál > és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus > üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem > terhelhet ezen üzenet tartalma miatt. > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede > unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. > Diese Nachricht dient lediglich dem Austausch von Informationen und > entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten > Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes > pas le destinataire prévu, nous te demandons avec bonté que pour > satisfaire informez l'expéditeur. N'importe quelle diffusion non > autorisée ou la copie de ceci est interdite. Ce message sert à > l'information seulement et n'aura pas n'importe quel effet légalement > obligatoire. Étant donné que les email peuvent facilement être sujets > à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > > > > From: wayne...@gmail.com > > Date: Wed, 26 Jun 2013 12:25:15 -0500 > > Subject: Re: plugin for soapui > > To: users@maven.apache.org > > > > > My question is if I can do the same using maven? Generate the war > > > file > of > > > this mock web service using some maven plugin. > > > > I would ask the same question on the soapui list, to see if they > > have a Maven plugin that supports your use case. > > > > Wayne > > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency in the local repository is ignored
If this is a multi-module project, and you run eclipse:eclipse, I'm fairly sure eclipse will resolve the dependency as a project dependency, not a library dependency. Look in your Build Path and select the Project tab to see if the dependent project is there. -Original Message- From: Alex [mailto:zeita...@googlemail.com] Sent: Tuesday, March 06, 2012 12:04 PM To: Maven Users List Subject: Re: Dependency in the local repository is ignored Thanks a lot for all answers. > What do you mean by ignored? Explain this in more detail. I compile and install jar from one project and using it in another project. It is installed in local repository but it is not included into .classpath . There are all external dependencies but not my own jar. >What is the exact command line you used to install? To build and install my jar into local repository I use just "mvn clean", "mvn install" or from eclipse m2e's menu "install" to include my jar into the eclipse's ".classpath" file of the other project I use: mvn eclipse:clean mvn eclipse:eclipse >Have you tried: >1) mvn -X eclipse:eclipse and seeing if any of the debug reports >removing or ignoring it >2) backup .classpath .project and .settings then recreating >3) Checking and older version in source control >4) New instance of Eclipse I tried all from above except mvn -X eclipse:eclipse. I will try it tomorrow when I will get access to working computer. Alex - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Cobertura instrumentation in complex projects
I've done exactly this and it's a pain. I didn't want cobertura-instrumented jars from possibly infecting our production jars, so I have a Jenkins project that uses a private maven repo to build the entire product. The final deliverable has a "cobertura" classifier and this is deployed to Artifactory. Another Jenkins project runs daily to pick up this artifact and deploy it to our integration test server. However, all this is only the start of your problems. Getting cobertura data files from the integration server in an automated fashion is very hard. I had to write a web service to fetch the data from the (well documented) cobertura static class and return it to the caller. After my integration test cases run, a maven plugin I wrote fetches that data, and I use the Jenkins cobertura plugin to turn it into html reports. I'm in the process of scrapping all that in favor of jacoco which instruments the code on-the-fly via a javaagent running in the container. -tim -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Tuesday, March 06, 2012 12:00 PM To: 'users@maven.apache.org' Subject: Cobertura instrumentation in complex projects Hello all, I have a fairly large build in which we use cobertura extensively to look at unit test code coverage for our project. We also have separate integration tests that we would like to run using these instrumented binaries. There is some good documentation on how to accomplish that here: http://mojo.codehaus.org/cobertura-maven-plugin/instrumentingDeploymentArtifact.html While that would work for a simple case, I'm struggling with trying to visualize how this would work in a complex case. We have several separate builds that accumulate to make up the install package that we then push to our integration testing systems. So everyone one of our couple hundred jar's which are fed from all these builds would need to be published to a Maven repository so that the install builds could pick them up. But if I push them to my standard SNAPSHOT repository it would overwrite my existing non-instrumented versions. We only envision needing this run on a nightly basis. One suggestion that has been proposed is to do the "publish with classifier" thing and a profile that turns on cobertura. https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html Frankly, I'm not sure how that plumbing would work at this point, but I suppose it's possible. Having said that, I think we just got done having that conversation on this list and the answer is that that is "not the maven way". I'm positive I'm not the first one in this boat. Any thoughts? -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependency in the local repository is ignored
If you already have eclipse projects set up, try running: mvn eclipse:clean eclipse:eclipse -Original Message- From: Alex [mailto:zeita...@googlemail.com] Sent: Tuesday, March 06, 2012 10:28 AM To: users@maven.apache.org Subject: Dependency in the local repository is ignored Dear All, I am looking for a solution since several days already. The problem: All of a sudden one of my dependencies is ignored. I am installing it using mvn install And when I am running mvn eclipse:eclipse It is not listed in the Referenced Libriries node although it is present in the local repository. I installed the newest releases of maven, eclipse, m2eclipse. Please, please help Alex - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: compiler errors hidden when building Maven project on Jenkins
>And the OP is probably using the "evil" Maven project type and not a >freestyle project with a maven build step I am. Is this bad? -tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
compiler errors hidden when building Maven project on Jenkins
I've asked this question on the Jenkins email list a week ago (where I think it belongs) and on StackOverflow, but I've gotten no results. I know this isn't a Maven issue per se' because a local build does show compiler syntax errors, but I'm at wits end and hoping someone on this list may have seen this issue before and offer some insight. I've posted this question to StackOverflow here: http://stackoverflow.com/questions/9229020/jenkins-not-showing-maven-compiler-errors I'll summarize here, but to see full output I hope you wouldn't mind clicking that link - the output is long and better encapsulated there then in this email. When Jenkins 1.450 builds my maven 3 project, if there are compiler errors all I get is an exception from the maven-compiler-plugin (2.0.2) and not the actual syntax errors you usually see. When building locally, you _do_ get the syntax errors. Jenkins used to show the compiler syntax errors but stopped doing so about two weeks ago. What changed? We switched from maven 2.2.1 to maven 3.0.4, but I'm fairly certain we got compiler errors in the output just after the switch (but can't verify this). I found a similar (possibly the same) issue on Jenkins' Jira: https://issues.jenkins-ci.org/browse/JENKINS-10333 but no action had been taken. Has anyone else seen this? Is this a Jenkins issue or a Maven issue (or both)? -tim Tim Drury Architect SAP Manufacturing Execution (SAP ME) Supply Chain Management SAP Labs, LLC T +1 404 943 2088 F +1 610 492 2257 mailto:t.dr...@sap.com www.sap.com Please consider the impact on the environment before printing this e-mail.
RE: skip cobertura for a module
I just looked at the cobertura maven source the other day, so I took another look. skipMojo() is the first call in the instrument plugin and if skip is true it should log at INFO level: "Skipping cobertura execution" While I don't have a solution to your issue, I can tell you that cobertura is definitely running on this module. -tim -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Monday, December 12, 2011 2:20 PM To: 'users@maven.apache.org' Subject: skip cobertura for a module Hello all, I tried posting this on the codehaus user list but it won't accept my e-mails. So let's try here: I'm having an issue with the cobertura plugin. I have a muti-module build that I invoke like this on a nightly basis: mvn install site:site findbugs:findbugs cobertura:cobertura Now all of the modules in the build should build using cobertura, except one. We have some custom stuff that is not entirely the "Maven way" and want to ignore it for the sake of running cobertura (it does not contain code anyway). Here's where I start hitting trouble. It seems that I cannot get the skip to work. It always at least runs the prepare. It's not corbertura that's failing (one of our in house plugins unfortunately), but I don't want that prepare to run at all. Ideally I would just use a skip like this: org.codehaus.mojo cobertura-maven-plugin true But when I put that in, it still invokes cobertura. At least I see it say this: [INFO] Preparing cobertura:cobertura And it proceeds to run all the other plugins again. To be pedantic, I tried this as well: org.codehaus.mojo cobertura-maven-plugin true clean check cobertura dump-datafile instrument But that had similar results. I also tried putting this property in the pom: true Again, that did not stop it from running the prepare bit. It seems to always run the prepare. How do I turn cobertura off for this one module? -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
