Re: Maven Dependencies Pop Quiz
Kind of frustrating to not be shown my score at the end... On Thu, Mar 26, 2020 at 1:01 PM Andres Almiray wrote: > > Hello everyone! > > If I can ask you for 15 minutes of your time, I've put of a 14 question pop > quiz on dependency resolution. I'm hopeful that this quiz will let us > realize a few things about the dependency resolution mechanism and its > rules, perhaps address concerns in the future and make Maven better as a > result. > > The quiz can be found at https://bit.ly/maven-dependencies-popquiz and is > totally anonymous (no email address collected). Unless you feel like > sharing your name ;-) > > Some preliminary numbers to this date: > > - 3 people have 13 correct answers > - 3 people have 12correct answers > - 10 people have 11 correct answers > > The current median is 8. Some quick feedback left: > > - pretty tricky, even for an almost 20 year maven dude. good job! > - I've never seen documentation on this > - Good food for thought. I guess I generally hope Maven does what I expect > and when it doesn't, I start specifying more exactly what I want. > > Please feel free to share it with your colleagues and friends. More entries > mean more data and better results. Thank you! > > Cheers, > Andres > > --- > Java Champion; Groovy Enthusiast > http://andresalmiray.com > http://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, and > those who don't. > To understand recursion, we must first understand recursion. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How do I skip site-generation for modules?
configure m-site-p:site:skip via property, then in parent set to false, and children set to true https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#skip or create a separate module called docs or site or something, and only produce the site in that module On Thu, Nov 8, 2018 at 2:18 PM Russell Gold wrote: > > And at the same time, I would like to copy to the site directory some files > that were generated during the build (and are now in one of the module jars). > > > On Nov 8, 2018, at 1:31 PM, Russell Gold wrote: > > > > I want to generate a site for my multi-module project only from the > > top-level. How do I tell maven to skip running the site plugin on each > > module? > > > - > 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: From none maven project to maven project
Without knowing any details about your project, I have no idea. Maybe you already keep your source code in src/main/java? Maybe you already have some scripts to download dependent libraries instead of using some lib/ directory? Maybe you have a simple JAR project and not a complex WAR project with a ton of dependencies? With the level of details you've provided, we're not going to be able to help you too much. Add a basic pom.xml, and try to build. Fix the things that don't work. I generally can Maven-ize a project pretty quickly, usually in less than an hour. https://maven.apache.org/guides/introduction/introduction-to-the-pom.html https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html On Tue, Nov 6, 2018 at 9:11 AM Eng. Bilal Ghayad wrote: > > Adding pom.xml is the minimum requirements, and what could be the other > requirements? > Because I need to know if I started the project as native (not maven) so how > to convert to maven? > > Regards, > Bilal > > -Original Message- > From: jieryn [mailto:jie...@gmail.com] > Sent: Tuesday, November 6, 2018 3:19 PM > To: Maven Users List > Subject: Re: From none maven project to maven project > > Adding the pom.xml is the minimum requirement. Try it and see.. > > On Tue, Nov 6, 2018 at 7:08 AM Eng. Bilal Ghayad wrote: > > > Hello All; > > > > > > > > If my project is not maven (native) and I need to make it maven, all what > > I need is to add the pom.properties and pom.xml files? > > > > Or I have to restructure the project folders same as maven folders > > structure? > > > > > > > > Regards, > > Bilal > > > - > 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: From none maven project to maven project
Adding the pom.xml is the minimum requirement. Try it and see.. On Tue, Nov 6, 2018 at 7:08 AM Eng. Bilal Ghayad wrote: > Hello All; > > > > If my project is not maven (native) and I need to make it maven, all what > I need is to add the pom.properties and pom.xml files? > > Or I have to restructure the project folders same as maven folders > structure? > > > > Regards, > > > -- > > > > *Eng. Bilal Ghayad* > Mob: +96171113391 > Tel: +9615806234 > > Fax: +9615806234 > > P.O.BOX 14-6306, Beirut – Mazraa, LEBANON > > Web: www.ghayad.com > Email: bi...@ghayad.com > > Please consider the environment before printing this email. > Disclaimer: This message and any attachments are confidential and intended > solely for the addressee(s). > Any unauthorized use is prohibited. Ghayad is not liable for the message > if altered, changed or falsified. > > >
Re: [ANN] Apache Maven Version 3.6.0 Released
Congratulations, and thanks! On Thu, Nov 1, 2018 at 7:53 AM Karl Heinz Marbaise wrote: > > The Apache Maven team is pleased to announce the release of the Apache > Maven 3.6.0. > > Apache Maven is a software project management and comprehension tool. Based > on the concept of a project object model (POM), Maven can manage a > project's build, reporting and documentation from a central piece of > information. > > You can find out more about Apache Maven at https://maven.apache.org > > You can download the appropriate sources etc. from the download page: > https://maven.apache.org/download.cgi > > Release Notes - Apache Maven Version 3.6.0 > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12338966 > > Code Contributors of this release: > > * Christoph Kunze > * David Churcher > > Issue Reporters of this release: > > * Richard van der Hoff > * Jörg Sesterhenn > * Andreas Sewe > * David Churcher > * Adam John Burley > * Alexander Griesbaum > * Christoph Amshoff > * Seckin Onur Selamet > * Phillip Webb > * John Canny > * Hoa Phan > > Many thanks to contributors and reporters for the support and time. > > Participants to the VOTE of the Maven 3.6.0 Release: > > * Filipe Sousa > * Eric Lilja > * Enrico Olivelli > * Gary Gregory > * Thomas Collignon > > Many thanks to those who tested the Maven releases > and thanks for their support as well. > > Release Notes for Apache Maven 3.6.0 > > > https://maven.apache.org/docs/3.6.0/release-notes.html > > Bugs: > > * [MNG-6311] - Maven intolerably slow when import scope used heavily in > large project > * [MNG-6358] - Maven build should not require access to apache.org > * [MNG-6383] - ProjectBuilder unnecessarily rebuilds modules with > ci-friendly versions > * [MNG-6412] - Exceeding project discovery time when using CI friendly > versions > * [MNG-6415] - Project Artifacts Cache does not retain the order of > classpath entries. > * [MNG-6472] - Mockito cannot mock this class: interface > org.eclipse.aether.impl.RepositoryEventDispatcher > * [MNG-6490] - Maven shall not fail reporting circular dependency when the > dependency is a classified secondary artifact > > Improvements: > > * [MNG-4508] - No way to avoid adding artifactId to site urls > * [MNG-5951] - add an option to avoid path addition to inherited URLs > * [MNG-6059] - Important use cases not covered, as child.inherit.append.path > affects all children > * [MNG-6164] - Collections inconsistently immutable > * [MNG-6391] - Printout version of last built module in reactor build > * [MNG-6414] - Add more Apache license header patterns to skip downloading > Apache license > * [MNG-6467] - Remove plugin definition from pom file which is inherited > * [MNG-6480] - Eclipse.org site is down, and you are unable to build Maven? > * [MNG-6492] - Minor improvement on Array construction, converson > > Task: > > * [MNG-6475] - Remove guava dependencies > > Dependency upgrades: > > * [MNG-6424] - Upgrade plexus-interpolation to 1.25 > * [MNG-6449] - Upgrade parent to 32 > * [MNG-6473] - Update Mockito to 2.21.0 > * [MNG-6478] - Upgrade parent to 33 for sha512 checksum on release > * [MNG-6479] - Upgrade XMLUnit to 2.2.1 > * [MNG-6486] - Upgrade to Wagon 3.2.0 > * [MNG-6489] - Upgrade Maven Resolver to 1.3.0 > * [MNG-6491] - Upgrade commons-lang3 to 3.8.1 > * [MNG-6496] - Upgrade Maven Resolver to 1.3.1 > * [MNG-6497] - Upgrade guice to 4.2.1 > > Enjoy, > > - The Apache Maven team > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need advice to put my bootstrap template in Maven archetype web app
You said you wanted to create a maven web project. Forgive me, I interpret that to mean a web application. I'm not familiar with any official or unofficial way to create a 3rd party bootstrap project. I presume you mean http://getbootstrap.com/ Bootstrap. Finally, your use of Maven archetype in the original subject may be confusing other folks that want to assist, because that term means you are creating a Maven Archetype which can be used to materialize example projects. This doesn't seem unfit with your suggestion about creating a bootstrap template, either. So really it's quite confusing what you're asking, perhaps you can try again. On Thu, Nov 1, 2018 at 12:55 AM Karen Goh wrote: > > > ---- > On Tue, 10/30/18, jieryn wrote: > > Subject: Re: Need advice to put my bootstrap template in Maven archetype web > app > To: "Maven Users List" , karenwo...@yahoo.com > Date: Tuesday, October 30, 2018, 8:31 PM > > https://maven.apache.org/plugins/maven-war-plugin/usage.html > > Hi Jieryn, > > Just to clarify, so I have to place the WebContent folder which contents all > my bootstrap css etc under the resources ? > > I am confused cos the title is how to WAR plug in where is my question is > more on the Maven structure directory usage for 3rd party bootstrap template. > > > On > Sun, Oct 28, 2018 at 4:37 AM Karen Goh > wrote: > > > > Hi, > > > > I have been > struggling for 2 days where to put my bootstrap template > that comes with pre-build template which includes css, fonts > etc. inside my maven web project without success. > > > > The problem - jsp is > not rendering the bootstrap layout. It was rendering ok > before I changed the project structure which meets the Maven > project standard structure. > > > > This is a 3rd party bootstrap template. > > > > After reading up the > maven project structure, I have tried to put it under > src/main/resources, tried under src, tried moving around all > parts of the directory but to no avail > > > > I also used the below > structure to move my WebContent which included this template > but it is still not working > > > > > https://stackoverflow.com/questions/15529184/where-to-place-twitter-bootstrap-files-in-a-maven-project > > > > Here's my pom.xml > : > > > > https://ibb.co/fesnGV > > > > https://ibb.co/m7GQ3A > > > > > > > Here's where my bootstrap ended now (still not working) > - where I put the jsp files and WebContent separately. > > > > https://ibb.co/fKArbV > > > > Please tell me where > should I put the bootstrap template. > > > > Thank you & regards, > > Karen > > > > > > > > > - > > 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 > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Need advice to put my bootstrap template in Maven archetype web app
https://maven.apache.org/plugins/maven-war-plugin/usage.html On Sun, Oct 28, 2018 at 4:37 AM Karen Goh wrote: > > Hi, > > I have been struggling for 2 days where to put my bootstrap template that > comes with pre-build template which includes css, fonts etc. inside my maven > web project without success. > > The problem - jsp is not rendering the bootstrap layout. It was rendering ok > before I changed the project structure which meets the Maven project standard > structure. > > This is a 3rd party bootstrap template. > > After reading up the maven project structure, I have tried to put it under > src/main/resources, tried under src, tried moving around all parts of the > directory but to no avail > > I also used the below structure to move my WebContent which included this > template but it is still not working > > https://stackoverflow.com/questions/15529184/where-to-place-twitter-bootstrap-files-in-a-maven-project > > Here's my pom.xml : > > https://ibb.co/fesnGV > > https://ibb.co/m7GQ3A > > > Here's where my bootstrap ended now (still not working) - where I put the jsp > files and WebContent separately. > > https://ibb.co/fKArbV > > Please tell me where should I put the bootstrap template. > > Thank you & regards, > Karen > > > > - > 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: maven-license plugin's license-list
The plugin ships with a bunch of licenses it can use to control the license information in your source files. You can always add more licenses (two files) and have the plugin keep your license up to date with the ones you specify. On Tue, May 22, 2018 at 1:00 PM, Désilets, Alain wrote: > Thx Thomas. Good thing I checked! > > Alain > - > 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
surefire test failure summary and format of -Dtest=
It sure would be nice if the surefire plugin -Dtest= option format would accept the output of the surefire summary report. For example: [ERROR] Errors: [ERROR] MyClassTest.testSomething1:80->MyClassTest.testSomething1:80 » NullPointer mvn test -Dtest=MyClassTest#testSomething1 It would just be nice if I could quickly double click (copy in linux) the failing test and then paste that right into the -Dtest=, but instead, I have do some formatting of the output before I can quickly get the specific test going again. Can we have -Dtest= support period (.) e.g. TheTest.testName in addition to the hash (#) separator between class and test name? Can we change the line number output to add a space or something like that so that it obeys normal word break semantics? Sorry, this is mostly a nit, but it sure would improve efficiency. Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Continuous Delivery with Maven now possible?
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/ On Thu, May 4, 2017 at 7:48 AM, Eric B wrote: > Hi Dan, > > Can you point me to Karl's blog please? I looked for it, but can't seem to > find it. > > Thanks! > > Eric > > On May 3, 2017 8:56 PM, "Dan Tran" wrote: > >> I am able to bring it to production with very small project with few >> modules. Where I hook up jenkins build number with the version >> >> 1.0.0-${env.BUILD_NUMBER} See Karl's Blog >> >> At the same time, use buildnumber-m-p to deploy text file with SCM info, >> and finally push to staging repo using Artifactory >> >> Once a build is promoted (GAed), I then remove the rest from staging, and >> manually tag the build using the recorded SCM info >> >> My next task is a much bigger project with 300+ modules and lots of >> dev/qa. So it is crucial i dont break their development environments >> >> Thanks >> >> -Dan >> >> >> On Wed, May 3, 2017 at 5:34 PM, Eric B wrote: >> >> > Hi Karl, >> > >> > Can you provide a little more information how you are doing this? Or do >> you >> > have a blog about it somewhere? It's something I desperately need to >> insert >> > into my build pipeline but haven't had the time to work on yet. So far, >> > the best I've been able to think of is to use a parameter for a build >> > number, have Jenkins assign a build number, pass it to maven, and have >> the >> > version reflect the build number using the external parameter. But I >> > really don't like that idea as the version is now dependent on a >> variable, >> > which I find is contrary to the whole concept. >> > >> > The other option is to have Jenkins took the build number in the pom >> using >> > the release plugin or the version plugin, commit the new pom, and then >> > build from a newly checked out code. My issue there is that I'm having >> > Jenkins do a lot of scm manipulations which are more subject to failing >> > (ie: version updates, commit, tag, push, etc). >> > >> > Finally, I'm trying to think of a good way of rolling all this into Nexus >> > staging repos and only promoting a build out of a staging repo once it >> > passes the pre prod environment and is certified for prod. >> > >> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated. >> > >> > Thanks, >> > >> > Eric >> > >> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise" wrote: >> > >> > > Hi Dan, >> > > >> > > I'm trying to do something in this direction starting next week... >> > > >> > > Apart from that already tested it with Eclipse Neon without any >> > > issue...(at the moment only test projects with 10-15 modules)... >> > > >> > > But it works at the moment.. >> > > >> > > In the meantime I have found one issue which is related to >> > > maven-enforcer-plugin where I already opened an issue for it [1].. >> > > >> > > Kind regards >> > > Karl Heinz >> > > >> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268 >> > > >> > > On 03/05/17 20:39, Dan Tran wrote: >> > > >> > >> Hi >> > >> >> > >> I have been experimenting with suggestion from Karl [1] with small >> multi >> > >> module maven project. >> > >> >> > >> >> > >> Is there any one actually bring this to production for large scale >> > project >> > >> yet? Love to learn from your experience integration specially with >> > >> Jenkins, >> > >> IDE ( eclipse, intellij, Netbean) >> > >> >> > >> this allows us to stop using maven-release-plugin >> > >> >> > >> Thanks >> > >> >> > >> -Dan >> > >> >> > >> [1] >> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou >> > >> t-a-version-in-it/ >> > >> >> > >> >> > > >> > > - >> > > 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: Please officially support RELEASE and LATEST (was: Re: dependency question)
Prefer to harden the version # in a corporate pom. Then use versions-m-p to detect and update bulk dependencies across all our projects. We manage about 350 dependencies in the corporate pom, and that doesn't even include the huge number that are scope=import for Arquillian and Selenium, etc. On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden wrote: >> I would like to argue for the inclusion / restoration / continued >> support of the RELEASE and LATEST tags. > > Really? No one else cares enough to respond? > > I am very often running into use cases where the easiest solution seems to > be LATEST and/or RELEASE. I have to manage a large Bill of Materials POM > and I need to know things like "which components have new releases > available" and "which components have SNAPSHOT builds since the last > release." How do other people answer these questions without custom > tooling, and without using LATEST or RELEASE tags? > > Regards, > Curtis > > -- > Curtis Rueden > LOCI software architect - https://loci.wisc.edu/software > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden > > > On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden wrote: > >> Hi Maven developers, >> >> I would like to argue for the inclusion / restoration / continued support >> of the RELEASE and LATEST tags. >> >> Reasons: >> >> 1) There are many valid use cases for them. For example, my script jrun >> [1] uses RELEASE right now to make it easier to launch a Maven GAV. >> Launching e.g. the Jython REPL is as easy as "jrun >> org.python:jython-standalone" from the CLI. But this relies on RELEASE >> working. I know that Maven is traditionally viewed as primarily a >> build-time tool, but it is also extremely useful for synthesizing runtime >> environments, and IMHO underutilized in this regard. >> >> 2) For LATEST, you can achieve basically the same behavior using a version >> range like [0,). There is no other way (that I know of) to achieve what the >> RELEASE tag does. >> >> 3) The argument that they harm reproducibility is totally valid. But so do >> SNAPSHOTs, and so do version ranges. And those have not been deprecated. So >> why are RELEASE and LATEST eschewed so heavily? >> >> Orthogonally: I think it would be awesome to warn about irreproducible >> builds, be they from SNAPSHOTs, version ranges, or these special keywords. >> People need to know when their builds are vulnerable. But there should >> probably also be a property to disable this warning, for the cases when the >> developer intentionally wants/needs to use them, and knows what they are >> doing. If the issue is just that no ones has time to work on e.g. MNG-6206, >> I could try to make some time for it—I feel strongly enough about this >> issue. >> >> Thanks for any insight, workarounds, counterarguments, agreement. >> (Especially if you agree: please speak up, so the core Maven devs know I'm >> not just an outlier here!) >> >> Regards, >> Curtis >> >> [1] https://github.com/ctrueden/jrun >> >> -- >> Curtis Rueden >> LOCI software architect - https://loci.wisc.edu/software >> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-clean-plugin on strike, sort of?
And the dir mismatch in your example is just because of multiple runs? On Thu, Oct 13, 2016 at 8:50 PM, Benson Margulies wrote: > ➜ tests git:(master) ls -l > /Users/benson/x/rosapi1.5/itests/tests/target/pax/6c7a5d80-3080-482f-abb4-394d9a782ef2/data > total 24 > -rw-r--r-- 1 benson staff 5 Oct 13 20:47 port > -rw-r--r-- 1 benson staff 7 Oct 13 20:47 rosette-usage.yaml > -rw-r--r-- 1 benson staff 7 Oct 13 20:47 rosette-usage.yaml.backup > > rm -rf is perfectly capable of deleting it. > > and yet, mvn clean fails. Any ideas? It's repeatable. > > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to > clean project: Failed to delete > /Users/benson/x/rosapi1.5/itests/tests/target/pax/4ba14215-319e-4688-95a0-d00997dd5fdc/data > at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:215) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > ... 20 more > Caused by: java.io.IOException: Failed to delete > /Users/benson/x/rosapi1.5/itests/tests/target/pax/4ba14215-319e-4688-95a0-d00997dd5fdc/data > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:249) > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:191) > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158) > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158) > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158) > at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:117) > at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:193) > ... 22 more > > - > 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: Create test jar during build without attaching
Confirmed. Is it so bad, though? :) I like the argument comparing putting .jpeg files in there. On Fri, Aug 19, 2016 at 2:13 PM, Christopher wrote: > src/test/resources are included in the source-release artifact, yes. > > On Fri, Aug 19, 2016 at 1:56 AM jieryn wrote: > >> Would src/test/resources be included in the src artifact? I suspect not. >> >> On Thu, Aug 18, 2016 at 9:47 PM, Christopher wrote: >> > If this were a personal project, I'd probably do that... but this is for >> an >> > ASF project, and I don't want to put us in a position where we are >> > releasing with binaries in the source artifact. >> > >> > On Thu, Aug 18, 2016 at 9:39 PM jieryn wrote: >> > >> >> Create the jar and then put it under src/test/resources/my.jar and >> >> then refer to that my.jar in your testcase. It seems like an awful lot >> >> of trouble to dynamically create this test artifact, when you could >> >> just create it once and then add it to your repository. Yes, adding >> >> jars to your scm is generally bad, but this seems like a perfect >> >> exception. >> >> >> >> On Thu, Aug 18, 2016 at 9:36 PM, Christopher >> wrote: >> >> > Hi Maven Users list, >> >> > >> >> > What's the best way to create a jar during a build without attaching >> it? >> >> > >> >> > Currently, our pom is configured to use the maven-jar-plugin to create >> >> it, >> >> > but that plugin attaches an artifact, which gets deployed. We don't >> want >> >> > that. That doesn't seem to be configurable. >> >> > >> >> > We could create a mini project and use maven-invoker-plugin to package >> >> it, >> >> > but that's a lot of overhead (configuration and processing time) for a >> >> very >> >> > small test jar containing a single file (used to test a classloader). >> >> > >> >> > We've also considered just using maven-exec-plugin to execute the jar >> >> > command-line tool, but that's tricky to get right, accounting for >> >> > JAVA_HOME, toolchains, etc. >> >> > >> >> > Any suggestions, or is maven-invoker-plugin the best option? >> >> > >> >> > I think the maven-assembly-plugin might be able to do it, and it has >> an >> >> > false option, but I've never used it like this >> before. >> >> If >> >> > that's the best option, does anybody have any examples of that kind of >> >> > thing? >> >> > >> >> > Thanks. >> >> >> >> - >> >> 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: Create test jar during build without attaching
Would src/test/resources be included in the src artifact? I suspect not. On Thu, Aug 18, 2016 at 9:47 PM, Christopher wrote: > If this were a personal project, I'd probably do that... but this is for an > ASF project, and I don't want to put us in a position where we are > releasing with binaries in the source artifact. > > On Thu, Aug 18, 2016 at 9:39 PM jieryn wrote: > >> Create the jar and then put it under src/test/resources/my.jar and >> then refer to that my.jar in your testcase. It seems like an awful lot >> of trouble to dynamically create this test artifact, when you could >> just create it once and then add it to your repository. Yes, adding >> jars to your scm is generally bad, but this seems like a perfect >> exception. >> >> On Thu, Aug 18, 2016 at 9:36 PM, Christopher wrote: >> > Hi Maven Users list, >> > >> > What's the best way to create a jar during a build without attaching it? >> > >> > Currently, our pom is configured to use the maven-jar-plugin to create >> it, >> > but that plugin attaches an artifact, which gets deployed. We don't want >> > that. That doesn't seem to be configurable. >> > >> > We could create a mini project and use maven-invoker-plugin to package >> it, >> > but that's a lot of overhead (configuration and processing time) for a >> very >> > small test jar containing a single file (used to test a classloader). >> > >> > We've also considered just using maven-exec-plugin to execute the jar >> > command-line tool, but that's tricky to get right, accounting for >> > JAVA_HOME, toolchains, etc. >> > >> > Any suggestions, or is maven-invoker-plugin the best option? >> > >> > I think the maven-assembly-plugin might be able to do it, and it has an >> > false option, but I've never used it like this before. >> If >> > that's the best option, does anybody have any examples of that kind of >> > thing? >> > >> > Thanks. >> >> - >> 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: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Sorry I am so late to this party. I find that Apache Maven 3.4.0-SNAPSHOT (90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00) prefers .mvn/maven.config options instead of specifically listed parameters. This is surprising to me. I expect the .mvn/maven.config options to be overriden by any actual parameters that I specify on the command line. Specifically, I am trying to override the maven.config --fail-at-end via --fail-fast, and also --threads 2.0C with --threads 1. When I invoke mvn, it seems the maven.config options are taken instead of my local cli invocation. These have a bad effect on my invocation and cause a lot of trouble. We do not check in our .mvn/maven.config, so I can not simply rm -rf it and then check it out after... it's a pita, and bad karma. Please examine it :) thank you. On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise wrote: > Hi to all Maven users, > > If you like to help making the next Maven release better it would be nice if > you could help a little bit. > > Please be aware of this *** This is not an official release *** > > I have created downloadable packages which are available from here: > > > Windows: https://s.apache.org/vG4r > Linux/Mac: https://s.apache.org/FfRw > > Every kind of feedback is helpful. > > Important hint: > > This is only a current state of development (Git hash: > 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the > community... > > The current list of changes can be seen in the issue tracker: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0 > > It would be nice if those who had found issues to retest their scenarios. > > > Kind regards > Karl Heinz Marbaise > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Create test jar during build without attaching
Create the jar and then put it under src/test/resources/my.jar and then refer to that my.jar in your testcase. It seems like an awful lot of trouble to dynamically create this test artifact, when you could just create it once and then add it to your repository. Yes, adding jars to your scm is generally bad, but this seems like a perfect exception. On Thu, Aug 18, 2016 at 9:36 PM, Christopher wrote: > Hi Maven Users list, > > What's the best way to create a jar during a build without attaching it? > > Currently, our pom is configured to use the maven-jar-plugin to create it, > but that plugin attaches an artifact, which gets deployed. We don't want > that. That doesn't seem to be configurable. > > We could create a mini project and use maven-invoker-plugin to package it, > but that's a lot of overhead (configuration and processing time) for a very > small test jar containing a single file (used to test a classloader). > > We've also considered just using maven-exec-plugin to execute the jar > command-line tool, but that's tricky to get right, accounting for > JAVA_HOME, toolchains, etc. > > Any suggestions, or is maven-invoker-plugin the best option? > > I think the maven-assembly-plugin might be able to do it, and it has an > false option, but I've never used it like this before. If > that's the best option, does anybody have any examples of that kind of > thing? > > Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing
Tested on RHEL 7, Java 8, -T8, all maven plugins up to date with current releases (thanks versions-m-p), on many internal projects for basic build/test/it and it is working great! It really looks great and modern! :-) Now I just made it my default version of Apache Maven and will give it more rigorous testing throughout the week, more plugins, more goals, more profiles, more oddball cases. (not scientific testing, but I am seeing minor performance improvements on the order of 2-3% despite colour outputs) Thank you Apache Maven Team! Thank you Karl :) On Sat, Jun 11, 2016 at 6:43 PM, Anton Tanasenko wrote: > Hi, > There is a commit for MNG-2478 which I think could cause problems for > projects that are authored using 3.4.0 and the new resources-filtered > source folder is used (provided it was not configured in the project as > such before). Those projects will not be buildable with prior maven > versions. > This is not something major, but it does break backwards compatibility > somewhat. Is that ok? > > https://issues.apache.org/jira/browse/MNG-2478 > > > 2016-06-11 23:21 GMT+03:00 Karl Heinz Marbaise : > >> Hi to all Maven users, >> >> is someone of you willing to do some testing on the current state of >> development for the upcoming Maven 3.4.0 release? >> >> Please be aware of this *** This is not an official release *** >> >> I have created downloadable packages which are available from here: >> >> Windows: https://s.apache.org/fawM, >> Linux: https://s.apache.org/RQ3C >> >> >> Every kind of feedback is helpful. >> >> This is only a current state of development (Git hash: >> 644ac9c40ad41bf61e3b099918af33b8eb950621) to get some feedback from the >> community... >> >> The current list of changes can be seen in the issue tracker: >> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0 >> >> >> Kind regards >> Karl Heinz Marbaise >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Regards, > Anton. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn deploy without rebuilding?
Seems like a lot of time fighting what Apache Maven does. Usually a good smell that you're doing something wrong. Use installAtEnd / deployAtEnd. Bytes are cheap, just burn them and move on to a real problem. On Wed, May 4, 2016 at 3:48 PM, Mirko Friedenhagen wrote: > Hello, > > what about enhancing the install plugin with a list of the latest installs > and creating a mojo deploy:deploy-latest-install? > > Regards > Mirko > -- > Sent from my mobile > Am 03.05.2016 18:15 schrieb "Stephen Connolly" < > stephen.alan.conno...@gmail.com>: > >> I think that if your SCM supports the options and your MRM supports staging >> then you can get the workflow you want by basically making every build a >> release build e.g. >> >> mvn -DreleaseVersion=1.0.0.${BUILD_NUMBER} \ >> -DdevelopmentVersion=1.0.0.0-SNAPSHOT \ >> -DsuppressCommitBeforeTag=true \ >> -DpushChanges=false \ >> -DlocalCheckout=true \ >> -DpreparationGoals=initialize \ >> release:prepare \ >> release:perform && git push --tags >> >> That should basically just create the tag and build from the tag and then >> only push the tag upstream if the release is successful. >> >> The developers pom stays on 1.0-SNAPSHOT (but as we do not push commits >> back to master it doesn't matter) and the release versions get their >> version number from Jenkins. >> >> On 2 May 2016 at 19:08, thully wrote: >> >> > Hi, >> > >> > Our project has many Maven artifacts, the vast majority of which are OSGi >> > bundles. These bundles are distributed together as part of our >> application >> > (Cytoscape), but may also be used by third-party developers using our >> API. >> > >> > Given this, we have been deploying our artifacts to a Maven repository >> each >> > time we make a new release of our application. However, we've run into an >> > issue with this - every time we run mvn deploy, the bundles are rebuilt >> > with >> > new time-stamps and checksums. This makes it impossible to ensure that >> > what's in the Maven repository matches a tested release version of the >> code >> > unless we deploy when we build (suboptimal when we have code we're not >> sure >> > is release-ready, but has non-SNAPSHOT version numbers in preparation for >> > release). >> > >> > I've seen that mvn deploy:deploy supposedly should do what we want >> (deploy >> > without rebuilding). However, this fails on every one of our bundles with >> > an >> > error like the following: >> > >> > "The packaging for this project did not assign a file to the build >> > artifact." >> > >> > mvn deploy:deploy-file works, but has to be done a file at a time with >> each >> > POM and artifact specified on the command line. That would be a pain with >> > 100+ artifacts/POMs in different locations. Does anybody know of a better >> > way to do this? >> > >> > >> > >> > -- >> > View this message in context: >> > >> http://maven.40175.n5.nabble.com/mvn-deploy-without-rebuilding-tp5866812.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 >> > >> > >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: finding dependencies that should be marked as compile
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html On Fri, Feb 26, 2016 at 9:29 PM, Jamie Johnson wrote: > Is there a way to list any dependencies that are being pulled in > transitively that really should be marked as compile? I'd like to isolate > any dependencies that I may be missing from the compile scope. > Additionally, is there a way to identify dependencies that are listed as > compile that aren't required? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jdeps-plugin RFEs
Ok, thanks. On Tue, Nov 3, 2015 at 1:42 PM, Karl Heinz Marbaise wrote: > Hi, > > JIRA will do a restart on 6.11.2015 afterwards the new project is > available...(Yes for this plugin)...http://status.apache.org/ (Upcoming > maintenance link)... > > > > On 11/3/15 7:31 PM, jieryn wrote: >> >> Since there isn't yet a project to report issues, I was informed to >> report issues here. >> >> Would be nice to have a skip option so we can configure the plugin to >> run in a high level POM, and then case by case skip it where we need. >> >> Also, there seems to be quite a lot of output. It would be nice if we >> could just have the errors reported without all the extra >> package/class output. >> >> Finally, that output itself is not grepable, so it's kind of spammy >> and then won't play nice with tools for processing a lot of data. >> Maybe a report mojo? >> >> Looks cool, love this stuff, thanks! >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > Kind regards > Karl Heinz Marbaise > > - > 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
maven-jdeps-plugin RFEs
Since there isn't yet a project to report issues, I was informed to report issues here. Would be nice to have a skip option so we can configure the plugin to run in a high level POM, and then case by case skip it where we need. Also, there seems to be quite a lot of output. It would be nice if we could just have the errors reported without all the extra package/class output. Finally, that output itself is not grepable, so it's kind of spammy and then won't play nice with tools for processing a lot of data. Maybe a report mojo? Looks cool, love this stuff, thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-jdeps-plugin:3.0.0 site
I'm sorry, it looks like I double pasted the URLs. http://maven.apache.org/plugins/maven-jdeps-plugin/issue-tracking.html links to https://issues.apache.org/jira/browse/MJDEPS which says the project does not exist. I want to file a couple of issues for this plugin. I can not find where to file the issues. Thanks! On Fri, Oct 30, 2015 at 12:31 PM, Karl Heinz Marbaise wrote: > Hi, > > On 10/30/15 3:14 PM, jieryn wrote: >> >> The site for the m-jdeps-p ( >> https://issues.apache.org/jira/browse/MJDEPS ) is broken for the >> Issues page. It links to https://issues.apache.org/jira/browse/MJDEPS >> which doesn't exist. > > > Can you be a little bit more specific what does not work?.. > > I have checked here from germany no problem...just fine... > > Kind regards > Karl Heinz Marbaise > > - > 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
maven-jdeps-plugin:3.0.0 site
The site for the m-jdeps-p ( https://issues.apache.org/jira/browse/MJDEPS ) is broken for the Issues page. It links to https://issues.apache.org/jira/browse/MJDEPS which doesn't exist. Where can I file an issue for this plugin? Thank you! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Central search is empty
Seems to be working now. On Fri, Sep 11, 2015 at 7:49 AM, Martijn Dashorst wrote: > It appears that the Maven central search index (search.maven.org) was > not able to load the index as any search now returns an empty response > (no entries found). > > Martijn > > - > 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: Replacing a bunch of -Dkey=value pairs using external file
bash$ cat sys1.env -DZZ01=maven -DZZ02=rocks bash$ mvn $( wrote: > As mentioned, the poms already jam with all the default properties work out > of box for a particular environment. I just need a friendly way to > override them. Using settings.xml is the only choice at this moment > > Thanks > > -Dan > > On Tue, Sep 8, 2015 at 5:07 PM, Barrie Treloar wrote: > >> On 9 September 2015 at 09:30, Dan Tran wrote: >> >> > Hi Barrie, >> > >> > That would work. On caveat, I have to instruct my user to edit their own >> > settings.xml. Would be nice if I can just pass in -fp xxx from command >> > line >> >> >> Are they truly always on? >> >> Then you can jam them in your pom.xml >> >> http://maven.apache.org/pom.html#Properties >> >> >> true >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where to put context.xml in webapp archetype ?
I personally find this a bit weird, but it's because the JPA persistence.xml needs to end up in war!WEB-INF/classes/META-INF/persistence.xml whereas Tomcat will expect to find context.xml in war!WEB-INF/context.xml. I suppose you could put it in src/main/webapp/WEB-INF/classes/META-INF/persistence.xml but then IDEs will probably not find it easily/at all. Glad it works for you. On Sat, Aug 8, 2015 at 8:47 AM, Sreyan Chakravarty wrote: > Thanks > > On Sat, Aug 8, 2015 at 4:05 PM, jieryn wrote: > >> src/main/resources/META-INF/persistence.xml >> src/main/webapp/WEB-INF/context.xml >> >> On Fri, Aug 7, 2015 at 3:24 PM, Sreyan Chakravarty >> wrote: >> > I am using Maven for building a simple webapp that uses JDBC connection >> > pooling along with Hibernate. >> > >> > I am using the Maven Webapp Archetype to build the project. >> > >> > Where do I put context.xml and persistence.xml that I normally put under >> > META-INF in a normal dynamic web project. >> >> - >> 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: Where to put context.xml in webapp archetype ?
src/main/resources/META-INF/persistence.xml src/main/webapp/WEB-INF/context.xml On Fri, Aug 7, 2015 at 3:24 PM, Sreyan Chakravarty wrote: > I am using Maven for building a simple webapp that uses JDBC connection > pooling along with Hibernate. > > I am using the Maven Webapp Archetype to build the project. > > Where do I put context.xml and persistence.xml that I normally put under > META-INF in a normal dynamic web project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Incremental Build: JDT Compiler Implementation
Is there an example project to kick the tires for incremental builds? How about early timings for performance? Seems like the feature requires its own package type, won't that cause lots of downstream headache for other tools? On Jan 13, 2015 2:18 PM, "Jason van Zyl" wrote: > Hi, > > Incremental build (or build avoidance) is a heavily discussed topic these > days and users always ask about it in the context of Maven. In the last > Maven Developer Hangout[1] we talked about incremental build as implemented > for Maven and Buck and Igor also presented what might be interesting to > users who want to learn move about incremental build which is Takari's > incremental compiler implementation that uses JDT. If you are interested > you can take a look here[2]. > > [1]: https://plus.google.com/u/0/events/cm0nnn4342ttnk0i9k4pvml3670 > [2]: http://takari.io/2015/01/13/incremental-build.html > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > > > > >
m-remote-resources-p && mvn 3.2.1 vs mvn 3.2.3
m-remote-resources-p:process has serious bug with excludeTransitive option: * with maven 3.2.1 excludeTransitive=false, my build completes in about 10 seconds * with maven 3.2.3 excludeTransitive=false, my build dies with OOME after about 2 minutes * with maven 3.2.3 excludeTransitive=true, my build completes in about 10 seconds Anyone else seeing this? It looks like it was introduced in v1.5 because of http://jira.codehaus.org/browse/MRRESOURCES-58 -- look at the patch that was applied, the logic behind 'if ( this.excludeTransitive )' looks to be exactly wrong. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven plugin which displays the parents of a given project recursively
http://mojo.codehaus.org/versions-maven-plugin/ I have Jenkins jobs which @weekly run a smoke test "update all the things and see if it works" build, for each project. I also have a set of jobs which are virtually the same but simply run the display versions of the plugin goals. If the team gets confident in this process, you can exploit scm:checkin to automatically commit these dependency and parent updates if the build is successful. It's pretty easy, actually. On Fri, Jun 20, 2014 at 8:09 AM, Mirko Friedenhagen wrote: > Hello, > > does anybody know of a plugin which shows the GAV coordinates of the > parents of a given project recursively? Or is there any feasible > plugin where I could contribute with a goal? > > My team of 3 is consulting approx. 200 developers in regards of build > engineering with ca. 1000 Jenkins jobs and we often see they are using > outdated versions of our department POM. Having this information in > the console of a Jenkins job would allow to see this without checking > the POM. > > Regards Mirko > -- > http://illegalstateexception.blogspot.com/ > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) > https://bitbucket.org/mfriedenhagen/ > > - > 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
duplicate GAV error message difference between v3.1.1 and v3.2.1
https://github.com/jieryn/maven-duplicate-gav You can use the project above to quickly see the stark difference between error messages produced by Apache Maven v3.1.1 and v3.2.1 when a duplicate GAV is found in the reactor. I think this is a pretty bad regression. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Plugin and report plugins that need dependencies declared
On Fri, Feb 14, 2014 at 7:55 AM, Alex Potsides wrote: > E.g. as an additional > dependency of the maven-site-plugin itself? Yes. > If so, I tried that [...] The maven-site-plugin does not appear to > share it's classpath with child reportPlugins and quite rightly so. Boo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Code coverage with debug logs: 100% branch coverage not possible?...
I have also been annoyed with what you describe, and have wondered how to fill the gap of missing coverage. Outside of copying the testcase and dynamically changing the log level inside of it, which in addition to being burdensome, also offends my DRY sensibility, the best idea I've had about this involves a relatively new feature of JUnit called @Theories[1]. You could create @DataPoints {Level.ALL, Level.NONE} and then pass them in to your test method. Then you dynamically set the class under test's Logger.Level with the data point. I think this ought to work just fine unless you execute your tests in parallel mode, as most Logger declarations are as static instances. There's one other problem which has prevented me from exploiting this technique: @Theories needs a dedicated @RunWith(Theories.class). Which would tend to preclude execution under @RunWith(Arquillian.class) since @RunWith takes a singular runner argument, unless Aslak/someone makes some tweaks[2]. [1] https://github.com/junit-team/junit/wiki/Theories [2] https://issues.jboss.org/browse/ARQ-561 On Wed, Feb 12, 2014 at 3:30 PM, Benoît Berthonneau wrote: > Hi all, > > > > I need your opinion/way to tackle the following problem: > > In many projects we use a Logger (doesn't matter which implementation). It > is often recommend to test if the debug level is activated before logging a > debug trace like the following: > > if (logger.isDebugEnabled()) { > > logger.debug("blah " + i + " in the loop that contains " + max); > > } > > > > Now when you run unit tests on this kind of code you need to make a choice: > run tests with INFO level or run tests with ALL traces activated. I choose > the second option in order to: > > * Check that debug traces doesn't throw unwanted exception (like > NPE) > > * Have a better code coverage in term of covered lines > > > > But in term of branches coverage we could never have a 100% :( > > > > To me the only way to cover this is to run the tests suite 2 times: one with > INFO traces configured, and another one with ALL traces activated. > > Did you face this issue and how did you solve it ? > > > > Thanks, > > Benoît. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Plugin and report plugins that need dependencies declared
Even though Hervé has given the best answer, I thought I'd chime in and say that The Maven Way would probably have you add the additional dependency at the plugin level, and not the configuration.reportPlugins.plugin level.. So, sorry, but you were wrong twice. :-) On Thu, Feb 13, 2014 at 10:34 AM, Alex Potsides wrote: > > maven-site-plugin > 3.3 > > > >.. >.. >.. > > >.. >.. >... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare does not update parent version
Greetings, On Tue, Jul 23, 2013 at 7:45 AM, Markus Karg wrote: > But why is release:prepare explicitly asking me whether I want to update that > number and what that number is, when it is intended behaviour that it does > not actually set that number into the POM? I would understand all what you > say if the plugin would not ask for the next development version of . > But it DOES ask. Ok, that is definitely odd. Can you please provide a minimal project which reproduces that issue? -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare does not update parent version
Greetings, On Mon, Jul 22, 2013 at 8:25 AM, Markus Karg wrote: > When I do mvn release:prepare, Maven asks whether I want to update all > SNAPSHOT version referenced in the POM. I don't think the language says that at all. I ran a quick build and I'm not seeing where it says it will update every single SNAPSHOT version referenced in the POM. Can you please paste it? > I say "yes" and confirm all suggested replacement versions unchanged. > When Maven is done, I check the POM.xml. > It is correctly rewritten for all references, but not for the parent > version. And it should not. It will rewrite the versions for the artifacts in its build plan, and the parent is not part of the build plan in this way. It would be horrifying, frankly, if running a release in a project would go update the parent project also. > The parent version still references the *old* SNAPSHOT, while obviously > it should now name the *next* SNAPSHOT. I don't think it should obviously do that. Perhaps you actually intended to run the release from the parent, if that is true, then you should do it from there. Not from within some submodule. > Can somebody tell me what I have to do so that mvn release:prepare will > also make the parent version point tot he *next* SNAPSHOT, as it does it > correctly with the dependencies and the project's own version? Run the release from the proper location. Or if the parent really does not have a submodule of the project you're errantly trying to run the release from right now, then you should release it (parent) first and then make the updates in the unlinked child projects to the latest release number. The m-versions-p is quite adept at automating this process. -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to create patched artifact?
Hi David, If you have all the source code, as you seem to suggest several times in this convoluted post, then why don't you just deploy a new -SNAPSHOT yourself to your local repository? You ARE using a repository manager, right?? http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with-3rd-party-snapshot-dependencies/ -jesse On Tue, Aug 4, 2009 at 10:25 AM, David Hoffer wrote: > What is the maven way of creating a patched jar? > > I have a case where I need to apply some overrides to a binary jar which is > one of my dependencies. I have the source code for the overrides. So I > could create a child module with the source and the one dependency that > needs the overrides applied. What maven plugin would I use to extract the > class files from the dependency, combine with the new generated classes from > source, and then re-jar? The final artifact would have a new name, i.e. > _patched, so as to not get confused with the original. How can I then stop > the transitive dependency on the original jar? I would want the dependency > to be on the new patched version only. > > What's the maven way of doing this sort of thing? > > -Dave > -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Archetype: escaping velocity properties.
Hi James, I place the following at the top of all my velocity-processed resources: #set( $symbol_pound = '#' ) #set( $symbol_dollar = '$' ) #set( $symbol_escape = '\' ) And then simply use those whenever I'd want to use the real symbol, which is special to velocity. This works for me in resources, remote-resources, and archetypes. -jesse On Tue, Jul 28, 2009 at 6:33 AM, Nord, James wrote: > > I'm creating an archetype but I need to escape some values so that > velocity doesn't complain about them or even try and substitute them > -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: build.plugins.plugin.dependencies nonsense
Thank you for responding, Using a property mitigates the issue, but only slightly. It seems rather silly that I have declared a specific version within just to have it ignored when listing a specific of a specific . I realize that project building is different than a plugin's classpath, however, I've gone out of my way to list GAV coordinates within dependencyManagement -- it doesn't seem to be a punishment fitting of the crime to require that I also set a version when one is already available in another section, albeit somewhat philosophically unrelated. The main goal here is that I want to unpack a m-remote-resource-p created bundle and use the output within a plugin. I do not want to have this dependency otherwise placed into any generated artifacts for that module, e.g. the war. However, I need it to be available for the plugin to operate properly. Perhaps I've misunderstood one of the dependency scopes that would allow this behavior... I dunno. Either way, it feels wrong that Maven requires me to code this information... ugh. -jesse On Tue, Jul 21, 2009 at 8:02 AM, Brian Fox wrote: > Use a property instead. > > The plugin dependencies don't pick up a version from the depMgt > because depMgt is about building your project and your classpaths, the > plugin dependencies are about overriding a plugin's classpath...two > very distinct things. > -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
build.plugins.plugin.dependencies nonsense
Greetings, [INFO] [enforcer:display-info {execution: default}] [INFO] Maven Version: 2.2.0 [INFO] JDK Version: 1.5.0_16 normalized as: 1.5.0-16 [INFO] OS Info: Arch: i386 Family: unix Name: linux Version: 2.6.29.5 It seems ridiculous to me that I have to specifically list a dependency version when it is bound to a particular plugin. Please see the example: maven-remote-resources-plugin com.mycom.super.resources checkstyle 0.0.1-SNAPSHOT [...] When I already have defined a managed version of that dependency as such: com.mycom.super.resources checkstyle 0.0.1-SNAPSHOT When I don't code a version inside the section, I receive the following: [ERROR] FATAL ERROR [INFO] [INFO] An invalid artifact was detected. This artifact might be in your project's POM, or it might have been included transitively during the resolution process. Here is the information we do have for this artifact: o GroupID: com.mycom.super.resources o ArtifactID: checkstyle o Version: <<< MISSING >>> o Type:jar [INFO] [INFO] Trace org.apache.maven.artifact.InvalidArtifactRTException: For artifact {com.mycom.super.resources:checkstyle:null:jar}: The version cannot be empty. at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147) at org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:122) at org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158) at org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:70) at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:439) at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:377) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:217) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1744) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:446) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] Ugggh! Why must I duplicate this information? Worst of all, the m-release-p doesn't bump these versions as I would hope it would. So, these things quickly become out of sync and are a royal PITA to maintain. Please help! -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-remote-resources-plugin and org.apache:apache-jar-resource-bundle
Why doesn't the OP just create his/her own bundle?? I just can't understand what the point of all this discussion is. In the time that has been wasted on this thread, the OP could have just copied the original module and customized the velocity scripts within... UGH. The stupid thing is like 3 .vm files and a pom. Does this really warrant an actual conversation? -jesse On Wed, Jun 17, 2009 at 3:21 PM, Dennis Lundberg wrote: > This bundle has changed over time to make sure that an ASF release that > is created using Maven follows the rules for releases set up by the ASF. > The bundle has not been designed to be reused for software created > outside the ASF. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cargo and multi-module projects
Hi Pieter, On Mon, May 11, 2009 at 11:47 AM, Bocalinda wrote: > > What exactly do you mean by "attachment to a life cycle phase"? > You mean like this: > > > > start-container > pre-integration-test > > start > deploy > > > > stop-container > post-integration-test > > stop > > > > Yes, that's exactly right. Inside a profile in your super pom.xml. -jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
Re: Cargo and multi-module projects
Hi Bocalinda, On Mon, May 11, 2009 at 11:28 AM, Bocalinda wrote: > > Glad I'm not the only one who is trying such thing. > Great solution you just gave me, I hope this works for me as well. > > Big thanks! You picked up on it, but, just to clearly state it this time (as I didn't previously), the profile would contain the configuration and attachment to a life cycle phase, of the Cargo plugin. Also, I've gone ahead and created a new JIRA[1] for the profile activation by packaging type I mentioned before. I found where I commented inside another JIRA[2], but this is worthy of its own ticket. [1] http://jira.codehaus.org/browse/MNG-4154 [2] http://jira.codehaus.org/browse/MNG-1753 You're welcome, :-) -jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cargo and multi-module projects
Hi Bocalinda, On Mon, May 11, 2009 at 10:28 AM, Bocalinda wrote: > > In order to achieve automatic testing of my projects, I use Cargo to > automatically deploy newly generated war files to a Tomcat server. > All the specifics to the automatic testing (depedencies, plugin > configuration, etc) are contained inside of a super pom. Yep, I find myself in the same position. I don't think the Cargo plugin is behaving badly here. Instead, you can create a profile in your super pom which will be automatically activated by a property. Then, in your Maven modules which are packaging=war, you can set that property. Ideally, Maven would support profile activation by packaging type (I believe I created a JIRA for this, or commented in an existing Profile Enhancement type JIRA) but unfortunately it can not, yet.. Anyhow, the solution I propose requires the least amount of specific per-Maven module configuration and allows the greatest amount configuration reusability. I have had it working in my environment for about 6 months of active development for several projects.. Good luck! -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Skinning
Hi Ryan, On Tue, Apr 21, 2009 at 11:31 AM, Ryan Connolly wrote: > Jesse: > > I would be glad to, however, I feel it still needs some tweaking > to allow for user configuration... I was going to do a project just like this, and incorporate ImageMagick. My first thought was just to have an open ended parameter that would be options to pass to ImageMagick. By default the Mojo would use the project.name as the text, but this would be overridable. -jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Skinning
Hello Ryan, On Tue, Apr 21, 2009 at 10:05 AM, Ryan Connolly wrote: > Hello: > I am creating a site skin for my company's project sites and have > written a MOJO that will generate the site logo based on the project > name that runs at the pre-site lifecycle phase. Any chance you can release this Mojo? :-) -jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: resources:copy-resources
Hi Sean, On Fri, Apr 17, 2009 at 7:08 PM, Sean Owen wrote: > > > 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 > pose > posnet > war > 1.1.1-SNAPSHOT > Positive Energy Web > > > > > maven-resources-plugin > > > validate > > copy-resources > > > src/main/webapp/clients/pse > > > > /opt/pose/main/clients/pse/trunk/src/main/resources/webclientconfig/clients/pse/assets/ > true > > > > > > > > > Strictly, you've configured a single execution of the resources:copy-resources goal. You then attached that configuration to the build in the validate life cycle phase. You have no configuration defined for any default resources:copy-resources goal. > If I run mvn resources:copy-resources with the above pom, I get the same > error, asking for outputDirectory and resources, both of which are plainly > specified above. No doubt! Try just copy and pasting your configuration for this plugin into .. then re-run your direct execution via mvn resources:copy-resources. > I've consulted every coworker with any maven experience, and they're all > mystified. Yikes! That's kind of discouraging... I'm sorry. Good luck, -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse:eclipse suddenly adding including="**/*.java" to .classpath
Hi, On Wed, Apr 8, 2009 at 11:28 PM, Zach Cox wrote: > > While I realize that technically only .java files should exist in > src/main/java, it's a pain to create a duplicate package hierarchy in > src/main/resources and this greatly reduces visibility of these .txt > files. > This is easily solved in one command line invocation, find it here: http://maven.markmail.org/message/wy7cjv772udtqtjm -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-compiler-plugin resources not in classpath
Hello David, Please review the maven-jar-plugin, specifically the includes parameter to the jar goal. http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#includes -jesse On Mon, Apr 6, 2009 at 9:47 AM, David Goodenough wrote: > But will that not exclude it from the jar as well? I tried it and it seems > to have that effect. I want it excluded from the compilation but included > in the jar. -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-compiler-plugin resources not in classpath
Hi David, If I understand the problem correctly, it will be solved by excluding META-INF/services/javax.annotation.processing.Processor file from your module resources (thereby preventing it from being put into the classpath). Please read http://maven.apache.org/pom.html#Resources for more information on how to do that. Good luck, -jesse On Mon, Apr 6, 2009 at 5:47 AM, David Goodenough wrote: > I am trying to use maven to compile a java annotation processor. > > When you build a jar which contains an annotation processor you can put > a file (META-INF/services/javax.annotation.processing.Processor) which > contains one line per annotation processor. With this file in place you > then only have to include the jar in the javac classpath to get it to > process annotations, you do not have to mention it on the command line. > > Unforunately if you build your pom.xml to include this file under the > resources tag, it gets included in the classpath, and then the compiler > complains that the annotation processor it is compiling (the one mentioned > in the file) does not exist, so it can not run it as an annotation processor > so the compilation fails. So what I need is a means to add the file to the > jar without adding it to the compiler classpath. > > Anyone got any suggestions. > > David -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Making LATEST work for multiple dependant projects ?
My breath is now officially bated. :-D On Mon, Mar 2, 2009 at 8:37 AM, Stephen Connolly wrote: > I am working on this... there were some issues with integration with doxia > that I need to resolve - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Making LATEST work for multiple dependant projects ?
I can recommend the versions-maven-plugin (http://mojo.codehaus.org/versions-maven-plugin/) also, but one thing that I really miss from it is the production of a report generated during site life cycle. On Mon, Mar 2, 2009 at 5:24 AM, Stephen Connolly wrote: > Or you could have a look at versions-maven-plugin... it will still require > you to commit your changes, but it will at least help with changing the > pom.xml files for you > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to copy resource files to target/classes directory?
Hello, On Thu, Feb 26, 2009 at 8:11 AM, youhaodeyi wrote: > > I have may XML files in src/main/java directory and its sub directory. When I > run "mvn compile", these XML files will not be copied to the target/classes > directory. I know I can put these files in src/main/resources directory but > it is really hard work for me. How can I let maven do this? Maven seems like a bad choice for this. Why don't you just... bash$ tar --wildcards --exclude '*.java' --exclude '.svn' --create --directory src/main/java --file - . | tar --extract --directory src/main/resources --file - -jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New repository for Maven snapshots
On Sat, Feb 21, 2009 at 8:52 PM, Wes Wannemacher wrote: > > Brian, right now, the struts project pushes its snapshots over to people.a.o > when the apache hudson builds them (as often as daily, but usually not quite > that often). Apache project itself uses Hudson over Continuum? LOL. -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding files from packaging
Vishal, If you had reviewed the documentation even preliminarily, you would have found: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#excludes -jesse On Thu, Feb 19, 2009 at 7:17 AM, Vishal Pahwa wrote: > Hi > > Sorry to sending you mail personaly but its urgent. > > Please help me out if you have any context on the below requirement. > > In our project we have a requirement of letting some java files in the > package to compile but need to restrict those files for being packaged in > the jar. > > Any idea how can we achive this. > > Regards > > Vishal > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to deploy ejb-client ??
No, you aren't forced to do that. But it is by far the easiest way of doing things. Separate concerns, i.e. artifacts, should be in separate modules. I, at least, would generally need a very good reason to bypass that design principle; a module having a small number of actual files in it is rather unconvincing. If you absolutely must, you could try maven-assembly-plugin. Good luck. -jesse On Thu, Feb 19, 2009 at 7:15 AM, Felipe Gaúcho wrote: > am I forced to do that ? > > * it is only 2 interfaces :) > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to deploy ejb-client ??
Make a separate module for each? On Thu, Feb 19, 2009 at 6:44 AM, Felipe Gaúcho wrote: > I am using the ejb plugin to generate two artifacts: > > - ejb-module.jar > - ejb-module-client.jar > > but only the ejb-module is being deployed to the local repository ... > > is there a way to configure the pom to deploy both artifacts ?? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Including project's sources in the same war file. Best practise?
Hello, On Fri, Jan 30, 2009 at 4:34 AM, Yves Dessertine wrote: > Hi. > > I've been asked to include a project's sources into the same war (it > is a war webapp). Where the best place to put the sources in the war > file? > What's the best way to do this ? > Probably the easiest way would be to do this: src/main/java Which has the effect of copying the resources into your output directory. Good luck, -jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven inheritence works with 2.1-SNAPSHOT but not with 2.0.9
Just thought I would chime in with yet another alternative approach, I employ a solution slightly different than Brian's assembly solution. It is possibly not to be considered clean by the Maven crocodiles. :-) My top level enterprise parent pom has a few support modules immediately in its SCM hierarchy. Some of these modules are nothing more than configuration files, e.g. checkstyle.xml, stylesheet.css (for maven-javadoc-plugin), etc. They are default jar and contain nothing but a src/main/resources/com/acme/base/. Then, in the enterprise parent pom I do something like: maven-dependency-plugin Explode com.acme.base:common-config-checkstyle generate-resources unpack com.acme.base common-config-checkstyle false src/main/resources true Since this is executed for every sub-module, everyone that inherits from this master enterprise base parent (every Maven project in our shop) will automatically get the most up to date, and corporate policy adhering, configuration file. In your plugins which exploit these configuration files, you can simply refer to ${basedir}/src/main/resources/com/acme/base/checkstyle.xml, e.g. I think the only thing that I would change about this solution is that having these things unpack during the generate-resources phase is a bit too aggressive for our usage pattern. I could probably bring to something closer to the install phase, but we then might lose the ability to do clever things like mvn checkstyle:checkstyle directly... Ideally, I could refer to a resource in a Spring-like manner, e.g. classpath:com/acme/base/checkstyle.xml and then I wouldn't need any unpack executions in the at all!! Oooh, what a sweet dream that would be.. :-) Anyhow, I have a half dozen of these common-config-* modules and things are working out pretty smooth otherwise. Good luck! -jesse On Wed, Jan 21, 2009 at 4:01 AM, kukudas wrote: > > Thanks for the clearing Brian, > > i have read your tutorial and it seems a good approach, however i thought > about an alternative aproach maybe you can give me your opinion about it. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
javadoc plugin
Greetings, It sure would be nice if all of my listed s could somehow pass information to the javadoc plugin such that I am not forced to manually enter s for external API cross referencing. I'm up to about 55 immediate dependencies already, in my largest maven project, and this adds 55 extra lines I am too lazy to enter manually.. Anyone know if this is possible? Thanks! -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple executions of goals under generate-sources: How to avoid?
On Sat, Oct 18, 2008 at 11:00 AM, stug23 <[EMAIL PROTECTED]> wrote: > > So my question is: "Is there a way to still produce a sources jar using the > maven-source-plugin without invoking execution of the generate-sources > phase?" > I am extremely interested in the answer to this question as well. Please Maven experts, help! :-) -jieryn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven JPA->DTO Plugin
Greetings, I am curious if there is a plugin out there that can transform JPA annotated classes and convert them into very simple DTOs? I am currently doing this conversion by hand, ouch! I need near mirror copies of my persisted classes because GWT can not work with these JPA (via Hibernate) enabled classes. I think my usage pattern will be to recursively mirror (same package layout from the base) a particular package just strip out any annotations -- I just don't want to reinvent the wheel. Thanks in advance, -jieryn -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven-pmd-plugin] Customizing generated report
Greetings, I don't see any way for me to customize the generated PMD report to my needs. Specifically, I think it would be quite helpful to me and my project developers to have clickable rules which would launch to the official PMD documentation for the rule which is being reported. I believe that PMD itself can create reports this way, I'm a bit stunned no one else has requested this before... (perhaps my searching of both the archive and JIRA is deficient, however). Perhaps I should just open a new JIRA for this? Thanks in advance, -jieryn -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]