Re: Dependency to native dll
I just now realized that you've mailed the maven dev mailing list. These type of questions should be posted to the users list. /Anders On Tue, Nov 16, 2010 at 14:49, Halvor Platou halvor.pla...@marinecyb.comwrote: Ok, then I can load the .dll directly from the local repository with System.load(...). Seems it will automatically be downloaded to the local repo when the plugin has a dependency to it. Thanks for the help! Halvor -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: 16. november 2010 14:17 To: Maven Developers List Subject: Re: Dependency to native dll The dependency is not supposed to end up in the target. It should be added to the classpath though. /Anders On Tue, Nov 16, 2010 at 14:09, Halvor Platou halvor.pla...@marinecyb.com wrote: OK, thanks again, but I'm still struggling. Probably something I've missed. I declare the dll-dependency in the maven-plugin project. The plugin compiles without any problems. No .dll in the target directory unless I specify an execution of dependency-plugin - which is fine. In the project using my plugin, I have my plugin specified in the build section running an execution in the generate-sources phase. At this stage I can't find the .dll anyware in the target-folder. Even if I specify a separate execution of dependency-plugin in the pom, the plugin dll-dependency is nowhere to be found in the target folder. Are the plugin-dependencies not put in the target-folder during execution? Halvor -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: 16. november 2010 13:07 To: Maven Developers List Subject: Re: Dependency to native dll Declare it as a dependency in the maven-plugin. That is, in the project where you develop the plugin. Just like any dependency. Or if you want to be able to change this dependency (like version or what ever), you can add it as a dependency to the plugin where you bind the plugin in your maven project. /Anders On Tue, Nov 16, 2010 at 12:55, Halvor Platou halvor.pla...@marinecyb.com wrote: Thanks for your reply. This is working perfectly for a normal maven project, but when my maven-plugin has a dependency to the dll, I can't figure out how the plugin itself can fetch this dependency during execution. I don't find the dll in the target-folder for the project that is build using my plugin. Halvor -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: 16. november 2010 12:36 To: Maven Developers List Subject: Re: Dependency to native dll Add it to your repo and declare a dependency. Loads of dissussions about this on the Internet. Here's one: http://stackoverflow.com/questions/1001774/managing-dll-dependencies-with-maven /Anders On Tue, Nov 16, 2010 at 12:27, Halvor Platou halvor.pla...@marinecyb.com wrote: I'm developing a plugin that has a dependency to a native dll. How can I find and load this dll during execution of my plugin? Halvor Marine Cybernetics Office Address: Vestre Rosten 77, 9th floor Postal Address: Vestre Rosten 77, NO-7075 TILLER, NORWAY Telephone: [+47] 98 62 58 50 Fax: [+47] 72 88 43 31 E-mail: halvor.pla...@marinecyb.com URL: www.marinecybernetics.com - 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 - 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: svn commit: r1036834 - in /maven/archetype/trunk: ./ archetype-common/ archetype-common/src/main/mdo/ archetype-models/ archetype-models/archetype-catalog/ archetype-models/archetype-catalog/src/
Hi Tamás, Author: cstamas Date: Fri Nov 19 13:37:58 2010 New Revision: 1036834 URL: http://svn.apache.org/viewvc?rev=1036834view=rev Log: ARCHETYPE-303: applied fix, externalizing all the models into separate project (except the deprecated one, that is left where it was). [...] Added: maven/archetype/trunk/archetype-models/ (with props) maven/archetype/trunk/archetype-models/archetype-catalog/ (with props) maven/archetype/trunk/archetype-models/archetype-catalog/pom.xml maven/archetype/trunk/archetype-models/archetype-catalog/src/ maven/archetype/trunk/archetype-models/archetype-catalog/src/main/ maven/archetype/trunk/archetype-models/archetype-catalog/src/main/mdo/ maven/archetype/trunk/archetype-models/archetype-catalog/src/main/mdo/archetype-catalog.mdo maven/archetype/trunk/archetype-models/archetype-descriptor/ (with props) maven/archetype/trunk/archetype-models/archetype-descriptor/pom.xml maven/archetype/trunk/archetype-models/archetype-descriptor/src/ maven/archetype/trunk/archetype-models/archetype-descriptor/src/main/ maven/archetype/trunk/archetype-models/archetype-descriptor/src/main/mdo/ maven/archetype/trunk/archetype-models/archetype-descriptor/src/main/mdo/archetype-descriptor.mdo maven/archetype/trunk/archetype-models/archetype-registry/ (with props) maven/archetype/trunk/archetype-models/archetype-registry/pom.xml maven/archetype/trunk/archetype-models/archetype-registry/src/ maven/archetype/trunk/archetype-models/archetype-registry/src/main/ maven/archetype/trunk/archetype-models/archetype-registry/src/main/mdo/ maven/archetype/trunk/archetype-models/archetype-registry/src/main/mdo/archetype-registry.mdo maven/archetype/trunk/archetype-models/pom.xml The new files are missing SVN properties, especially svn:eol-style, please check your SVN client is properly configured [0]. Benjamin [0] http://maven.apache.org/developers/committer-environment.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1036834 - in /maven/archetype/trunk: ./ archetype-common/ archetype-common/src/main/mdo/ archetype-models/ archetype-models/archetype-catalog/ archetype-models/archetype-catalog/src/
What? What eol style? Is there any other proper OS on planet Earth aside UNIX? :D Sorry, you were true. SVN client is now properly configures, by the book. What should happen with committed files? How to reapply properties there? Thanks, ~t~ On Fri, Nov 19, 2010 at 2:45 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi Tamás, The new files are missing SVN properties, especially svn:eol-style, please check your SVN client is properly configured [0]. Benjamin [0] http://maven.apache.org/developers/committer-environment.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Doxia 1.1.4 and Maven Doxia Sitetools 1.1.4 take 2
+1 On 2010-11-16 21:40, Dennis Lundberg wrote: Hi, This is the second try to release Doxia. A failing test was fixed since the last release attempt. We solved 5+2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=16702 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=16694 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repo: https://repository.apache.org/content/repositories/maven-007/ Staging sites: http://maven.apache.org/doxia/doxia-1.1.4/ http://maven.apache.org/doxia/doxia-sitetools-1.1.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Use of standards in the Maven core
On 11/18/2010 03:34 AM, Kristian Rosenvold wrote: The rant is somewhat about seeing all these internal components. A little bit, though it is generally easy to see from the package or class name that something should be considered an implementation. My slow learning curve has had to do with the interfaces, probably not helped by starting from embedder code originally written against Maven 2 that was probably doing things the wrong way. I should note that what I have seen so far of Aether interfaces has been much more clearly documented, and the code looks to do a better job of noticing invalid or missing parameters and throwing helpful exceptions early. So I think the issue is that older code never got fully documented or made foolproof, which is understandable given the focus on shipping 3.0. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Access to the raw list of dependencies - multiple versions of an artifact included
On 11/18/2010 07:20 PM, Rex Hoffman wrote: it's pretty straight forward if you use some code provided by the dependencies library (part of the maven-dependencies-plugin) Beware that this does _not_ produce the same results as Aether in certain cases, and there is no apparent plan to fix it: http://jira.codehaus.org/browse/MSHARED-167 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0.1-RC1
Works fine on a multi module Android project with plain library, Android application and instrumentation test modules. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Access to the raw list of dependencies - multiple versions of an artifact included
Ouch... not cool... Aether apparently has a very similar construct to the one I used see: https://github.com/sonatype/sonatype-aether/blob/master/aether-api/src/main/java/org/sonatype/aether/graph/DependencyVisitor.java as far as what goes into instantiating everything you need to run it, I don't know yet. But I guess I need to update my enforcer rule to use Aether Api. I'm more than a little shocked at problem. Some point over the weekend I'll dig through the mailing lists to see what if anything is planned to be done about this. Plan: Maybe we should construct a cleaner api though. One that could wrap maven-dependency-tree in maven 2.2.1 and use aether in 3.0. It should be a very clean api (nothing but interfaces) and have two implementation, one over each implementation. It's a good sign that this visitor pattern made it through two different implementation. It's very bad that it wasn't made portable. I'd be happy to help you with this if you decide to go down this path, and the maven-devs agree that it's probably the best approach. At least, aether has an api jar file. Which could make future changes like this less painful if we rely on it directly. Looks like it has too much in it though, and a good number of implementation class. Which limits it's ability to be decouple parts of maven Rex On Fri, Nov 19, 2010 at 9:15 AM, Jesse Glick jesse.gl...@oracle.com wrote: On 11/18/2010 07:20 PM, Rex Hoffman wrote: it's pretty straight forward if you use some code provided by the dependencies library (part of the maven-dependencies-plugin) Beware that this does _not_ produce the same results as Aether in certain cases, and there is no apparent plan to fix it: http://jira.codehaus.org/browse/MSHARED-167 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Solving SUREFIRE-141 ; pluggable providers
I have been refactoring quite heavily on the surefire plugin the last weeks. This has been entirely non-functional with the intent of loosening the internal dependencies (without breaking the existing plugin) enough to create a starting point for solving SUREFIRE-141. At the moment I am quite satisfied with where the plugin is at, and we need to take some decisions on how the SUREFIRE-141 can be solved. Those of you who are familiar with the old surefire might want to have a look at svn HEAD, since there's been considerable changes around the booter. At the moment I feel this discussion is required before I can move on: I have two different proposals here. Both of them have some details that need to be solved, but I have come to the conclusion that the key issue to be resolved is how parameters arrive at the individual providers: A) Pile it up Adding all the provider-specific settings to the main surefire plugin was probably a mistake; but this solution assumes we'll have to live with that. The current list of parameters at http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html is probably reasonably close to complete for java xUnit, leaving room for some future expansion there might be 5-10 more for java, and maybe (wild guess) 20-30 other parameters for other languages, assuming they re-use the existing parameters for similar meanings. All in all it could be handled by documentation. - Technically we could just transparently serialize ANY parameter given to the surefire-plugin through the booter to the provider, without the surefire plugin trying to find out if the provider will use them or not. The provider knows its own requirements and will sort it out. - Any new parameters required by a new provider would have to be added to the surefire-plugin. - Detect user-specified providers in the suerfire-plugin's dependencies, which would disable the current autodetection. - The only real piece of work remaining for this is cleaning up the provider instantiation parameter transfer. Could/would probably be feature complete with 2.7 release. B) Per-provider plugins Surefire is basically a library providing classpath scanning, forking and reporting services. Extract the necessary interfaces so that a plugin can simply declare a dependency on the required services and have them wired in via plexus or similar. - Extract interfaces so that similar features (e.g. fork configuration, classloader settings and reporting settings) become homogenous in terms of plugin parameters, even though there is one distinct mojo per provider. Assume no more re-use between plugins than this. - Deprecate the current surefire plugin and declare that no new parameters EVER will be added to it. All new parameters will only be added to the provider-specific plugins. - Make the deprecated surefire plugin delegate to the 4 well known new mojos (testng, junit3, junit4, junit47), so that the deprecated plugin can be kept indefinitely compatible at surefire 2.6 level. Users wishing post-2.6 features will have to declare an explicit plugin dependency to the specific mojo. - Make all surefire mojos implement a specific interface/marker of some sort. The old surefire-plugin will have to detect the presence of any such mojo; if any such explicit declaration exists, the old surefire does nothing. - Converting from old-style surefire declaration to the new per-provider-mojo should basically be about replacing GAV identifier in the pom to the provider-specific version, since this by definition should accept all the same parameters as the existing surefire mojo. - The important stuff (extracting the libraries that can be used by anyone) should be doable for 2.7, maybe converting one or two of the current providers in the process; I like using the junit47 provider for this stuff since it's mostly used by folks running // junit. Porting ALL the existing providers to this schema can probably wait until 2.8-2.9 ish. An advantage of this approach would be the ability to NOT finalize the api's for 2.7 but to be able to adjust this slightly if/when someone wants to write an independent provider (or fork one of the existing ones - the guy who wanted to do parallel junit 3 comes to mind), and maybe aim for a surefire 3.0 like target for the first officially frozen api. My only uncertainty wrt this second option is how failsafe would fit in; maybe Stephen has some thoughts on this... What do you think ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JIRA project for ASF/Maven parent POM issues
Hi, can some JIRA admin please move the MNG component Apache or Maven Parent poms http://jira.codehaus.org/browse/MNG/component/14457 out into a separate JIRA project? Those POMs, just like any Maven plugin out there, have no inherent relation to the Maven core and its issues, nor do they share the same release/version cycle. Thanks Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
I have a slight concern. It goes into testing portability (running in maven, or eclipse, idea, netbeans, or via command line) In short, the smarter we make maven about running tests, the less easy it is for a developer to run that same test via IDE or something similar. I'll give two common examples and hope it makes the point. If we add test-ng listeners to the maven surefire plugin config, those same tests wont run the same in eclipse without adding the listeners as annotations to the class. Eliminating the need to add the Listeners to maven config in the first place. Same is true of the life cycle phases around integration tests. People often start jetty and run selenium style test in the integration test phase via maven. It might be better to use an annotations or something similar on that tests that loads the needed data and starts the application (if not already running). That way a right click and a run as in an IDE would be enough to run the test. Seems like energy is being put into allowing and promoting sub-optimal solutions. Maybe helper libraries meant to be used by test developers, that are not tied to maven, but make the running of tests in maven cleaner would be a better approach to promote? Move the mountain as it were So in short maybe a C approach. Keep maven test running as simple and unconfigurable as possible, provide some libraries and documentation to bridge any gaps. Forking config, sure... Ant style file includes, definitely, anything that has to do specifically with the configuration of any implementation of a test runner should not possible via maven. Not sure if this is useful with what has been already implemented. But while getting companies to switch to maven and start testing, it has proven a challenge in the past, and this solution has been the one I found that worked for devs, qa and automation teams. I wrote a small library for testNG: http://www.epolity.net/blog/2010/04/testng-extensions-to-bridge-the-small-gap-between-maven-and-testng/ and found that the less config I put in maven, the easier it was to develop and run tests. My two pennies Rex On Fri, Nov 19, 2010 at 10:58 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I have been refactoring quite heavily on the surefire plugin the last weeks. This has been entirely non-functional with the intent of loosening the internal dependencies (without breaking the existing plugin) enough to create a starting point for solving SUREFIRE-141. At the moment I am quite satisfied with where the plugin is at, and we need to take some decisions on how the SUREFIRE-141 can be solved. Those of you who are familiar with the old surefire might want to have a look at svn HEAD, since there's been considerable changes around the booter. At the moment I feel this discussion is required before I can move on: I have two different proposals here. Both of them have some details that need to be solved, but I have come to the conclusion that the key issue to be resolved is how parameters arrive at the individual providers: A) Pile it up Adding all the provider-specific settings to the main surefire plugin was probably a mistake; but this solution assumes we'll have to live with that. The current list of parameters at http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html is probably reasonably close to complete for java xUnit, leaving room for some future expansion there might be 5-10 more for java, and maybe (wild guess) 20-30 other parameters for other languages, assuming they re-use the existing parameters for similar meanings. All in all it could be handled by documentation. - Technically we could just transparently serialize ANY parameter given to the surefire-plugin through the booter to the provider, without the surefire plugin trying to find out if the provider will use them or not. The provider knows its own requirements and will sort it out. - Any new parameters required by a new provider would have to be added to the surefire-plugin. - Detect user-specified providers in the suerfire-plugin's dependencies, which would disable the current autodetection. - The only real piece of work remaining for this is cleaning up the provider instantiation parameter transfer. Could/would probably be feature complete with 2.7 release. B) Per-provider plugins Surefire is basically a library providing classpath scanning, forking and reporting services. Extract the necessary interfaces so that a plugin can simply declare a dependency on the required services and have them wired in via plexus or similar. - Extract interfaces so that similar features (e.g. fork configuration, classloader settings and reporting settings) become homogenous in terms of plugin parameters, even though there is one distinct mojo per provider. Assume no more re-use between plugins than this. - Deprecate the current surefire plugin and declare that no new parameters
Re: svn commit: r1037014 - /maven/indexer/
doh ! sure a big rollback here :-) 2010/11/19 bdem...@apache.org: Author: bdemers Date: Fri Nov 19 20:35:26 2010 New Revision: 1037014 URL: http://svn.apache.org/viewvc?rev=1037014view=rev Log: rolling back did not remove the tag Removed: maven/indexer/ -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0.1-RC1
Works fine for all Sonar projects, including based on Tycho. On Fri, Nov 19, 2010 at 20:38, Manfred Moser manf...@mosabuam.com wrote: Works fine on a multi module Android project with plain library, Android application and instrumentation test modules. manfred - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Best regards, Evgeny Mandrikov aka Godin http://godin.net.ru http://twitter.com/_godin_ http://www.SonarSource.com http://www.sonarsource.com/
Re: svn commit: r1037014 - /maven/indexer/
yeah, bad day today In the process now, it seems my hands didn't feel like typing tags/... On Fri, Nov 19, 2010 at 3:46 PM, Olivier Lamy ol...@apache.org wrote: doh ! sure a big rollback here :-) 2010/11/19 bdem...@apache.org: Author: bdemers Date: Fri Nov 19 20:35:26 2010 New Revision: 1037014 URL: http://svn.apache.org/viewvc?rev=1037014view=rev Log: rolling back did not remove the tag Removed: maven/indexer/ -- Olivier Lamy http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Solving SUREFIRE-141 ; pluggable providers
I think what you're advocating is much of what one would achieve with per-provider plugins. The idea here is to extract the common functionality of surefire (some of which is *hard* to get right) into separate module(s) which each plugin can choose to use or not. To achieve a certain kind of end-user consistency in how the user specifies parameters they can choose to use the common properties interfaces to define the mojo attributes. The net long term effect is that you'd probably end up with a number of different testng providers, one less-is-more plugin or a surefire traditional testng plugin and another more is more plugin that would support the whole shebang and then some. And the ones that support forking execution would *probably* be using the surefire forking module, but the per-provider plugin strategy mandates very few such absolute choices, since the different mojos can choose which bits to use free of constraints from what the others are doing. Personally I will not implement any solution that does not have a decent migration path for existing users, so any option that alienates existing users is a clear -1 from me. Part of the problem with existing surefire is that it's overly prescriptive in terms of what must be shared/common between the different providers. And quite a few of these assumptions are just not generalizable; they turned out to be relevant for only 1 provider. So I can easily see this turning into a small handful of old-skool providers here at apache, with various forks popping up for less-is-more or more-is-more at github. I kind of like that kind of ecosystem, which would give a freedom of choice that is not available currently. Kristian fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman: I have a slight concern. It goes into testing portability (running in maven, or eclipse, idea, netbeans, or via command line) In short, the smarter we make maven about running tests, the less easy it is for a developer to run that same test via IDE or something similar. I'll give two common examples and hope it makes the point. If we add test-ng listeners to the maven surefire plugin config, those same tests wont run the same in eclipse without adding the listeners as annotations to the class. Eliminating the need to add the Listeners to maven config in the first place. Same is true of the life cycle phases around integration tests. People often start jetty and run selenium style test in the integration test phase via maven. It might be better to use an annotations or something similar on that tests that loads the needed data and starts the application (if not already running). That way a right click and a run as in an IDE would be enough to run the test. Seems like energy is being put into allowing and promoting sub-optimal solutions. Maybe helper libraries meant to be used by test developers, that are not tied to maven, but make the running of tests in maven cleaner would be a better approach to promote? Move the mountain as it were So in short maybe a C approach. Keep maven test running as simple and unconfigurable as possible, provide some libraries and documentation to bridge any gaps. Forking config, sure... Ant style file includes, definitely, anything that has to do specifically with the configuration of any implementation of a test runner should not possible via maven. Not sure if this is useful with what has been already implemented. But while getting companies to switch to maven and start testing, it has proven a challenge in the past, and this solution has been the one I found that worked for devs, qa and automation teams. I wrote a small library for testNG: http://www.epolity.net/blog/2010/04/testng-extensions-to-bridge-the-small-gap-between-maven-and-testng/ and found that the less config I put in maven, the easier it was to develop and run tests. My two pennies Rex On Fri, Nov 19, 2010 at 10:58 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I have been refactoring quite heavily on the surefire plugin the last weeks. This has been entirely non-functional with the intent of loosening the internal dependencies (without breaking the existing plugin) enough to create a starting point for solving SUREFIRE-141. At the moment I am quite satisfied with where the plugin is at, and we need to take some decisions on how the SUREFIRE-141 can be solved. Those of you who are familiar with the old surefire might want to have a look at svn HEAD, since there's been considerable changes around the booter. At the moment I feel this discussion is required before I can move on: I have two different proposals here. Both of them have some details that need to be solved, but I have come to the conclusion that the key issue to be resolved is how parameters arrive at the individual providers: A) Pile it up Adding all the provider-specific settings
[RESULT] [VOTE] Release Maven Doxia 1.1.4 and Maven Doxia Sitetools 1.1.4 take 2
Hi, The vote has passed with the following result : +1 (binding): Lukas Theussl, Vincent Siveton, Hervé Boutemy, Olivier Lamy, Dennis Lundberg I will promote the artifacts to the central repo. Thanks to those who votes for this release! On 2010-11-16 21:40, Dennis Lundberg wrote: Hi, This is the second try to release Doxia. A failing test was fixed since the last release attempt. We solved 5+2 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=16702 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624styleName=Htmlversion=16694 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11624status=1 Staging repo: https://repository.apache.org/content/repositories/maven-007/ Staging sites: http://maven.apache.org/doxia/doxia-1.1.4/ http://maven.apache.org/doxia/doxia-sitetools-1.1.4/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA project for ASF/Maven parent POM issues
+1 Arnaud On Nov 19, 2010, at 9:03 PM, Benjamin Bentmann wrote: Hi, can some JIRA admin please move the MNG component Apache or Maven Parent poms http://jira.codehaus.org/browse/MNG/component/14457 out into a separate JIRA project? Those POMs, just like any Maven plugin out there, have no inherent relation to the Maven core and its issues, nor do they share the same release/version cycle. Thanks Benjamin - 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: Solving SUREFIRE-141 ; pluggable providers
I don't think that the option C would prevent a fairly painless migration path. Though it's been a while since I've used the older junits, so I don't know. The libraries to configure the tests outside of maven would be need for the standard testing environments (junit, testng), and would hopefully work in IDEs as well. I think we can eliminate the problem your trying to solve by moving the means of configuring the test library outside of maven. Maven just tried to do to much here. This was helpful to gain initial adoption, but ultimately just leads to unneeded coupling, for both maven and logical runtime of the tests maven runs. Maybe allow config from both the plugin and lib initially, and on a 3.0 drop support for the non-generic plugin config? We could still pass info as system parameters, through to the helper library, which users could have default overrides for set in there IDEs The work your doing to decouple various parts of the test plugin and it's apis is very cool. Thanks for tackling this problem! Apologies for being a little opinionated on the matter. Rex On Fri, Nov 19, 2010 at 12:50 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think what you're advocating is much of what one would achieve with per-provider plugins. The idea here is to extract the common functionality of surefire (some of which is *hard* to get right) into separate module(s) which each plugin can choose to use or not. To achieve a certain kind of end-user consistency in how the user specifies parameters they can choose to use the common properties interfaces to define the mojo attributes. The net long term effect is that you'd probably end up with a number of different testng providers, one less-is-more plugin or a surefire traditional testng plugin and another more is more plugin that would support the whole shebang and then some. And the ones that support forking execution would *probably* be using the surefire forking module, but the per-provider plugin strategy mandates very few such absolute choices, since the different mojos can choose which bits to use free of constraints from what the others are doing. Personally I will not implement any solution that does not have a decent migration path for existing users, so any option that alienates existing users is a clear -1 from me. Part of the problem with existing surefire is that it's overly prescriptive in terms of what must be shared/common between the different providers. And quite a few of these assumptions are just not generalizable; they turned out to be relevant for only 1 provider. So I can easily see this turning into a small handful of old-skool providers here at apache, with various forks popping up for less-is-more or more-is-more at github. I kind of like that kind of ecosystem, which would give a freedom of choice that is not available currently. Kristian fr., 19.11.2010 kl. 12.13 -0800, skrev Rex Hoffman: I have a slight concern. It goes into testing portability (running in maven, or eclipse, idea, netbeans, or via command line) In short, the smarter we make maven about running tests, the less easy it is for a developer to run that same test via IDE or something similar. I'll give two common examples and hope it makes the point. If we add test-ng listeners to the maven surefire plugin config, those same tests wont run the same in eclipse without adding the listeners as annotations to the class. Eliminating the need to add the Listeners to maven config in the first place. Same is true of the life cycle phases around integration tests. People often start jetty and run selenium style test in the integration test phase via maven. It might be better to use an annotations or something similar on that tests that loads the needed data and starts the application (if not already running). That way a right click and a run as in an IDE would be enough to run the test. Seems like energy is being put into allowing and promoting sub-optimal solutions. Maybe helper libraries meant to be used by test developers, that are not tied to maven, but make the running of tests in maven cleaner would be a better approach to promote? Move the mountain as it were So in short maybe a C approach. Keep maven test running as simple and unconfigurable as possible, provide some libraries and documentation to bridge any gaps. Forking config, sure... Ant style file includes, definitely, anything that has to do specifically with the configuration of any implementation of a test runner should not possible via maven. Not sure if this is useful with what has been already implemented. But while getting companies to switch to maven and start testing, it has proven a challenge in the past, and this solution has been the one I found that worked for devs, qa and automation teams. I wrote a small library for testNG:
Re: Solving SUREFIRE-141 ; pluggable providers
On 19 November 2010 18:58, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I have been refactoring quite heavily on the surefire plugin the last weeks. This has been entirely non-functional with the intent of loosening the internal dependencies (without breaking the existing plugin) enough to create a starting point for solving SUREFIRE-141. Cool At the moment I am quite satisfied with where the plugin is at, and we need to take some decisions on how the SUREFIRE-141 can be solved. Those of you who are familiar with the old surefire might want to have a look at svn HEAD, since there's been considerable changes around the booter. At the moment I feel this discussion is required before I can move on: I'll have to see if I can find some cycles... work is mad while they try to find my replacement! I have two different proposals here. Both of them have some details that need to be solved, but I have come to the conclusion that the key issue to be resolved is how parameters arrive at the individual providers: A) Pile it up Adding all the provider-specific settings to the main surefire plugin was probably a mistake; but this solution assumes we'll have to live with that. The current list of parameters at http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html is probably reasonably close to complete for java xUnit, leaving room for some future expansion there might be 5-10 more for java, and maybe (wild guess) 20-30 other parameters for other languages, assuming they re-use the existing parameters for similar meanings. All in all it could be handled by documentation. - Technically we could just transparently serialize ANY parameter given to the surefire-plugin through the booter to the provider, without the surefire plugin trying to find out if the provider will use them or not. The provider knows its own requirements and will sort it out. - Any new parameters required by a new provider would have to be added to the surefire-plugin. Or we could use tricks (I say tricks, but they're not really so much tricks as more advanced ways of doing things) like, e.g. enforcer uses to basically let the provider's config be exposed through a specific sub-option basically that sub-option would have a custom xml deserializer that we could map to the providers configuration, eliminating the need to pass extra through, and in fact allowing us to fail faster if the configuration is invalid... though I am not sure how far along the lifecycle our deserializer gets invoked, and tooling such as intellij and perhaps eclipse would not be able to give autocomplete when editing the custom section. - Detect user-specified providers in the suerfire-plugin's dependencies, which would disable the current autodetection. I think if we use the SPI mechanism to detect providers... but now that I think about is perhaps you might want to have two providers running different tests from the same execution... - The only real piece of work remaining for this is cleaning up the provider instantiation parameter transfer. Could/would probably be feature complete with 2.7 release. B) Per-provider plugins Surefire is basically a library providing classpath scanning, forking and reporting services. Extract the necessary interfaces so that a plugin can simply declare a dependency on the required services and have them wired in via plexus or similar. - Extract interfaces so that similar features (e.g. fork configuration, classloader settings and reporting settings) become homogenous in terms of plugin parameters, even though there is one distinct mojo per provider. Assume no more re-use between plugins than this. - Deprecate the current surefire plugin and declare that no new parameters EVER will be added to it. All new parameters will only be added to the provider-specific plugins. - Make the deprecated surefire plugin delegate to the 4 well known new mojos (testng, junit3, junit4, junit47), so that the deprecated plugin can be kept indefinitely compatible at surefire 2.6 level. Users wishing post-2.6 features will have to declare an explicit plugin dependency to the specific mojo. Not sure how this would fit in with the pre-3.0 builds... we might be screwing the over if we are doing the delegation - Make all surefire mojos implement a specific interface/marker of some sort. The old surefire-plugin will have to detect the presence of any such mojo; if any such explicit declaration exists, the old surefire does nothing. - Converting from old-style surefire declaration to the new per-provider-mojo should basically be about replacing GAV identifier in the pom to the provider-specific version, since this by definition should accept all the same parameters as the existing surefire mojo. - The important stuff (extracting the libraries that can be used by anyone) should be doable for 2.7, maybe converting one or two of the current providers in the process; I like
