Re: Re : The next major release of Maven: 4.0.0
Am 13.03.2013 08:38 schrieb herve.bout...@free.fr herve.bout...@free.fr: If you write documentation in Maven core (the components), not in Maven site (the global project), you'll be happy with git like you do with sources I can then take care of svnpubsub publication, or anybody else since I already prepared it (notice ranting against svnpubsub is just a waste of time and karma) What is the value of svnpubsub? Why is it so valuable compared to alternatives? Which alternatives are could you (all) imagine? I'm clueless. Best Ansgar Envoyé depuis mon mobile - Reply message - De : Jason van Zyl ja...@tesla.io Pour : Maven Developers List dev@maven.apache.org Objet : The next major release of Maven: 4.0.0 Date : mar., mars 12, 2013 16:29 I would like if someone would volunteer to do the documentation part of the release. This will probably be the 3rd time I've merged Eclipse Aether into Maven and there are a lot of moving parts that need to be tested and frankly it's starting to burn me out. I don't have time or interest in using the Subversion-based documentation system so I'd like someone else to do that. Do we really have no choice in how we publish our site? Checking stuff into SVN for documentation seems arcane and ridiculous. I don't mind doing the technical work, I would like someone else to pickup the documentation work for the release. Can someone help with that? On Mar 11, 2013, at 10:33 AM, Jason van Zyl ja...@tesla.io wrote: Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means. On Mar 10, 2013, at 1:20 AM, Anders Hammar and...@hammar.net wrote: Personally I would like us to stick with the initial discussion of shipping 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed and talked about for some time so it would be great to get that out of the door. The we could discuss the next step. Basically, and generally, I'd like us to stick to the plans we discuss. At the same time I fully appreciate that I'm not doing the work. On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen mfriedenha...@gmail.comwrote: Well at least with Maven 4.0 I would not get the question anymore, why the pom's model version is at 4 while we use Maven 3 ;-). Regards Mirko -- Sent from my mobile On Mar 9, 2013 12:15 AM, Brian Fox bri...@infinity.nu wrote: I don't think we should move to 4.0 because of this. The primary consumer of our systems are the end users and this change doesn't represent api breakage to them. If we make what appears to be such a large version change, that could scare off or confuse people who are just now warming up to 3.x. I think this does need to be resolved, but lets just call it 3.1 and notify the plugins that need to know directly. On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 6, 2013, at 6:09 PM, Olivier Lamy ol...@apache.org wrote: 2013/3/4 Hervé BOUTEMY herve.bout...@free.fr: some more personal thoughts and questions to make myself an opinion - about determining whether Aether API is biased or not: there was an argument for not developing Aether in Maven that was Aether API will be more generic to cover other dependency resolution mecanisms and repository formats, like P2. Is there something done on this area (be it P2 or anyhting else outside Maven use)? - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with the master incorporating Eclipse Aether: isn't it the area where the git move was expected to help? The 3.1.0 is just a bugfix branch, without much commits expected since the work will happen on master (and on every components/plugins having an impact from Eclipse Aether integration), or do I miss something? I suppose these outside component will require some time to adapt and propose a solution for users. In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) Regards, Hervé Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and
Re: Logback in Maven Core
Hi, please go for logback. I really wondered why slf4j was initially chosen at all, given logback is available and mature. We've been using logback at work in production for quite some time now and are very pleased. So yes, using logback in Maven is fine. Regards Ansgar Am 11.12.2012 03:33 schrieb Jason van Zyl ja...@tesla.io: Hi, I looked around a bit more today and I don't think SLF4J Simple is viable long term, I don't want to patch it anymore as I would have to do a day's work to make changes that keep the performance levels up, get it reviewed and released, and I honestly don't think it's worth it anymore. I would rather spend my time building out the plugin test cases and help to finish the classloader blocking of SLF4J. I don't mind spending time getting it all working but I don't want to waste my time on an implementation we're going to toss. After a conversation with the PMC it will require a vote to accept Logback which is EPL but I wanted to ask committers and interested users about using Logback. I believe Logback is the best choice as it's the most mature and battle tested implementation because once it goes in it's likely not ever to come out. Many of us are users and have integration experience with Logback and it's what I use everyday for logging in all my other projects and I've been a happy user for years. I see Logback as best of breed and widely adopted including 8 projects at Apache. There's no point in asking the PMC to vote on the acceptance of Logback if it's not acceptable by the community. If there are interested users I would really like to hear what you think because you're the ones who will have to live with the choice that is made. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: [VOTE] Maven Archetypes Parent 5 and Maven Archetype Plugin 1.2
Please remove it. I've seen it slipping into way too many poms of corporate projects, just to add more noise to the poms and give maven a bad name for being so hard to understand. So it as soon as possible. TIA + BR Ansgar Am 27.11.2012 21:46 schrieb Olivier Lamy ol...@apache.org: 2012/11/27 Robert Scholte rfscho...@apache.org: Hi Olivier, looks like a very nice and useful archetype. the configuration of the m-invoker-p could be smaller, since it includes some defaults. There's only one thing which always surprises me: why is the url filled with our site? marketing ? :-) more seriously I have no idea about the history. perso I don't have any trouble with that. Folks can remove that (and must if they deploy a web site) I've seen a lot of projects started with archetypes and they all keep this url untouched. I'd prefer to remove it, since it's almost never pointing to the project-page. -Robert Op Tue, 27 Nov 2012 00:54:58 +0100 schreef Olivier Lamy ol...@apache.org: Hi, I'd like to release the archetype for maven plugin. The goal is to have an archetype which generate project using new mojo annotations (and a sample to run maven-invoker-plugin) We fixed 2 issues: http://jira.codehaus.org/browse/MARCHETYPES/fixforversion/18708 Staging repository: https://repository.apache.org/content/repositories/maven-080/ To test it: mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-plugin -DarchetypeVersion=1.2 -DarchetypeRepository= https://repository.apache.org/content/repositories/maven-080/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MDEP-339 and MPIR-237
No, unfortunately I did not test anything. I'm just a happy/grateful maven user recognizing somebody has been spending his spare time to fix an issue. :-) Am 25.07.2012 22:36 schrieb Hervé BOUTEMY herve.bout...@free.fr: that's nice to see some interest did you try and check it works as you expect? Regards, Hervé Le mercredi 25 juillet 2012 07:50:34 Ansgar Konermann a écrit : That's great news. Thank you very much. Am 24.07.2012 22:49 schrieb Hervé BOUTEMY herve.bout...@free.fr: I think I finally fixed MDEP-339 and MPIR-237: these plugins should now be fully Maven 2 and Maven 3 compatible. AFAIK, m-project-info-reports-p is the last plugin that was causing trouble to publish standard site with Maven 3. maven-dependency-tree has been reworked to an thin layer on Maven 2 and Maven 3 dependency resolution code, and should easily be extensible in the future to any change like Eclipse Aether or any other implementation. I intend to release these 3 artifacts in about a week: please test and report if you find anything not as expected. Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MDEP-339 and MPIR-237
That's great news. Thank you very much. Am 24.07.2012 22:49 schrieb Hervé BOUTEMY herve.bout...@free.fr: I think I finally fixed MDEP-339 and MPIR-237: these plugins should now be fully Maven 2 and Maven 3 compatible. AFAIK, m-project-info-reports-p is the last plugin that was causing trouble to publish standard site with Maven 3. maven-dependency-tree has been reworked to an thin layer on Maven 2 and Maven 3 dependency resolution code, and should easily be extensible in the future to any change like Eclipse Aether or any other implementation. I intend to release these 3 artifacts in about a week: please test and report if you find anything not as expected. Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Plugins annotations support @Component role attribute to Class?
Am 20.05.2012 19:46 schrieb Hervé BOUTEMY herve.bout...@free.fr: here, the end-user is a plugin developer, then someone who should be able to create a (Plexus) component when necessary Yes, I liked @Component too but as soon as you write a component and inject somponents inside it, you discover the discrepency: the more I work on this, the more I discover these little discrepencies that lost me for a long time. Notice that the target is JSR330 @Inject. Is it too early to use @Inject? If @Inject supports all our use cases: go for it. It's standard, it's available. Why wait? Just my 2 cents. Best regards Ansgar Le dimanche 20 mai 2012 14:48:34 Olivier Lamy a écrit : Perso, I prefer @Component more auto documented name. IMHO The goal is to hide to end user what is used in core so why using plexus naming. 2012/5/20 Hervé BOUTEMY herve.bout...@free.fr: of course, +1 since we discussed it :) but thinking once more at it, I just found that @Component should be renamed to @Requirement, to match corresponding plexus annotation, isn't it? Regards, Hervé Le dimanche 20 mai 2012 09:00:05 Olivier Lamy a écrit : Hi, After discussion on irc with Hervé, I think role attribute in @Component can be of type Class? rather than String. @Component( role = ArtifactMetadataSource.class, roleHint = maven ) protected ArtifactMetadataSource artifactMetadataSource; Any objections on this change ? Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 1.5 Annotations for Mojo
Hi there, I think JFrog (the Artifactory guys) has already published a set of Java 1.5 annotations for mojo development, including a m-plugin-p extension to use them. The source code is available on github [1], but unfortunately the artifacts are not available in Central (there is a ticket in JFrog's JIRA [2] regarding this problem). They even have reasonably complete documentation [3] plus it's all under ASL 2.0 AFAICS. From my own experience, these annotations work quite well. Shouldn't they be incorporated or used as a starting point? I guess starting from JFrog's annotations will not only save a considerable amount of development time, but also increase acceptance with those plugin developers which already used the existing JFrog annotations in the past. Best regards Ansgar [1] https://github.com/JFrogDev/maven-anno-mojo [2] https://issues.jfrog.org/jira/browse/ANMJ-18 [3] http://wiki.jfrog.org/confluence/display/OSS/Maven+Anno+Mojo Am 27.04.2012 16:37 schrieb Olivier Lamy ol...@apache.org: Hi, I'd like to work on 1.5 Annotations for Mojos. Hervé started documentation here: https://cwiki.apache.org/confluence/display/MAVEN/Java+5+Annotations+for+Plugins The Stephen's idea for named without Mojo prefix looks fine (at least for me). But I would prefer to not implement (yet) the other idea with synthetic bridging classes. I can start the job next week (probably in a branch). Comments ? Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Preparation releases SCM 1.7 and MRELEASE 2.3
Am 20.04.2012 23:21 schrieb Olivier Lamy ol...@apache.org: Hi, Yes it looks some people need m-r-p which depends on a new scm so I moved SCM-623 to 1.8 I will start release proces early next week. Thank you very much Best regards Ansgar 2012/4/20 Robert Scholte apa...@sourcegrounds.com: Hi, due to several RFR's (request for release) for the maven-release-plugin I'd first like to release SCM-1.7 first. For SCM 1.7[1] we have 10 issues fixed, 2 open and 1 reopened. All these open issues are assigned to Olivier. SCM-658: HgChangeLogCommand doesn't implement method executeChangeLogCommand(); blocker, bug, 0 votes SCM-623: Add a configuration mode to be able to use git svn (at least for release plugin) ; major, new feature, 4 votes SCM-656: Building maven-scm-1.6 requires a native install of git.; major, bug, 0 votes Olivier, could you judge these issues? If there are other issues which should be part of this release, please let me know. -Robert [1] http://jira.codehaus.org/browse/SCM/fixforversion/18136?selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Next release of maven-release-plugin?
Hi all,
are there any chances to have a release of the maven-release-plugin in a
relatively short timeframe?
We're about to migrate a larger part of our build infrastructure to
Maven and would like to use MRELEASE-128 before we spread our proof of
concept into a wider scope.
It would help a lot if we could use properties in SCM connections, so we
can have even simpler project POMs and deduce the SCM connection strings
via a project-specific convention plus configuration in *one* parent
POM, like so:
connectionscm:svn:https://my.svnserver.local/repo/some-prefix/${project.groupId}/${project.artifactId}/trunk/connection
Thanks in advance for any answer.
Best regards
Ansgar
http://jira.codehaus.org/browse/MRELEASE-128
Re: GIT DIFF
Am 01.03.2012 01:41 schrieb Chris Graham chrisgw...@gmail.com: Can someone please walk me through exactly what it is doing? This is the wrong list for git-related questions. Best Ansgar It's doing two different diffs, and then I'm not sure what, and I certainly don't know why. TIA, -Chris
Re: maven release plugin introducing scm urls into modified poms
Am 20.02.2012 06:51 schrieb Chris Graham chrisgw...@gmail.com: Hi All. I have a multi module project that I have working perfectly. In tracking down a reported problem, I ran the release plugin with the -DpreparationGoals=help:effective-pom clean verify In it, I can see that it has added a scm section into the poms in the modules. Although this is with Jazz, the same happens in SVN as well. The urls that are rewritten in the root pom are correctly. I've added the JazzScmTranslator into the release manager. It adds a /sub module name to the end of the URL, which in Jazz's case, makes no sense, but it will make sense for SVN - and it's correct. Is there a way to stop this? Git also likes no submodule suffix in its scm urls. You could have a look at the git scm provider how it's implemented there. HTH Ansgar This only becomes a problem, when there is a scm section in a pom in one of the modules, as when it is written out, it is incorrect. Or is this an unsupported configuration? Ie, undefined behaviour? -Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Unable add java class dependency to my pom.xml
Am 24.01.2012 09:32 schrieb krrish516 murthy516.s...@gmail.com: Hi, I've a pom.xml of a project.I've a jar file of a java class in my local file system.How to add that my jar file dependency to my maven project.What are the steps to be followed.Please sis.uggest me in achieving th Use goal install-file of maven-install-plugin to install your Jar into your local maven repository. Then simply use Maven's dependency mechanism to reference the installed jar from your pom. -- View this message in context: http://maven.40175.n5.nabble.com/Unable-add-java-class-dependency-to-my-pom-xml-tp5280979p5280979.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: need info about Maven
Am 04.01.2012 19:45, schrieb Shamitha Reddy: the Microsoft JDBC Driver for SQL Server, can be made available within Maven Hi Shamitha, some introductory information what Maven is and how it is used can be found in various places, for example [1] [2] [3] Your customer most likely wants to use Maven to build Java projects, and use your JDBC driver the Maven way, that is, pull the JAR file into the compilation or runtime classpath using Maven's dependency mechanism. This is commonly and most easily done by uploading it into a corporate maven repository, managed by some Repository Manager like Nexus [4], Artifactory [5] or Archiva [6]. They all have a mechanism to upload JAR files which were not built/deployed by Maven. The only thing you or your customer have to take care of is to assign a unique identifier to this JAR file. For Maven, this 'identifier' is a structured one, consisting of groupId, artifactId and a version (and a type, but this is 'jar' by default, and thus does not need to be specified explicitly). This is the approach I'd recommend. Each Maven installation is then set up in a way that all requests to provide dependency artifacts (i. e. library JAR files) automatically go to the central repository manager, which distributes these artifacts to the maven installations on demand. This is a one-time setup effort and can be automated. If your customer wants to avoid the effort to set up a repository manager, you can also install the JAR file into Maven's local artifacts cache (so-called 'local repository'), by default living under $HOME/.m2/repository. This is typically done using the maven-install-plugin and its 'install-file' goal [7]. This might look easier at first, but since there is no corporate-wide repository manager, this step has to be performed on *each* Maven installation which should be used to compile/run Java code which employs your JDBC driver. Depending on organisation size, this can become cumbersome, especially when your JDBC driver is updated (you need to re-do this for the new version). You should ask your customer if they have already set up a corporate-wide Maven repository manager. Most likely, if they're not totally new to Maven and already doing serious software development with it, they'll have one anyway. Another option is to make your JAR file compatible with the requirements of the world-wide central library of Maven artifacts, or Maven Central for short. This means some more preparation from your side [8] and is only advisable if your product is intended to be used by a wide audience, preferrably as open source software. Your JAR file could then be deployed to Maven Central and any Maven installation could automatically pull it from there, without the need for uploading it to a corporate repository manager first. Best regards Ansgar [1] http://www.sonatype.com/books/mvnref-book/reference/index.html [2] http://en.wikipedia.org/wiki/Apache_Maven [3] http://maven.apache.org/ [4] http://nexus.sonatype.org/ [5] http://www.jfrog.com/products.php [6] http://archiva.apache.org/ [7] http://maven.apache.org/plugins/maven-install-plugin/usage.html [8] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Am 03.01.2012 22:12, schrieb Benson Margulies: On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... I disagree. There's no law requiring people to use 2.2.2 of the plugin. Hi, that's is an interesting point. No offense here, but what *is* the law w.r.t a Maven Release? I'm not that deep into Apache and Maven processes, but from what I could learn from public sources so far, I believe this is not clear altogether, and it might help to discuss this and make up our mind regarding such a law (i. e. release policy) to have a guideline for the future. Being a bit heretical: is it Maven's policy to release only Maven and wish the user luck to find out which versions of the core plugins work well with which version of Maven? Or can the average user expect to be reasonably safe if using the latest release of Maven with the latest release of any core plugin? From a user perspective, I perceive Maven as the Maven application plus its core plugins - they are basically one system. Agreed, it has a highly modular architecture, and a lot of these modules (= plugins) have decoupled release cycles, nevertheless it's IMHO hard to sell to the average user that the newest bugfix release of Maven with the newest bugfix release of the release plugin has *more* bugs than the slightly outdated one. This leads to another question: shouldn't we have system tests which make sure that common usage scenarios work with, say, the last N maven releases? That is: should plugins run their ITs against multiple versions of Maven? If so, how many versions should they go into the past? Or even better, shouldn't a *Maven* release trigger re-running the ITs of the most recent release of all core plugins', using the new Maven version? Add to this the fact that signing artifacts before deployment using gpg is mandatory for sync to central, so this is one of the more important use cases of the release plugin. Would love to hear more opinions on this. Best regards Ansgar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven release plugin not honoring -Darguments
Am 27.09.2011 14:48 schrieb David Blevins david.blev...@gmail.com: Is it a known issue that the release plugin does not honor the -Darguments? Specifically, I'm attempting to: mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true -DfailIfNoTests=false Try: mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true -DfailIfNoTests=false Notice the slightly different quoting (before -Darguments). Works well for me. Best regards Ansgar It takes 40 minutes to get through a dryRun with tests on. We still have several kinks in the build to work out before the release plugin will work, so obviously running with tests on every dryRun is just making a hard task impossible. maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1 -David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PROPOSAL] Java 5 Annotations for Plugins
Am 07.11.2011 16:31 schrieb Jesse Glick jesse.gl...@oracle.com: I do not think Phase should be an enum, just a list of String constants - you are permitted to define alternative lifecycles, right? New lifecycles: yes, possible (i. e.: which action to perform in which phase). New lifecycle *phases*: no, not to my knowledge, at least not without patching maven's core. Willing to learn if this is wrong, but till then, I prefer the enum solution to represent phases. Best regards, Ansgar
Re: is it possible to search on an artifactid without a groupid in a mojo?
Am 16.10.2011 09:57 schrieb Shaun Elliott javamonke...@gmail.com: Is it possible to search on an artifactid without a groupid in a mojo? I am using maven 3. I'd like to search for a given groupid in a mojo - I've been using: ArtifactMetadataSource, but it is deprecated and doesn't seem to have what I need. Is there something else I should be using? Is what I'm trying to do even possible? If your search space is not too large (say: limited to a few potential groupids) then it should be possible. You could Google for Sonatype Aether documentation and use that library directly to resolve all candidate artifacts until aether comes back without error code. (linear search). However, I'm not so sure why one would want this? Can you tell me mote about your use case (just curious). Maybe there is a much simpler solution for your problem? Thanks in advance Ansgar Thanks. -- René Descartes is in a bar at closing time. The bartender asks him if he'd like another drink. Descartes says, I think not, and he disappears.
Re: Maven Dependency Plugin
Am 12.09.2011 22:44, schrieb Jason Pyeron: On my hit list are the following: I'd like to add: * make dependency:tree work with Maven 3.0 (as Benjamin pointed out, it currently does not, because of the way Aether works when constructing the dependency tree) Best regards Ansgar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Project local setting.xml
Am 01.08.2011 22:09, schrieb Benson Margulies: I have several alternative design ideas. 0) If you religiously use a repository manager and mirrorOf *, you can prevent this rogues from bothering you. Hi, we do this and still have the need to use a settings.xml, for two reasons: - at work, different teams use different repository managers as mirror. On our CI server, we thus need to use our own settings.xml. - at home, I have a project which I want to build using both a local/private CI server and a public one, but they all use different repo managers as mirror *Nevertheless* I already do use project-specific settings.xml from SCM, in exactly this context. It's as easy as: - check in your settings.xml - run mvn -s settings.xml goals in checkout directory You could even split the settings.xml files into a different SCM repository and create one branch each for different environments, referring to the mirrors which should be active in this environment. Our CI server software can check out multiple SCM roots per build configuration, so we could checkout settings.xml (internal) + main code base on the internal CI server, plus settings.xml (public) + main code base on the public CI server. I don't strictly see the need to add auto-search functionality of settings.xml to Maven for this to work, the existing -s switch suffices at least for my use case. I can't see why this should not suffice for the use case of the OP. Best regards Ansgar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MavenProject / POM change in a command chain
Am 23.08.2011 18:43 schrieb Krull, Stephan stephan.kr...@ecg-leipzig.de: Hello there, I am currently working on a maven command chain to fulfill several tasks in one step on a maven project. the chain has the following syntax: ../apache-maven-2.2.1/bin/mvn clean versions:use-parent-release scm:checkin install Explanation: The command chain starts by changing the version number of the parent artifact in the POM file to a corresponding release version (i.e. if I declare version1.0.0-SNAPSHOT/version in the parent section of the POM this will be transformed to version1.0.0/version). After this change maven is going to commit these changes to the source code management. Thereafter I want maven to install the project with the new parent version number. The problem: Changing and committing the change runs perfectly but at the installation step maven is working with the old parent version. My guess is that although the file (pom.xml) has already changed in the filesystem, maven still holds the org.apache.maven.project.MavenProject object which at instantiation time got the POM information before transformation. That is a problem because I do not see a way to change the POM file and call install (or deploy) on that currently changed project configuration in one maven call. Why is this a problem in your use case? I. e. why can't you use multiple invocations of maven? Best regards, Ansgar Does anybody have a clue how to get around this problem? I have been looking around to special annotations for the mojo to call but have not been lucky. Maybe there is a (hidden) plugin that is able to inject a reloaded MavenProject object into the reactor. Appreciate your time reading this. Regards Stephan Krull ECG Erdgas-Consult GmbH Föpplstraße 3 04347 Leipzig / Germany +49 341 443-1583 (phone) +49 341 443-1855 (fax) mailto: stephan.kr...@ecg-leipzig.de mailto:stephan.kr...@ecg-leipzig.de Internet: www.ecg-leipzig.de http://www.ecg-leipzig.de/ __ ECG Erdgas-Consult GmbH Föpplstraße 3 04347 Leipzig / Germany Court of Register: Local Court of Leipzig HRB 16467 Chief Executive Officer: Dr. Peter Heine, Klaus-Dieter Görlich
Re: non-reproducible issues on CI
Had a similar if not same issue while developing a plugin. Fixed it by
adding
systemProperties
localRepository${repository.integrationtests}localRepository
systemProperties
to surefire plugin configuration in IT phase.
Works for me with surefire-plugin 2.9 and invoker-plugin 1.5
Regards,
Ansgar
Am 31.07.2011 13:50 schrieb Dennis Lundberg denn...@apache.org:
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
Am 26.07.2011 01:27, schrieb Kasun Gajasinghe: Manually, editing the pom with the available plugin versions is much complicated, http://mojo.codehaus.org/versions-maven-plugin/update-parent-mojo.html Automate this using a CI server and you're probably mostly done. Best Ansgar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
Am 26.07.2011 00:56, schrieb Kasun Gajasinghe: So, doesn't having an intermediary layer that will point to newer set of plugins is justified? Sure. Simplest solution that will work: use your own parent pom with an updated pluginManagement section. Ansgar - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Set specific plugin versions for a project - issue in plugin-registry.xml/maven-metada-local.xml
Am 26.07.2011 21:14, schrieb Ansgar Konermann: Am 26.07.2011 01:27, schrieb Kasun Gajasinghe: I'm sorry, wrong list. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
