Re: Maven plugin - some licensing questions
Hi Karl On 2016-07-01 14:09, Karl Heinz Marbaise wrote: > Hi, > > On 7/1/16 1:54 PM, Grzegorz Słowikowski wrote: >> Thank you very much Stian. >> >> I have some more technical questions. >> >> 1. >> >> When I wrote about using modified class from Maven core I thought about >> ExecutionEventLogger class from maven-embedder >> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java) >> > >> >> I wanted to change Logger interface >> (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50) >> >> and use org.apache.maven.plugin.logging.Log available in Maven plugins. > > This means you changing the interface which means your version of Maven > is not compatible with the Apache Maven ? No > >> >> Now I'm testing another approach. I've added provided dependency on >> maven-embedder and use original class. Minimal Maven version is set to >> 3.1.0 in prerequisities of my plugin. >> >> My first question is, can I expect ExecutionEventLogger to be stable API >> in future releases? > > > What I don't understand is why you need to change such interface? May be > you can describe your exact problems (here on the list) or better into a > JIRA ticket and may be the Maven project can help or change things there > if it makes sense...Or your provide a patch (as already mentioned) to > solve your problem ? > > Otherwise you start to creating a Maven which is not compatible with > Apache Maven which will confuse people and will produce many problems... > I didn't write it before, I'm implementing mojo running the application (Play! Framework), watching source changes and rebuilding projects, all this while application is still running. Play! Framework supports this. They use SBT and I'm reimplementing this functionality in Maven. To run Maven build, I create 'MavenExecutionRequest', new 'MavenSession', etc. and execute this session using 'LifecycleExecutor'. To see build progress, I need 'ExecutionListener' (see https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java#L376) There is one implementation available in maven-embedder https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java I didn't want to depend on 'maven-embedder', so my first thought was to copy this class, change 'org.slf4j.Logger' class of the 'logger' variable to 'org.apache.maven.plugin.logging.Log', I have (in 'AbstractMojo') Advantage - I control the class Disadvantages - e.g. no colors in future Maven versions (because using class from Maven not supporting colors yet), licensing questions > > > > Kind regards > Karl Heinz Marbaise > > > >> >> My second questions is how and where should I describe my modifications? >> Do I need to provide somehow the original source of modified class? >> >> 2. >> >> When using (not modified) classes from another ASLv2 project do I need >> to create NOTICE file (I've had no NOTICE file before) in the root >> directory of my repository containing: >> >> This product includes software developed at >> XXX Inc. <https://www.xxx.com>, >> which is licensed under the Apache 2 license. >> >> Is this note OK? >> >> Additionally, identical NOTICE file should be added to >> /src/main/resources/META-INF directory of every module using external >> classes, right? >> >> >> I will ask next questions on legal-disc...@apache.org. Thank you in >> advance. Regards. >> >> Grzegorz Slowikowski >> >> >> On 2016-06-30 12:24, Stian Soiland-Reyes wrote: >>> This would be more a question for legal-disc...@apache.org, but I'll >>> try to respond anyway :). Sorry for the long answer.. Please correct >>> me! >>> >>> On 29 June 2016 at 19:30, Grzegorz Słowikowski >>> <gslowikow...@gmail.com> wrote: >>>> 1. Can I include slightly modified class from Maven code in one of my >>>> plugins? How should I note this fact? >>> >>> Of course - that's explicitly permitted as long as you follow the >>> Apache License clause 5 >>> >>> https://www.apache.org/licenses/LICENSE-2.0.html#redistribution >>> >>> >>> You should note it by keeping the license header in the files, and by >>> propagating the content of the NOTICE from the Maven code, e.g. from >>> >>> https://github.com/apache/maven/blob/master/
Re: Maven plugin - some licensing questions
Thank you very much Stian. I have some more technical questions. 1. When I wrote about using modified class from Maven core I thought about ExecutionEventLogger class from maven-embedder (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java) I wanted to change Logger interface (https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java#L50) and use org.apache.maven.plugin.logging.Log available in Maven plugins. Now I'm testing another approach. I've added provided dependency on maven-embedder and use original class. Minimal Maven version is set to 3.1.0 in prerequisities of my plugin. My first question is, can I expect ExecutionEventLogger to be stable API in future releases? My second questions is how and where should I describe my modifications? Do I need to provide somehow the original source of modified class? 2. When using (not modified) classes from another ASLv2 project do I need to create NOTICE file (I've had no NOTICE file before) in the root directory of my repository containing: This product includes software developed at XXX Inc. <https://www.xxx.com>, which is licensed under the Apache 2 license. Is this note OK? Additionally, identical NOTICE file should be added to /src/main/resources/META-INF directory of every module using external classes, right? I will ask next questions on legal-disc...@apache.org. Thank you in advance. Regards. Grzegorz Slowikowski On 2016-06-30 12:24, Stian Soiland-Reyes wrote: > This would be more a question for legal-disc...@apache.org, but I'll > try to respond anyway :). Sorry for the long answer.. Please correct > me! > > On 29 June 2016 at 19:30, Grzegorz Słowikowski <gslowikow...@gmail.com> wrote: >> 1. Can I include slightly modified class from Maven code in one of my >> plugins? How should I note this fact? > > Of course - that's explicitly permitted as long as you follow the > Apache License clause 5 > > https://www.apache.org/licenses/LICENSE-2.0.html#redistribution > > > You should note it by keeping the license header in the files, and by > propagating the content of the NOTICE from the Maven code, e.g. from > > https://github.com/apache/maven/blob/master/NOTICE > > if the code you are modifying is from the main Maven code. (Note that > most plugins have their own repositories with slightly different > NOTICE files) > > Remember: > >> You must cause any modified files to carry prominent notices stating that >> You changed the files; and > > So if you modify a file, then append to the existing license header > what you have changed. > > > > You will probably want to add your own (c) as well to the new NOTICE. > > Note that Apache trademarks mean you can't call your derived product > for "Apache Maven", however you may want to say "partially based on > Apache Maven" if that is true. > > > > You should still reconsider if you really NEED to do your own > modifications - perhaps the modifications can be provided to us > upstream instead in order for you to do subclassing or use the Maven > classes as they are? This would remove your need in the future to > "keep track" with Apache Maven development. > > >> 2. Can I include classes from other project with ASLv2 license (Play! >> Framework)? > > You can mix and match source code from any compatible license, as long > as you keep their license headers and NOTICE content, and provide the > Apache license with your work. > > You are not required to license your own derived work under the Apache > license (e.g. you could license it as GPL 3.0 or a commercial license > instead), but in most cases keeping it as Apache License 2.0 makes > things easier :) > > Note that while software from ASF always ensures that there is a > NOTICE file and /** Apache **/ license header, not all open source > software under the Apache License do this (it's not a requirement). > You should still append a license header saying which files you have > modified, if you need to. > > You may want to keep note in your new NOTICE what files came from where. > >> JNotify uses different licenses: GNU LGPL 2.1 + EPL >> Can, from legal PoV, JNotify implementation be used automatically >> (without user configuration) in any case (OSX here)? > > Yes, there is no legal reason why you can't use Apache licensed > software with LGPL or EPL. You will have to respect LGPL or EPL > separately for those parts - you can't distribute those as if they are > Apache License. This is normally easily achieved by your software > downloading their JARs separately using normal Maven >
Maven plugin - some licensing questions
Hi guys. Answer my questions or tell me the right list to ask them, please. I'm developing some Maven plugins. All have ASLv2 licenses. My questions are: 1. Can I include slightly modified class from Maven code in one of my plugins? How should I note this fact? 2. Can I include classes from other project with ASLv2 license (Play! Framework)? 3. Slightly more complicated case. I'm porting source files watching mechanism from Play! Framework SBT plugin to my Maven plugin. I have an API module and some implementations: JDK6, JNotify, polling. Implementation can be selected or chosen automatically based on Java version and OS (Maven artifact resolved dynamically). In Play! Framework, if Java is 1.7+, default implementation is - JNotify for OSX - JDK7 for other systems JNotify uses different licenses: GNU LGPL 2.1 + EPL Can, from legal PoV, JNotify implementation be used automatically (without user configuration) in any case (OSX here)? Can it be used, if it requires user configuration (in pom.xml or command line parameter)? Regards Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Plexus repos moved
Hi I see some strange differences in related repos, for example: https://github.com/sonatype/plexus-archiver - 45 releases https://github.com/codehaus-plexus/plexus-archiver - 0 releases https://github.com/sonatype/plexus-io - 36 releases https://github.com/codehaus-plexus/plexus-io - 0 releases https://github.com/sonatype/plexus-interpolation - 25 releases, 165 commits https://github.com/krosenvold/plexus-interpolation - 2 releases, 168 commits https://github.com/codehaus-plexus/plexus-interpolation - 2 releases, 166 commits Regards Grzegorz Slowikowski On 2015-02-09 18:13, Kristian Rosenvold wrote: They are now all at https://github.com/codehaus-plexus The issue tracking should be closed on the sonatype clones, it does not seem like it's possible to disable pull requests. Any maven devs or existing committers needing permissions should just ping. We'll hopefully get maven central access for publishing for everyone in the github org. In the meantime, the usual suspects can publish to central. Kristian - 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: Integrate Maven Site reporting with maven plugin that externally create report html page.
Hi Lukasz I didn't check, but your plugin must be very similar to one I wrote recently for SCoverage (Scala coverage) https://github.com/scoverage/scoverage-maven-plugin Look at this class: https://github.com/scoverage/scoverage-maven-plugin/blob/master/src/main/java/org/scoverage/plugin/SCoverageReportMojo.java Regards Grzegorz Slowikowski On 2014-11-26 22:42, animator wrote: I'm developing maven plugin (https://github.com/lgadawski/cloverage-maven-plugin). This plugin produces code coverage report for clojure sources from project. This report (html page) is generated by cloverage (clojure library as dependency in my maven plugin). The problem is that I would like to link this generated html file to maven site reporting section. Is that possible to achieve this automagically? Any suggestions? My Mojo extends AbstractMavenReport and after calling 'mvn site' I get link in Project Reports section. How to link there generated earlier html page? Thanks for any ansewrs! -- View this message in context: http://maven.40175.n5.nabble.com/Integrate-Maven-Site-reporting-with-maven-plugin-that-externally-create-report-html-page-tp5817068.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 . - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Bug in forked lifecycle?
Hi I think I found a bug in Maven when working in forked lifecycle, like cobertura lifecycle. Look at these two example projects: http://sbt-compiler-maven-plugin.googlecode.com/svn/tmp/bug-in-forked-lifecycle/ There are logs from mvn test -X, mvn cobertura:cobertura -X and mvn site -X executions commited. The problem is the plugin configuration parameter values are initialized to values set for parameters with the same name in previous plugin. In java example maven-surefire-plugin is replaced by scalatest-maven-plugin as testing plugin so there is skipTests=true added to Surefire configuration. When executing test Surefire skips test execution and ScalaTest executes, as expected. When executing cobertura:cobertura or site Surefire skips test execution and ScalaTest skips as well because it's skipTests prameter value is now true. Why? In scala example things are even more weird. There is the same logic as in java example (ScalaTest replaces Surefire) and additionally sbt-compiler-maven-plugin replaces maven-compiler-plugin. In standard compiler plugin skipMain=true to skip source files compilation and skip=true to skip test source files compilation. Situation here is similar to Surefire-ScalaTest conflict, both plugins have the same skipMain option (SBTCompiler has skipTest parameter for skipping test sources compilaiton and Compiler has skip parameter so no conflict here). When executing compile standard Compiler skips compilation and SBTCompiler compiles sources. I was expectiong problems in cobertura lifecycle (when executing site or cobertura:cobertura), but compilation works here! Test execution does not work, like in previous example. Why such difference? I don't know. There is cobertura:instrument execution In cobertura lifecycle in process-classes phase, so after compilation, but before testing. Maybe this execution is the source of the problem. Tested with different versions of Maven, from 2.2.1 to latest 3.2.3. Always the same behaviour. I made one more test, renamed skipTest parameter in SBTCompiler to test (in my local svn copy) to have parameter conflict with standard Compiler in testCompile mojo (executed after cobertura:instrument). Surprisingly, there is no conflict, so maybe this has nothing to do with cobertura:instrument mojo execution. Summary: In forked cobertura lifecycle (in mvn site or mvn cobertura:cobertura executions): - skipTests configuration parameter value of ScalaTest plugin gets overwritten by value of skipTests parameter defined for Surefire plugin, - skipMain and skip configuration parameter values of SBTCompiler don't get overwritten by values of skipMain and skip parameters defined for standard Compiler plugin. Worse, I didn't a workaround. Could someone help me solve this problem? Regards Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to read plexus/components.xml configuration from dynamically resolved artifact?
Hi Jason Thanks for your response. I will try to describe, what I need. I'm developing sbt-compiler-maven-plugin [1]. This plugin is similar to maven-compiler-plugin. It compiles Java and Scala sources using SBT (Scala Build Tool) delegates. There are different delegates for different, not compatible, SBT versions. This is similar to Plexus compilers idea. There is one important difference though. In maven-compiler-plugin there is default compiler, Javac, added as plugin's dependency. If you want another compiler, you add it as plugin dependency and set compilerId parameter. Javac compiler has no dependencies, so it will never cause dependency conflict with other compilers. In my case different delegates/compilers depend on different versions of the same artifacts, so there never can be more than one compiler in plugin's classpath. The consequence is, user has always! add the compiler he needs to plugin's dependencies. To avoid this, I implemented compiler autoselection mechanism. If there is no compiler added to plugin's dependencies, plugin automatically detects and resolves one based on sbtVersion parameter. This is very similar to Surefire providers detection mechanism [2]. Surefire has delegates called providers, for example for different JUnit versions. The user doesn't need to configure a provider, Surefire does it automatically based on test framework dependecy in a project and some plugin's parameters. Because different junit providers depend on different versions of junit artifact, only one provider at a time can be used (just like in my plugin). Surefire uses standard Java services mechanism to resolves a provider class, for example [3]. It does not use Plexus DI. I want to use Plexus in my plugin, but I don't know how to find provider class inside an artifact jar. I want to replace this [4] ugly code. [1] https://sbt-compiler-maven-plugin.googlecode.com/svn/mavensite/1.0.0-beta3/index.html [2] http://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html [3] https://github.com/apache/maven-surefire/blob/c8858944ca1409ae368f217cc2f7ca039651bd98/surefire-providers/surefire-junit3/src/main/resources/META-INF/services/org.apache.maven.surefire.providerapi.SurefireProvider [4] https://sbt-compiler-maven-plugin.googlecode.com/svn/mavensite/1.0.0-beta3/sbt-compiler-maven-plugin/xref/com/google/code/sbt/compiler/plugin/AbstractSBTCompileMojo.html#L694 Regards Grzegorz On 2014-05-01 16:51, Jason van Zyl wrote: What are you trying to do from a high level. Much of what Maven does to resolve, load and configure plugins dynamically can likely be reused, but if you tell me what you want I can point you at code you can lift. At a high level Maven: 1. Looks at some configuration and determines what the plugin is 2. Downloads the plugin into the local repository 3. Creates a class loader with the plugin artifact and its dependencies 4. Scans the class loader for component implementations (the mojos, and any ancillary components) 5. Instantiates the plugin 6. Applies configuration to the plugin 7. Executes the plugin On May 1, 2014, at 5:07 AM, Grzegorz Słowikowski gslowikow...@gmail.com wrote: Hi I need to read implementation value of a component with specified role and role-hint from META-INF/plexus/components.xml resource of dynamically resolved artifact. In other words I want to do the same thing Maven does configuring mojo attributes with @Component( role = AnInterface.class hint = foo) annotation. Maven finds implementation in the classpath, initializes implementation object and assigns to mojo attribute. In my case I find and resolve an artifact containing the class implementing AnInterface.class role with foo hint (a have a well known pool of artifacts with different implementations). Now I need to get this implementation class name. How can I do this? Regards Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to read plexus/components.xml configuration from dynamically resolved artifact?
Hi Igor On 2014-05-04 14:08, Igor Fedorenko wrote: If all compiler delegates have the same groupId/artifactId but different versions, then you can use standard maven plugin dependency resolution to achieve something very similar. Specify the default delegate groupId/artifactId/version as direct plugin dependency, but the user will still be able to specify different version with plugin/dependency in their pom.xml files. Maybe not as convenient as sbtVersion parameter, but way simpler to implement. This is a little different. The compiler delegates have different artifactIds. Their dependencies have the same groupId+artifactId pairs (com.typesafe.zinc:zinc). For example: plugin groupIdcom.google.code.sbt-compiler-maven-plugin/groupId artifactIdsbt-compiler-maven-plugin/artifactId version1.0.0-beta3/version dependencies dependency !-- depends on com.typesafe.zinc:zinc:0.2.5 -- groupIdcom.google.code.sbt-compiler-maven-plugin/groupId artifactIdsbt-compiler-sbt012/artifactId version1.0.0-beta3/version /dependency dependency !-- depends on com.typesafe.zinc:zinc:0.3.0 -- groupIdcom.google.code.sbt-compiler-maven-plugin/groupId artifactIdsbt-compiler-sbt013/artifactId version1.0.0-beta3/version /dependency /dependencies /plugin Dependency conflict is with com.typesafe.zinc:zinc (and its dependencies). If you really want to have sbtVersion, I don't believe you'll be able to use dependency injection or at least this will be super messy. Plugin class realm is fully setup before plugin code runs (obviously), so you won't be able to use standard maven plugin component discovery for sure. What may work is this : resolve compiler delegate dependencies, filter anything that must be provided by maven core and your plugin, create new child classrealm with the filtered depenedncies as classpath , then discover components in the new realm with DefaultPlexusContainer#discoverComponents, then set thread context classloader to the new realm and hopefully be able to do PlexusContainer#lookup. You will almost certainly want to cache the new realm so your plugin performs reasonably well during multimodule build and will need to discard the realm at the end of the build. I didn't try to understand class realms. I found no documentation and this is too complicated for me. I'm creating URLClassloaders, and this solution works. I'm cache'ing these classloaders to improve performace (I asked about releasing them some time ago, and you answered). I want to improve [4]. Look at this line. This works, but I don't like the way I implemented it. I would prefer to use Plexus to discover component implementation in the artifact. Regards Grzegorz -- Regards, Igor On 2014-05-04, 5:36, Grzegorz Słowikowski wrote: Hi Jason Thanks for your response. I will try to describe, what I need. I'm developing sbt-compiler-maven-plugin [1]. This plugin is similar to maven-compiler-plugin. It compiles Java and Scala sources using SBT (Scala Build Tool) delegates. There are different delegates for different, not compatible, SBT versions. This is similar to Plexus compilers idea. There is one important difference though. In maven-compiler-plugin there is default compiler, Javac, added as plugin's dependency. If you want another compiler, you add it as plugin dependency and set compilerId parameter. Javac compiler has no dependencies, so it will never cause dependency conflict with other compilers. In my case different delegates/compilers depend on different versions of the same artifacts, so there never can be more than one compiler in plugin's classpath. The consequence is, user has always! add the compiler he needs to plugin's dependencies. To avoid this, I implemented compiler autoselection mechanism. If there is no compiler added to plugin's dependencies, plugin automatically detects and resolves one based on sbtVersion parameter. This is very similar to Surefire providers detection mechanism [2]. Surefire has delegates called providers, for example for different JUnit versions. The user doesn't need to configure a provider, Surefire does it automatically based on test framework dependecy in a project and some plugin's parameters. Because different junit providers depend on different versions of junit artifact, only one provider at a time can be used (just like in my plugin). Surefire uses standard Java services mechanism to resolves a provider class, for example [3]. It does not use Plexus DI. I want to use Plexus in my plugin, but I don't know how to find provider class inside an artifact jar. I want to replace this [4] ugly code. [1] https://sbt
How to read plexus/components.xml configuration from dynamically resolved artifact?
Hi I need to read implementation value of a component with specified role and role-hint from META-INF/plexus/components.xml resource of dynamically resolved artifact. In other words I want to do the same thing Maven does configuring mojo attributes with @Component( role = AnInterface.class hint = foo) annotation. Maven finds implementation in the classpath, initializes implementation object and assigns to mojo attribute. In my case I find and resolve an artifact containing the class implementing AnInterface.class role with foo hint (a have a well known pool of artifacts with different implementations). Now I need to get this implementation class name. How can I do this? Regards Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Classloader cache in Maven plugin - how to avoid classloader leaks?
Hi Devs Actual question is at the end. Some introduction first. I'm developing two Maven plugins, where actual functionality is not implemented in the plugin, but delegated to providers. This idea is taken from maven-compiler-plugin, where the plugin delegates compilation to plexus compilers. I've improved this in my plugins by adding provider auto-discovery mechanism based on some project properties, etc. In maven-compiler-plugin default javac compiler is added as a dependency by default. You can add other compilers as dependencies and set desired compilerId. This implementation works because plexus-javac-compiler has no dependencies, so adding other compilers will not cause any dependency conflict. In both my plugins I have (for now) two providers, with conflicting transitive dependencies (different version of the same dependency), so I cannot add one of them by default, because when I would want to use the other one I couldn't remove the first, default one from dependencies, and the resulting classpath after dependency resolution would be unpredictable. The solution is the ability to find and resolve the right provider without the need to add it do plugin's dependencies. This is similar to Surefire internal (so called well known) providers (junit3, junit4, testng). They are never declared as Surefire dependencies, but Surefire can resolve then in runtime. To improve provider auto-discovery performance Surefire caches already resolved provider dependencies. See: https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/ClasspathCache.java I went one step further and I cache ClassLoaders because repetitive class loading process is very timeconsuming even when cache'ing classpaths. My question is, when can I dispose my cached classloaders? Is there any project build event I can add listener to? I would like to dispose the classloaders at the end of reactor build, not at the end of each reactor module build. Thanks in advance. Regards Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven development tools for m2e
Hi I'm new to Maven plugin M2Eclipse integration. I've imported my plugin (with custom packaging) I want to integrate with M2Eclipse and some test projects using this packaging. When playing with lifecycle-mapping-metedata.xml (changing actions for different mojos) I found that I have to delete all projects and reimport them. Without this projects don't see these changes. I don't know if this would be hard to improve it? Regards Grzegorz Slowikowski On 2013-11-27 13:49, Igor Fedorenko wrote: On 11/27/2013, 3:04, Hervé BOUTEMY wrote: I'm interested in such tools: this can help a lot. adding a link in http://maven.apache.org/developers/index.html will be useful to let Maven developers know that such tooling exists for Eclipse I am mostly seeking feedback about this feature at this point, and I will really appreciate if you could try it and see if it works for your plugins and development workflow. I do plan to publish this feature to eclipse marketplace and mention in on maven developers page, but I would like to see the following happen first * somebody else tried the feature and confirmed and both useful and works as advertised. * m2e 1.5 m4 is released (which will happen in few weeks) * verifier 1.5 is released and core ITs are updated to use it I read Known problems and limitations Maven Plugin metadata, i.e., META-INF/maven/plugin.xml, is disappears in some cases. A partial fix is planned in maven-plugin-plugin 3.3 But I didn't see any Jira issue that seems to handle such an issue What's the problem? Can I help find a solution? The problem is poor interaction between maven-plugin-plugin and eclipse workspace java builder. Java builder deletes META-INF/maven/plugin.xml file for some plugins but not for others. The solution is to use plexus BuildContext to write files to disk, like we did in resources-plugin. I don't have jira for this yet. -- Regards, Igor Regards, Hervé Le lundi 25 novembre 2013 08:03:17 Igor Fedorenko a écrit : Hello, I have a couple of m2e extensions that I use to work on maven and maven plugins. In short, they allow running/debugging maven core and maven plugin directly from m2e workspace, without the need to install anything to the local repo after each code change. There is slightly more detailed description and installation instructions at github [1] and I plan to publish this to eclipse marketplace for easier user installation. Let me know what you think. [1] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev/blob/master/README .md -- Regards, Igor - 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: maven development tools for m2e
Hi I'm Maven plugins developer. For me it works great on first sight. I've has small problem when installing (reported to Igor), but worked it around. Greetings Grzegorz Slowikowski On 2013-11-25 14:03, Igor Fedorenko wrote: Hello, I have a couple of m2e extensions that I use to work on maven and maven plugins. In short, they allow running/debugging maven core and maven plugin directly from m2e workspace, without the need to install anything to the local repo after each code change. There is slightly more detailed description and installation instructions at github [1] and I plan to publish this to eclipse marketplace for easier user installation. Let me know what you think. [1] https://github.com/ifedorenko/com.ifedorenko.m2e.mavendev/blob/master/README.md -- Regards, Igor - 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: Reactor dependencies with custom packaging not being resolved - bug in Maven or on my side?
Hi
Did you find anything, any progress?
I would like to know if I can workaround this problem on my side.
Thanks
Grzegorz
On 2013-11-04 16:55, Jason van Zyl wrote:
Danke.
On Nov 4, 2013, at 10:51 AM, Grzegorz Słowikowski
gslowikow...@gmail.com mailto:gslowikow...@gmail.com wrote:
Simplified version commited here:
http://maven-play-plugin.googlecode.com/svn/tmp/test-projects/reactor-problem/
Grzegorz
On 4 listopad 2013 15:12:45, Jason van Zyl wrote:
If I checkout your test project it doesn't build. If you make a self
contained example that builds I'll take a look. It is most
definitely a problem with the WorkspaceReader which should be
relatively easy to fix.
On Nov 4, 2013, at 3:08 AM, Grzegorz Słowikowski
gslowikow...@gmail.com wrote:
Hi
Maybe I'm doing something wrong and maybe it's Maven bug.
Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x
I have multi-module test project for my plugin:
https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
There are two submodules: app1 and app2, both with custom play
packaging. app2 depends on app1.
play packaging lifecycle is producing zip file (you can see zip in
the logs).
Everything starts working after installing app1 in local repo, but
this shouldn't be required.
play packaging is defined here, for reference:
http://maven-play-plugin.googlecode.com/svn/tags/plugin-1.0.0-beta6/play-maven-plugin/src/main/resources/META-INF/plexus/components.xml
Calling mvn initialize:
with Maven 2.2.1:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App1
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App2
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App1
[INFO]task-segment: [initialize]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [play:initialize {execution: default-initialize}]
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App2
[INFO]task-segment: [initialize]
[INFO]
Downloading:
http://repo1.maven.org/maven2/com/google/code/maven-play-plugin/test-projects/packagings/default/inter-app-dependency/app1/1.0.0-beta6/app1-1.0.0-beta6.zip
[INFO] Unable to find resource
'com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6'
in repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
2)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
--
1 required artifact is missing.
for artifact:
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Nov 04 08:52:36 CET 2013
[INFO] Final Memory: 22M/54M
[INFO
Reactor dependencies with custom packaging not being resolved - bug in Maven or on my side?
Hi
Maybe I'm doing something wrong and maybe it's Maven bug.
Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x
I have multi-module test project for my plugin:
https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
There are two submodules: app1 and app2, both with custom play
packaging. app2 depends on app1.
play packaging lifecycle is producing zip file (you can see zip in
the logs).
Everything starts working after installing app1 in local repo, but
this shouldn't be required.
play packaging is defined here, for reference:
http://maven-play-plugin.googlecode.com/svn/tags/plugin-1.0.0-beta6/play-maven-plugin/src/main/resources/META-INF/plexus/components.xml
Calling mvn initialize:
with Maven 2.2.1:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App1
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App2
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App1
[INFO]task-segment: [initialize]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [play:initialize {execution: default-initialize}]
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App2
[INFO]task-segment: [initialize]
[INFO]
Downloading:
http://repo1.maven.org/maven2/com/google/code/maven-play-plugin/test-projects/packagings/default/inter-app-dependency/app1/1.0.0-beta6/app1-1.0.0-beta6.zip
[INFO] Unable to find resource
'com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6'
in repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
2)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
--
1 required artifact is missing.
for artifact:
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Nov 04 08:52:36 CET 2013
[INFO] Final Memory: 22M/54M
[INFO]
==
with Maven 3.0.5 and 3.1.1:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
[WARNING] 'parent.relativePath' points at
com.google.code.maven-play-plugin.test-projects.packagings.default:inter-app-dependency
instead of com.google.code.maven-play-plugin:play-app-default-parent,
please verify your project structure @ line 21, column 13
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no
Re: Reactor dependencies with custom packaging not being resolved - bug in Maven or on my side?
On 2013-11-04 10:03, Mikolaj Izdebski wrote: On 11/04/2013 09:08 AM, Grzegorz Słowikowski wrote: Maybe I'm doing something wrong and maybe it's Maven bug. Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x I have multi-module test project for my plugin: https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency There are two submodules: app1 and app2, both with custom play packaging. app2 depends on app1. play packaging lifecycle is producing zip file (you can see zip in the logs). Everything starts working after installing app1 in local repo, but this shouldn't be required. This looks like MNG-5503 [1,2], which was fixed in Maven 3.1.1. [1] http://jira.codehaus.org/browse/MNG-5503 [2] http://bugzilla.redhat.com/991454 1. In my case this does not work with Maven 3.1.1, even if I run mvn package first for app1 module (produce zip file) 2. I have a mojo doing something if it finds reactor intermodule dependencies (lets say I want to log these dependencies only). I don't need zip files for this mojo at all. Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Reactor dependencies with custom packaging not being resolved - bug in Maven or on my side?
Simplified version commited here:
http://maven-play-plugin.googlecode.com/svn/tmp/test-projects/reactor-problem/
Grzegorz
On 4 listopad 2013 15:12:45, Jason van Zyl wrote:
If I checkout your test project it doesn't build. If you make a self
contained example that builds I'll take a look. It is most definitely a
problem with the WorkspaceReader which should be relatively easy to fix.
On Nov 4, 2013, at 3:08 AM, Grzegorz Słowikowski gslowikow...@gmail.com
wrote:
Hi
Maybe I'm doing something wrong and maybe it's Maven bug.
Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x
I have multi-module test project for my plugin:
https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
There are two submodules: app1 and app2, both with custom play
packaging. app2 depends on app1.
play packaging lifecycle is producing zip file (you can see zip in
the logs).
Everything starts working after installing app1 in local repo, but
this shouldn't be required.
play packaging is defined here, for reference:
http://maven-play-plugin.googlecode.com/svn/tags/plugin-1.0.0-beta6/play-maven-plugin/src/main/resources/META-INF/plexus/components.xml
Calling mvn initialize:
with Maven 2.2.1:
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App1
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency : App2
[INFO] Play! Framework Maven Test Projects : Packagings : Default :
Inter-App Dependency
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App1
[INFO]task-segment: [initialize]
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [play:initialize {execution: default-initialize}]
[INFO]
[INFO] Building Play! Framework Maven Test Projects : Packagings :
Default : Inter-App Dependency : App2
[INFO]task-segment: [initialize]
[INFO]
Downloading:
http://repo1.maven.org/maven2/com/google/code/maven-play-plugin/test-projects/packagings/default/inter-app-dependency/app1/1.0.0-beta6/app1-1.0.0-beta6.zip
[INFO] Unable to find resource
'com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6'
in repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file
-DgroupId=com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency
-DartifactId=app1 -Dversion=1.0.0-beta6 -Dpackaging=play
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
2)
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app1:play:1.0.0-beta6
--
1 required artifact is missing.
for artifact:
com.google.code.maven-play-plugin.test-projects.packagings.default.inter-app-dependency:app2:play:1.0.0-beta6
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Mon Nov 04 08:52:36 CET 2013
[INFO] Final Memory: 22M/54M
[INFO]
==
with Maven 3.0.5 and 3.1.1:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
Re: [VOTE] Apache Maven Shared Incremental 1.1 and Apache Maven Compiler Plugin 3.1 (take 2)
Hi So, why the plugin version is 3.2 instead of 3.1? I see two release (3.1 and 3.2) in repository generated recently. Are they identical? It looks so. The 3.2 release should be removed and the voting should be for 3.1 release IMO. Grzegorz Slowikowski On 2 kwiecień 2013 23:57:46, Olivier Lamy wrote: I know. I did as usual but no idea what happened on the mrm 2013/4/3 Mirko Friedenhagen mfriedenha...@gmail.com: Hello Olivier, maven-compiler-plugin-3.2 uses the new maven-shared-incremental-1.1 and these are in two staging repositories, both have to be included as repositories, Regards Mirko Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Tue, Apr 2, 2013 at 2:50 PM, Olivier Lamy ol...@apache.org wrote: Hi, Apache Maven Shared Incremental 1.1 We fixed 1 issue: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=19002styleName=TextprojectId=11761Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-049/ Staging site: http://maven.apache.org/shared-archives/maven-shared-incremental-1.1/ Apache Maven Compiler Plugin 3.1 We fixed 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11130version=18973 Staging repository: https://repository.apache.org/content/repositories/maven-050 Staging site: http://maven.apache.org/plugins-archives/maven-compiler-plugin-3.1/ Vote open for 72H [+1] [0] [-1] Thanks! -- Olivier Lamy Ecetera: http://ecetera.com.au 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
Re: [VOTE] Apache Maven Wagon 2.2
Hi I tried to upgrade my org.apache.maven.wagon:wagon-webdav:1.0-beta-2 extension to org.apache.maven.wagon:wagon-webdav-jackrabbit:2.2 but without luck. It does not work with Maven 2.2.1 at all (versions 2.0 and 2.1 don't work too). Log: ... SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder. SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. ... Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder With Maven 3.0.3 it works, but with a warning in the log: SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. My questions are: 1. What is the minimum Maven version working with Maven Release Plugin 2.x? Can I use it somehow with Maven 2.2.1? 2. How can I add (if I can at all) missing SLF4J implementation dependency to extension defined: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav-jackrabbit/artifactId version2.2/version /extension /extensions /build Grzegorz Slowikowski On 2011-12-15 16:07, Olivier Lamy wrote: Hello, I'd like to release Apache Maven Wagon 2.2 We fixed 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335version=18090 The staged repo is available here: https://repository.apache.org/content/repositories/maven-344/ Staged site: http://maven.apache.org/wagon-2.2/ Vote open for 72H [+1] [0] [-1] Here my +1 Thanks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[Surefire] submodules common-junit3 and common-junit4 not deployed (deployment skipped in the poms) - problem
Hi These modules are not deployed. Their content is only shaded into providers. I want to write my own, specialized junit4 provider and I cannot use these modules (I want to use them) because they are not present in main repository. I know, I can install them locally, but this is not the proper way. For example, I couldn't deploy my provider to central repo because it needs artifacts not present there. Can you remove skip flag in the deploy plugin configuration and deploy them like every other module? If you agree, I can create Jira issue. Greetings Grzegorz Slowikowski - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 2.1.1
This version does not fix http://jira.codehaus.org/browse/MSITE-456 for me. Grzegorz Slowikowski On 2010-05-31 23:33, Dennis Lundberg wrote: Hi, We solved 7-8 issues (I'm not sure if MSITE-440 is resolved or not): http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146version=15923 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repo: https://repository.apache.org/content/repositories/maven-025/ Staging site: http://maven.apache.org/plugins/maven-site-plugin-2.1.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Assembly Plugin 2.2-beta-5
See my comment http://jira.codehaus.org/browse/MASSEMBLY-416?focusedCommentId=201500page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_201500 Greetings Grzegorz Slowikowski Benjamin Bentmann wrote: Hi, We solved 7 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126version=15324 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11126status=1 Staging repo: https://repository.apache.org/content/repositories/maven-041/ Staging site (sync pending): http://maven.apache.org/plugins/maven-assembly-plugin-2.2-beta-5/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 +1 from me 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: [VOTE 4] maven-assembly-plugin 2.2-beta-4
Still not perfect, see my comment: http://jira.codehaus.org/browse/MASSEMBLY-416?focusedCommentId=179238page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_179238 Grzegorz Slowikowski John Casey wrote: Resending this with the proper subject...*SIGH* Hi again, I've corrected the missing NOTICE and LICENSE files, and [hopefully] the POM signature issue (by using Maven 2.0.10 for the release...2.2.0 isn't released yet, so I don't want to inject further risk of bugs). Please let me know if I've missed anything else. URLs below have been updated where appropriate. --- As I'm sure you've noticed, we've had a large thread on this list regarding how to put together a proper ASF release using Maven. In order to enable the Assembly plugin to take on the burden of producing ASF source-release assemblies, we had to fix a few bugs. Along with this, I've also tackled the tar/zip file modes problem. The staged repository for this release can be found at: https://repository.apache.org/content/repositories/maven-staging-004 The JIRA notes for the release can be found at the following URL, or at appended to the end of this message: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=15298 The website is staged at: http://maven.apache.org/plugins/maven-assembly-plugin-2.2-beta-4 NOTE: I staged one version of this website and it contained bad links. I've just pushed another version up, and it should sync over soonish, so keep an eye out. Please vote! [ ] +1 Pull the trigger! [ ] +0 ...like I care [ ] -1 Stop right there and back away from the plugin slowly! Here's my +1. Thanks! -john === Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 ** Bug * [MASSEMBLY-238] - Assembly plugin removes file permissions * [MASSEMBLY-379] - Follow-up: file permissions are removed when creating tar.gz assembly * [MASSEMBLY-413] - Assembly plugin uses absolute paths from project instance after interpolation * [MASSEMBLY-414] - Allow regular expressions in include/exclude patterns for filesets --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - 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: [VOTE] maven-assembly-plugin 2.2-beta-4
Hi With this configuration: pluginRepositories pluginRepository idmaven-staging-031/id namemaven-staging-031/name urlhttps://repository.apache.org/content/repositories/maven-staging-031/url /pluginRepository /pluginRepositories build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4/version configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs /configuration executions execution idmake-assembly/id phasepackage/phase goals goalsingle/goal /goals /execution /executions /plugin /plugins /build I have target folder/package inside jar-with-dependencies archive which contains copies of my project classes (they are in the normal package structure within this archive too). Greetings Grzegorz Slowikowski John Casey wrote: Hi, As I'm sure you've noticed, we've had a large thread on this list regarding how to put together a proper ASF release using Maven. In order to enable the Assembly plugin to take on the burden of producing ASF source-release assemblies, we had to fix a few bugs. Along with this, I've also tackled the tar/zip file modes problem. The staged repository for this release can be found at: https://repository.apache.org/content/repositories/maven-staging-031 The JIRA notes for the release can be found at the following URL, or at appended to the end of this message: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11126styleName=Htmlversion=15298 Please vote! [ ] +1 Pull the trigger! [ ] +0 ...like I care [ ] -1 Stop right there and back away from the plugin slowly! Here's my +1. Thanks! -john === Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-4 ** Bug * [MASSEMBLY-238] - Assembly plugin removes file permissions * [MASSEMBLY-379] - Follow-up: file permissions are removed when creating tar.gz assembly * [MASSEMBLY-413] - Assembly plugin uses absolute paths from project instance after interpolation * [MASSEMBLY-414] - Allow regular expressions in include/exclude patterns for filesets --- John Casey Developer and PMC Member, Apache Maven (http://maven.apache.org) Member, Apache Software Foundation What we have to learn to do, we learn by doing. -Aristotle - 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: Bad dependency
Hi There are two artifacts, both with classifiers. Your declaration should look like: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version5.1/version classifierjdk14/classifier scopetest/scope /dependency or dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version5.1/version classifierjdk15/classifier scopetest/scope /dependency Greetings Grzegorz Slowikowski José Pacheco pisze: Hello all, I’m using testng version 5.1 in one project, but maven says that can not find the dependency, and I now the dependency is available in mvn repository. How can I solve the problem? The declaration is as follows: dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version5.1/version scopetest/scope /dependency Regards, José Pacheco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dep to same artifact in different versions
Hi Look at hibernate2 and hibernate3 artifacts. They have hibernate and org.hibernate groupIds respectively, so they can be used together (java package names are different too). This is IMO the proper way to do this. While writing this mail I found: http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 which confirms what I have written above. Greetings Grzegorz Slowikowski Arik Kfir napisał(a): Doesn't the jmock2 contains the classes of jmock1 as well? On 4/25/07, Jörg Schaible [EMAIL PROTECTED] wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 3:26 PM: On 25 Apr 07, at 9:00 AM 25 Apr 07, Jörg Schaible wrote: Jason van Zyl wrote on Wednesday, April 25, 2007 2:41 PM: On 25 Apr 07, at 8:09 AM 25 Apr 07, Jörg Schaible wrote: Hi devs, how will Maven handle the problem of a dependency that should be used in two different versions? This applies to all project that release a new (normally major) version that can be used with the old version at the same time. This is currently possible at least with: jmock 1.x / jmock 2.x webworks 1.x / webworks 2.x Maven supprts currently only two versions of sa dep if groupId:artifactId is different between those two versions/ branches, but this might not be always the case. In Gentoo Linux such a situation is solved by introducing a slot indicating two different development trees that can be installed at the same time. For Maven this would mean that the separation between (main) artifacts should switch to groupId:artifactId:slot, where slot is 0 by default Is there already a proposal or doc for such kind of functionality in a future release that I might have been missed? Sorry, I'm not sure I fully understand what you're talking about. If you want a specific version of something why would we use a slot, when you can specify the version? If you want to use Webwork 1.x then you specify the version. Many versions sit happily together in the repository. Or are you talking about behavior that should be constricted to a certain version range? For example, in selecting the latest version of the 1.x family? I'm honestly not sure what you're talking about. Maybe a problem trying to translate Gentoo speak to Maven? Maven speek: dependencies dependency groupIdjmock/groupId artifactIdjmock/artifactId version1.2.0/version /dependency dependency groupIdjmock/groupId artifactIdjmock/artifactId version2.0.0/version /dependency /dependencies jMock 2.x is designed to be used at the same time as jMock 1.x. My code uses both. So how can I define the deps? First I'll ask why you are using both versions in one project and then I'll answer your question. Becasue I have 1000 of old unit tests with jMock 1.x, I am switching my project to JDK 5 and write my new unit tests with improved DSL and annotation support of jMock 2.x. No need at all to to convert the 1000 old tests (some might be converted over time). This is exaclty why jMock 1.xand jMock 2.x is designed to be used at the same time. - Jörg BTW: The same problem appears if your deps depend transitively on two development branches of the same artifact, that are classloader compatible (different class names) and might be used at the same time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Controlling plugin versions using dependency management
Hi developers I want to control plugin versions used in a multimodule build with dependencyManagement. I thing, Maven behaves weird. Here is a test project, where I try to control maven-jar-plugin version. parent pom: project modelVersion4.0.0/modelVersion groupIdmycompany/groupId artifactIdparent/artifactId packagingpom/packaging version1.0.0-SNAPSHOT/version modules modulechild/module /modules dependencyManagement dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.0/version /dependency /dependencies /dependencyManagement /project child pom (in child subdirectory): project modelVersion4.0.0/modelVersion parent groupIdmycompany/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version /parent artifactIdchild/artifactId version1.0.0-SNAPSHOT/version !-- dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId /dependency /dependencies -- /project When building child, maven-jar-plugin 2.1 (latest) is selected. If I uncomment dependencies section, maven-jar-plugin 2.0 (specified in dependencyManagement section) is selected. Why I have to specify dependency to make dependencyManagement work for a plugin? Is this an error or am I doing something wrong? Greetings Grzegorz Slowikowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Controlling plugin versions using dependency management
Thank you. I thought, pluginManagement is for plugin configurations and all other stuff but versions, and dependencyManagement for artifact/plugin versions managing. I was wrong. Grzegorz Slowikowski LAMY Olivier napisał(a): Hi, In your root pom, use build/pluginManagement/plugins with this : plugin artifactIdmaven-jar-plugin/artifactId version2.0/version /plugin And maybe use user ML for this question. -- Olivier -Message d'origine- De : Grzegorz Słowikowski [mailto:[EMAIL PROTECTED] Envoyé : vendredi 20 avril 2007 10:34 À : dev@maven.apache.org Objet : Controlling plugin versions using dependency management Hi developers I want to control plugin versions used in a multimodule build with dependencyManagement. I thing, Maven behaves weird. Here is a test project, where I try to control maven-jar-plugin version. parent pom: project modelVersion4.0.0/modelVersion groupIdmycompany/groupId artifactIdparent/artifactId packagingpom/packaging version1.0.0-SNAPSHOT/version modules modulechild/module /modules dependencyManagement dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.0/version /dependency /dependencies /dependencyManagement /project child pom (in child subdirectory): project modelVersion4.0.0/modelVersion parent groupIdmycompany/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version /parent artifactIdchild/artifactId version1.0.0-SNAPSHOT/version !-- dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId /dependency /dependencies -- /project When building child, maven-jar-plugin 2.1 (latest) is selected. If I uncomment dependencies section, maven-jar-plugin 2.0 (specified in dependencyManagement section) is selected. Why I have to specify dependency to make dependencyManagement work for a plugin? Is this an error or am I doing something wrong? Greetings Grzegorz Slowikowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, any attachments and the information contained therein (this message) are confidential and intended solely for the use of the addressee(s). If you have received this message in error please send it back to the sender and delete it. Unauthorized publication, use, dissemination or disclosure of this message, either in whole or in part is strictly prohibited. -- Ce message électronique et tous les fichiers joints ainsi que les informations contenues dans ce message ( ci après le message ), sont confidentiels et destinés exclusivement à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le renvoyer à son émetteur et de le détruire. Toutes diffusion, publication, totale ou partielle ou divulgation sous quelque forme que se soit non expressément autorisées de ce message, sont interdites. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Controlling plugin versions using dependency management
Thank you Grzegorz Slowikowski Franz Allan Valencia See napisał(a): Good day, Use pluginMangement/ instead. Something like project ... build pluginManagement plugins plugin !-- if you don't specify a groupId, org.apache.maven.plugins is used. -- groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.0/version /plugin /plugins /pluginManagement /build /project See [1] for more info. Cheers, Franz [1] http://maven.apache.org/ref/current/maven-model/maven.html On 4/20/07, Grzegorz Słowikowski [EMAIL PROTECTED] wrote: Hi developers I want to control plugin versions used in a multimodule build with dependencyManagement. I thing, Maven behaves weird. Here is a test project, where I try to control maven-jar-plugin version. parent pom: project modelVersion4.0.0/modelVersion groupIdmycompany/groupId artifactIdparent/artifactId packagingpom/packaging version1.0.0-SNAPSHOT/version modules modulechild/module /modules dependencyManagement dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.0/version /dependency /dependencies /dependencyManagement /project child pom (in child subdirectory): project modelVersion4.0.0/modelVersion parent groupIdmycompany/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version /parent artifactIdchild/artifactId version1.0.0-SNAPSHOT/version !-- dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId /dependency /dependencies -- /project When building child, maven-jar-plugin 2.1 (latest) is selected. If I uncomment dependencies section, maven-jar-plugin 2.0 (specified in dependencyManagement section) is selected. Why I have to specify dependency to make dependencyManagement work for a plugin? Is this an error or am I doing something wrong? Greetings Grzegorz Slowikowski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invalid jetty version in maven-site-plugin 2.0-beta-5
Hello maven-site-plugin 2.0-beta-5 has dependency: dependency groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version6.0.0beta12/version /dependency This version is used in poms in maven/plugins/trunk and maven/plugins/tags/maven-site-plugin-2.0-beta-5. In the repository on ibiblio pom contains: dependency groupIdorg.mortbay.jetty/groupId artifactIdjetty/artifactId version6.0.0beta15/version /dependency This version is incompatible with beta12, so e.g. mvn site:run will fail. I don't know why, but someone changed jetty version number from 6.0.0beta12 to 6.0.0beta15. Stacktrace fragment from mvn site:run on a simple project: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run' in the plugin 'org.apache.maven.plugins:maven-site-plugin' org/mortbay/jetty/handler/NotFoundHandler [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run' in the plugin 'org.apache.maven.plugins:maven-site-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run' in the plugin 'org.apache.maven.plugins:maven-site-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-site-plugin:2.0-beta-5:run', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:524) ... 18 more Caused by: org.codehaus.plexus.component.factory.ComponentInstantiationException: Could not instanciate component: role: 'null', implementation: 'org.apache.maven.plugins.site.SiteRunMojo' at org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactory.java:77) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:62) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) ... 20 more Caused by: java.lang.NoClassDefFoundError: org/mortbay/jetty/handler/NotFoundHandler at
Cannon generate maven-checkstyle-plugin site
Hello
Checkstyle plugin site checkstyle mojo has no content:
http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html
I tried to generate it myself from sources.
It fails with an error during xml parsing for trunk and
tags/maven-checkstyle-plugin-2.1
Invalid xml fragment:
tr
td
codepackageNamesLocation/code i(Optional)/i/td
td
code title=java.lang.StringString/code
/td
td
code-/code
/td
td
code-/code
/td
tdp/ Specifies the location of the package names XML to be used
to configure the Checkstyle a
href=http://checkstyle.sourceforge.net/config.html#Packages;Packages/a.
/p p/ p/ This parameter is resolved as resource, URL, then file. If
resolved to a resource, or a URL, the contents of the package names XML is
copied into the
code${project.build.directory}/checkstyle-packagenames.xml/code file before
being passed to checkstyle for loading. /p/td
/tr
(look at p/, should be p)
I don't knot which component is responsible for this error, so I'm writing to
this list.
fragment from log shows that I use latest site plugin version:
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-5:site' --
Greg
Maven Embedder 2.0.3 functionality
Hello I've hoped that new version of Maven Embedder will have the functionality Jason was working on in maven-embedder-refactor branch. M2eclipse guys are waiting for it, and I wait for them to start using their product :-) Are there any plans to finish this work and maybe release another embedder before the next Maven version? Greg
Tomcat poms - maybe we could change proupId to org.apache.tomcat?
Hello While preparing POMs for Tomcat 5.5.15 Jacek Laskowski (Geronimo team) suggested that we can change groupId from tomcat to org.apache.tomcat. For backward compatibility we would add poms with relocations in tomcat directory. What do you think? I still have no answer, where shoul I upload my poms. Greg
Re: Tomcat POMs
Hi Comments below. - Original Message - From: Wayne Fay [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Thursday, March 16, 2006 5:21 PM Subject: Re: Tomcat POMs I'm not a Maven dev but felt like responding. ;-) For the MX4J issue... I would build two bundles... One with target JDK1.4, include the MX4J dependency, and use no classifier... The other with target JDK1.5 and the classifier jdk5. 1. MX4J has EXACTLY the same interface as Sun's JMX - JSR 3 (JMX) and JSR 160 (JMX Remote API). 2. I do not build Tomcat jars. They are built with Ant and distributed by Tomcat team. I'm only preparing poms for these jars. So there is only one copy of each library which will work perfectly with JMX anf MX4J. If you run Tomcat on JDK 1.5 you don't need MX4J because you have JMX in JDK's rt.jar. If you run Tomcat on JDK 1.4 you need JMX (jars can be downloaded from Sun) or MX4J. I think, that JDK 1.5 + MX4J would work too if someone would prefer MX4j even on JDK 1.5. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat poms - maybe we could change proupId to org.apache.tomcat?
Hello While preparing POMs for Tomcat 5.5.15 Jacek Laskowski (Geronimo team) suggested that we can change groupId from tomcat to org.apache.tomcat. For backward compatibility we would add poms with relocations in tomcat directory. What do you think? I still have no answer, where shoul I upload my poms. Greg
Re: Tomcat POMs
- Original Message - From: Carlos Sanchez [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Friday, March 17, 2006 12:58 AM Subject: Re: Tomcat POMs I'm not such a fan of classifiers, I'd do a profile triggered by jdk version dependencies !-- deps required in all jdk versions -- /dependencies profiles profile activation jdk1.4/jdk /activation !-- add here the dependencies for 1.4 -- /profile profile activation jdk1.3/jdk /activation !-- add here the dependencies for 1.3 + 1.4 -- /profile /profiles 1.4 and 1.5 support are important, 1.3 depends on what level of detail you want to go, as you said, maven runs on 1.4+ This is the way I have done it. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat POMs
Hi all I have already prepared all poms for Tomcat 5.5.15 artifacts. I have some questions about dependencies because some things can be achieved in more then one way and I don't know which way is the best. I want to discuss a little with maven team before I give them to Geronimo team. Where should I upload them, which project on JIRA? Does anybody want to discuss about it at all? For example: How should I add xml-apis and mx4j? All classes from xml-apis exist in JDK 1.4, and 1.5. They are not present in JDK 1.3, but Maven does not work with 1.3, so this is not a problem (I think). So shoul I add xml-apis dependencies or not? MX4J is an equivalent for Sun's JMX. JMX exists in JDK 1.5, and does not exist in JDK 1.4. Shoud MX4J dependency be added in a profile triggered by jdk1.4/jdk (I don't know if something like less then 1.5 works) Greetings Greg
Question about xml-apis dependencies
Hello This is important for me, so don't ignore if you can help!! There are xml-apis dependencies in commons-digester and commons-modeler poms on ibiblio (for example). When do I need them? When I run Maven with Java 1.5 or 1.4, I have all javax.xml.* classes in rt.jar. So I don't need additional (endorsed) library. It would be needed when building with JDK 1.3, but can Maven be run with this JDK? Isn't this version too old? I'm preparing poms for Tomcat 5.5.15 artifacts. Some of them depend on commons-modeler:commons-modeler:1.1. commons-modeler:commons-modeler:1.1 depends on: - commons-digester:commons-digester:1.2 - xml-apis:xml-apis:2.0.2 - ... others... commons-digester:commons-digester:1.2 depends on: - xml-apis:xml-apis:1.0.b2 - ...others... Tomcat has no xml-apis.jar in its distribution. I don't know if it can run on JDK 1.3. Maybe not. So should I exclude xml-apis dependencies in Tomcat poms: dependency groupIdcommons-modeler/groupId artifactIdcommons-modeler/artifactId version1.1/version exclusions exclusion groupIdxml-apis/groupId artifactIdxml-apis/artifactId /exclusion /exclusions /dependency or not: dependency groupIdcommons-modeler/groupId artifactIdcommons-modeler/artifactId version1.1/version /dependency To exclude or not to exclude, that is the question ;-))) Greg
Re: [discussion] Improving poms on ibiblio
- Original Message - From: Jacek Laskowski [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Monday, March 06, 2006 3:09 PM Subject: Re: [discussion] Improving poms on ibiblio 06-03-06, Grzegorz Słowikowski [EMAIL PROTECTED] napisał(a): Hi Wendy Now I have some time and I started preparing poms for all Tomcat artifacts. I have checked out all modules from svn (tags TOMCAT_5_5_15) and now I'm preparing poms for them. I already see, that I will have many questions. Where can we discuss it all? On Tomcat Bugzilla? Witaj Grzegorz, Isn't it already sorted out? See http://jira.codehaus.org/browse/MAVENUPLOAD-761. No, Brett made only commons-modeler pom and uploaded it with jar. Tomcat artifacts still wait for poms. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Improving poms on ibiblio
- Original Message - From: Wendy Smoak [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Tuesday, February 28, 2006 4:00 PM Subject: Re: [discussion] Improving poms on ibiblio On 2/28/06, Grzegorz Słowikowski [EMAIL PROTECTED] wrote: I analyzed ALL Tomcat 5.5.9, 5.5.12 and 5.5.15 ibiblio artifacts. What I found is: - all 5.5.9 and 5.5.12 artifacts have empty poms - only modelVersion, groupId, artifactId and version tags, no dependencies!! - all 5.5.15 artifacts have NO poms (I cannot even find maven upload issue for Tomcat 5.5.15 to check who uploaded it) It would have been synced from the Apache repository, not uploaded. I'm not sure about we don't generate empty poms though. Has that changed? If there was no pom we used to get a minimal one so Maven 2 would at least work even without transitive dependencies. I can do an investigation (check out sources from svn, compare with distribution sources, compile) and generate all poms with dependencies. I can even generate sources and javadocs jars. But I don't know what is the policy. 1. Is it right to prepare pom by person which is not a product author? When generating dependencies I may omit something that is runtime only for example. For an Apache project with missing poms, I think the best thing is to convince the developers to put the files in dist/java-repository where they will sync over to ibiblio. Less work for Carlos that way. :) If you have time to create the poms and open a Bugzilla 'enhancement' ticket with Tomcat, I'll watch for it and help. -- Wendy Hi Wendy Now I have some time and I started preparing poms for all Tomcat artifacts. I have checked out all modules from svn (tags TOMCAT_5_5_15) and now I'm preparing poms for them. I already see, that I will have many questions. Where can we discuss it all? On Tomcat Bugzilla? Question #1: Where are sources for naming-factory-dbcp.jar? Greetings Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discussion] Improving poms on ibiblio
Hi all We know there are many errors in poms on ibiblio. I would like to help to improve some of them. There are some areas I am interesting most. First Tomcat 5.5.x. I analyzed ALL Tomcat 5.5.9, 5.5.12 and 5.5.15 ibiblio artifacts. What I found is: - all 5.5.9 and 5.5.12 artifacts have empty poms - only modelVersion, groupId, artifactId and version tags, no dependencies!! - all 5.5.15 artifacts have NO poms (I cannot even find maven upload issue for Tomcat 5.5.15 to check who uploaded it) I placed first two issues on MEV: http://jira.codehaus.org/browse/MEV-344 http://jira.codehaus.org/browse/MEV-343 I wanted someone copy empty poms from 5.5.12 to 5.5.15 changing only version. Carlos immediately closed them with Won't fix status and comment We don't generate empty poms. If you know what the dependencies are you can submit the pom. I don't understand this. There are only empty poms for all Tomcat 5.5.x artifacts. I can do an investigation (check out sources from svn, compare with distribution sources, compile) and generate all poms with dependencies. I can even generate sources and javadocs jars. But I don't know what is the policy. 1. Is it right to prepare pom by person which is not a product author? When generating dependencies I may omit something that is runtime only for example. 2. Should I generate sources and javadocs jars? 3. How can non-author say which dependencies shold be optional? There are some other products I found their poms need improvements, and I can suggest the improvements, but I would like to hear what do you thing about it all I wrote. Greg
Re: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.ja
Hi Why maven-clean-plugin-2.1 tag was added under maven/components/tags, not i maven/plugins/tags? Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Monday, February 20, 2006 5:37 AM Subject: svn commit: r379023 - in /maven/components/tags/maven-clean-plugin-2.1: ./ pom.xml src/main/java/org/apache/maven/plugin/clean/CleanMojo.java src/main/java/org/apache/maven/plugin/clean/Fileset.java Author: jdcasey Date: Sun Feb 19 20:37:49 2006 New Revision: 379023 URL: http://svn.apache.org/viewcvs?rev=379023view=rev Log: [maven-scm] copy for tag maven-clean-plugin-2.1 Added: maven/components/tags/maven-clean-plugin-2.1/ - copied from r377744, maven/plugins/trunk/maven-clean-plugin/ maven/components/tags/maven-clean-plugin-2.1/pom.xml - copied unchanged from r379022, maven/plugins/trunk/maven-clean-plugin/pom.xml maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java - copied unchanged from r378028, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java maven/components/tags/maven-clean-plugin-2.1/src/main/java/org/apache/maven/plugin/clean/Fileset.java - copied unchanged from r377838, maven/plugins/trunk/maven-clean-plugin/src/main/java/org/apache/maven/plugin/clean/Fileset.java -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.11/264 - Release Date: 2006-02-17 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven JXR
Hi maven-jxr 1.0 is not present on ibiblio till today (released 2 or 3 days ago). Greg - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Sunday, January 29, 2006 10:27 PM Subject: Re: Maven JXR JXR is the library that backs both the Maven 1 and Maven 2 plugin. The Maven 2 plugin is the one at mojo, though we've discussed bringing this back to the Maven project now that code is a separate library. - Brett Ersin Er wrote: Hi, I see that Maven JXR 1.0 is tagged (but it's not at ibiblio yet). I seems that it's not a Maven plugin. So how do we use it? I thought I could use it during site generation process but of course it's not accepted as a plugin. (I had asked a question on a previous thread and it was in fact about mojo jxr plugin. It still has the problem i mentioned.) Thanks. -- Ersin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 2006-01-27 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes M2 plugin (there is no JIRA project for this plugin)
Thanks. I just created MOJO/changes issue. Greg - Original Message - From: Mike Perham [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, January 25, 2006 4:55 PM Subject: RE: Changes M2 plugin (there is no JIRA project for this plugin) http://jira.codehaus.org/browse/MOJO changes component -Original Message- From: Grzegorz Słowikowski [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 25, 2006 9:24 AM To: Maven Developers List Subject: Changes M2 plugin (there is no JIRA project for this plugin) Hi Maven2 changes plugin 2.0-beta-1 When parsing changes.xml we got exception. This exception is not logged. there is e.printStackTrace() instead of log statement. (org.apache.maven.changes.ChangesXML.java line 62) Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.22/239 - Release Date: 2006-01-24 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changes M2 plugin (there is no JIRA project for this plugin)
Hi Maven2 changes plugin 2.0-beta-1 When parsing changes.xml we got exception. This exception is not logged. there is e.printStackTrace() instead of log statement. (org.apache.maven.changes.ChangesXML.java line 62) Greg
Re: why no ant tasks for m2.0.2 on the repository
Hi maven-embedder 2.0.2 continuum-plexus-application 1.0.2 many continuum 1.0.1 artifacts are not present on ibiblio too. Greg - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Tuesday, January 24, 2006 1:20 AM Subject: Re: why no ant tasks for m2.0.2 on the repository It's a manual step in the release process that hadn't been included in our docs, so each time a different person cuts the release it gets skipped. Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1 Will look into it - Brett Steve Loughran wrote: Is there any reason why the ant tasks for m2 dont automaticallly go up on the repository at the same time all the other artefacts are released? only the 2.0.1 version is there right now. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.22/238 - Release Date: 2006-01-23 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2.0.2 bootstrap problems
Hi I just cleared my local repo and tried to bootstrap Maven from 2.0.2 tag. There are some problems in integration tests (localhost: is my maven proxy): I think 2. and 3. should be fixed easy and quickly. 1. it0088 Log fragment: --- T E S T S --- [surefire] Running org.apache.maven.it0088.PomInterpolationTest [surefire] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 0,047 sec FAILURE !! Results : [surefire] Tests run: 2, Failures: 2, Errors: 0 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] There are some test failure. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: There are some test failure. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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) Caused by: org.apache.maven.plugin.MojoExecutionException: There are some test failure. at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:384) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530) ... 16 more 2. it0075 It tries to use maven-help-plugin. There are no releases of this plugin on ibiblio. There is only maven-projecthelp-plugin (old name of this plugin) 2.0-beta-1. I think that someone spoiled www.ibiblio.org/maven2/org/apache/maven/plugins/maven-metadata.xml file (probably the one who releases pmd plugin). There are no prefix - artifactid mappings except pmd. Log fragment: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-help-plugin' does not exist or no valid version could be found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-help-plugin' does not exist or no valid version could be found at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1203) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1436) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:134) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) 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) Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The
Integration tests
Hi all We have a lot of problems with our integration tests, and I would like to share out thoughts with you. I saw voting for Maven 2.0.2 has started, so this is last minute to change something before 2.0.2. 1. I think that the two new phases: before/after-integration-test should be renamed to pre/post-integration-test. The prefixes would be similar to pre/post-site and pre/post-clean. What do you think? 2. We cannot compile our intergation tests sources with maven-compiler-plugin because we cannot change compileSourceRoots. Firstly it is readonly, and secondly there is no way to set them in configuration in pom file. We had to write our own it compiler plugin by copying almost all sources from TestCompilerMojo.java. What would be the best solution? Changing one of the standard compiler mojos? Adding additional generic mojo without readonly's, with possibility to set source roots, etc? Maybe something else. I don't like what we had to do - copy/paste a lot of source from one of maven-compiler-plugin mojos. Pablo from my team wrote about it today, and Bob Allison here: http://jira.codehaus.org/browse/MCOMPILER-13. 3. Now all our artifacts for integration testing (there are lot of them) have test scope. So they are included in unit testing classpaths too. Would it be ok to add another scope - it to separate it artifacts from unit testing artifacts? 4. ... more later ... Greg
Re: plugins tags in apache/maven/components/tags/...
This is the best solution, but you have not copied all tags (eg. maven-site-plugin-..., maven-war-plugin-...). Why? Greg - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Thursday, January 05, 2006 10:24 PM Subject: Re: plugins tags in apache/maven/components/tags/... Actually, we should do an svn cp to the new location so they are in both. I'll do that now. - Brett Grzegorz Słowikowski wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Thursday, January 05, 2006 3:24 PM Subject: Re: plugins tags in apache/maven/components/tags/... Grzegorz Słowikowski wrote: Hi I know that this is not important at all, but don't you wath to move plugin tag directories in svn from .../apache/maven/components/tags/... to .../apache/maven/plugins/tags/...? We left the tags there for the releases we made prior to creating a separate tree for the plugins. All subsequent releases will be tagged in the new location. Greg -- jvz. I know that, but new users may have problems finding them. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.14/222 - Release Date: 2006-01-05 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plugins tags in apache/maven/components/tags/...
Hi I know that this is not important at all, but don't you wath to move plugin tag directories in svn from .../apache/maven/components/tags/... to .../apache/maven/plugins/tags/...? Greg
Re: plugins tags in apache/maven/components/tags/...
- Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Thursday, January 05, 2006 3:24 PM Subject: Re: plugins tags in apache/maven/components/tags/... Grzegorz Słowikowski wrote: Hi I know that this is not important at all, but don't you wath to move plugin tag directories in svn from .../apache/maven/components/tags/... to .../apache/maven/plugins/tags/...? We left the tags there for the releases we made prior to creating a separate tree for the plugins. All subsequent releases will be tagged in the new location. Greg -- jvz. I know that, but new users may have problems finding them. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun's libraries in ibiblio repository
Done - MEV-126 Greg - Original Message - From: Jason van Zyl [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, October 19, 2005 4:12 AM Subject: Re: Sun's libraries in ibiblio repository On Tue, 2005-10-18 at 11:35 +0200, Grzegorz Słowikowski wrote: Hi Not all Sun's libraries poms have very helpful tags: urlhttp://java.sun.com/products/jta/url distributionManagement downloadUrlhttp://java.sun.com/products/jta/downloadUrl /distributionManagement (this is from jta/jta) I would be great when all other Sun's libraries have such description in their poms. We are trying, if you see something that's missing use JIRA: http://jira.codehaus.org/browse/MEV And include a better POM :-) Greg -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat
The mistake with slashes is obvious, but it still doesn't work on my system. I have error message Invalid directory name (I have Polish Windows, so this is my translation from Polish). Can anyone confirm that it works now? Greg - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Tuesday, October 18, 2005 11:00 PM Subject: Re: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat This was just a dumb mistake: / should be \. I've tested this and it works. - Brett Grzegorz Słowikowski wrote: Hi Command: %~dps0/mvn %* in m2.bat doesn't work. Why don't use simply: mvn %* Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Saturday, October 15, 2005 8:27 PM Subject: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat Author: brett Date: Sat Oct 15 11:27:49 2005 New Revision: 321412 URL: http://svn.apache.org/viewcvs?rev=321412view=rev Log: merg from tag up to r321409 Added: maven/components/trunk/maven-core/src/bin/mvn - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn maven/components/trunk/maven-core/src/bin/mvn.bat - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn.bat Modified: maven/components/trunk/maven-core/src/bin/m2 maven/components/trunk/maven-core/src/bin/m2.bat Modified: maven/components/trunk/maven-core/src/bin/m2 URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core/src/bin/m2?rev=321412r1=321411r2=321412view=diff == ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat
No, Windows XP. I don't know this syntax, but from my experience you don't need %~dps0/ part of the command. I tested it and simpe mvn does work. I will try to figure out, what's going on. Greg P.S You could change m2 calls to mvn ones in all scripts to avoid log messages about deprecation. - Original Message - From: Brett Porter [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Tuesday, October 18, 2005 2:59 AM Subject: Re: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat It works for me - Are you on Windows 98? Grzegorz Słowikowski wrote: Hi Command: %~dps0/mvn %* in m2.bat doesn't work. Why don't use simply: mvn %* Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Saturday, October 15, 2005 8:27 PM Subject: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat Author: brett Date: Sat Oct 15 11:27:49 2005 New Revision: 321412 URL: http://svn.apache.org/viewcvs?rev=321412view=rev Log: merg from tag up to r321409 Added: maven/components/trunk/maven-core/src/bin/mvn - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn maven/components/trunk/maven-core/src/bin/mvn.bat - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn.bat Modified: maven/components/trunk/maven-core/src/bin/m2 maven/components/trunk/maven-core/src/bin/m2.bat Modified: maven/components/trunk/maven-core/src/bin/m2 URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core/src/bin/m2?rev=321412r1=321411r2=321412view=diff == ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sun's libraries in ibiblio repository
Hi Not all Sun's libraries poms have very helpful tags: urlhttp://java.sun.com/products/jta/url distributionManagement downloadUrlhttp://java.sun.com/products/jta/downloadUrl /distributionManagement (this is from jta/jta) I would be great when all other Sun's libraries have such description in their poms. Greg
Re: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat
Hi Command: %~dps0/mvn %* in m2.bat doesn't work. Why don't use simply: mvn %* Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Saturday, October 15, 2005 8:27 PM Subject: svn commit: r321412 - in /maven/components/trunk/maven-core/src/bin: m2 m2.bat mvn mvn.bat Author: brett Date: Sat Oct 15 11:27:49 2005 New Revision: 321412 URL: http://svn.apache.org/viewcvs?rev=321412view=rev Log: merg from tag up to r321409 Added: maven/components/trunk/maven-core/src/bin/mvn - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn maven/components/trunk/maven-core/src/bin/mvn.bat - copied unchanged from r321409, maven/components/tags/maven-2.0/maven-core/src/bin/mvn.bat Modified: maven/components/trunk/maven-core/src/bin/m2 maven/components/trunk/maven-core/src/bin/m2.bat Modified: maven/components/trunk/maven-core/src/bin/m2 URL: http://svn.apache.org/viewcvs/maven/components/trunk/maven-core/src/bin/m2?rev=321412r1=321411r2=321412view=diff == ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r321131 - /maven/components/trunk/m2-bootstrap-all.sh
Hi And what about m2-bootstrap-all.bat? Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Friday, October 14, 2005 4:20 PM Subject: svn commit: r321131 - /maven/components/trunk/m2-bootstrap-all.sh Author: brett Date: Fri Oct 14 07:19:58 2005 New Revision: 321131 URL: http://svn.apache.org/viewcvs?rev=321131view=rev Log: seems to be choking on the bootstrap-built plugin-plugin in the reactor, try building manually first Modified: maven/components/trunk/m2-bootstrap-all.sh Modified: maven/components/trunk/m2-bootstrap-all.sh URL: http://svn.apache.org/viewcvs/maven/components/trunk/m2-bootstrap-all.sh?rev=321131r1=321130r2=321131view=diff == --- maven/components/trunk/m2-bootstrap-all.sh (original) +++ maven/components/trunk/m2-bootstrap-all.sh Fri Oct 14 07:19:58 2005 @@ -47,14 +47,21 @@ ) ret=$?; if [ $ret != 0 ]; then exit $ret; fi +echo --- +echo Rebuilding maven2 plugins ... +echo --- + # I Really Don't want to be rebuilding these (Especially the reports) every time, but # until we regularly push them to the repository and the integration tests rely on # some of these plugins, there is no choice ( - echo --- - echo Rebuilding maven2 plugins ... - echo --- + # Build plugin plugin first, it seems to choke on the version built by the bootstrap + cd maven-plugins/maven-plugin-plugin + + m2 --no-plugin-registry --batch-mode --fail-at-end -e $ARGS clean:clean install +) +( cd maven-plugins # update the release info to ensure these versions get used in the integration tests m2 --no-plugin-registry --batch-mode --fail-at-end -e $ARGS clean:clean install - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r321131 - /maven/components/trunk/m2-bootstrap-all.sh
Hi all What exactly does your Continuum when building m2? I'm asking because very often I cannot bootstrap m2 from 'trunk' souces while Continuum sends me email about successful compilation. Does it call m2-bootstrap-all or something other? Some days ago I saw that: - after update from scm Continuum built m2 successfully - after fresh checkout - there were errors Bootstraping cleans everything before building, so I don't understand why Continuum performed differently after fresh checkout. Greg P.S. I have Windows, and I think you have Linux. I did some corrections in bat files so they look like sh ones. - Original Message - From: Grzegorz Słowikowski [EMAIL PROTECTED] To: dev@maven.apache.org Sent: Monday, October 17, 2005 2:59 PM Subject: Re: svn commit: r321131 - /maven/components/trunk/m2-bootstrap-all.sh Hi And what about m2-bootstrap-all.bat? Greg - Original Message - From: [EMAIL PROTECTED] To: commits@maven.apache.org Sent: Friday, October 14, 2005 4:20 PM Subject: svn commit: r321131 - /maven/components/trunk/m2-bootstrap-all.sh Author: brett Date: Fri Oct 14 07:19:58 2005 New Revision: 321131 URL: http://svn.apache.org/viewcvs?rev=321131view=rev Log: seems to be choking on the bootstrap-built plugin-plugin in the reactor, try building manually first Modified: maven/components/trunk/m2-bootstrap-all.sh Modified: maven/components/trunk/m2-bootstrap-all.sh URL: http://svn.apache.org/viewcvs/maven/components/trunk/m2-bootstrap-all.sh?rev=321131r1=321130r2=321131view=diff == --- maven/components/trunk/m2-bootstrap-all.sh (original) +++ maven/components/trunk/m2-bootstrap-all.sh Fri Oct 14 07:19:58 2005 @@ -47,14 +47,21 @@ ) ret=$?; if [ $ret != 0 ]; then exit $ret; fi +echo --- +echo Rebuilding maven2 plugins ... +echo --- + # I Really Don't want to be rebuilding these (Especially the reports) every time, but # until we regularly push them to the repository and the integration tests rely on # some of these plugins, there is no choice ( - echo --- - echo Rebuilding maven2 plugins ... - echo --- + # Build plugin plugin first, it seems to choke on the version built by the bootstrap + cd maven-plugins/maven-plugin-plugin + + m2 --no-plugin-registry --batch-mode --fail-at-end -e $ARGS clean:clean install +) +( cd maven-plugins # update the release info to ensure these versions get used in the integration tests m2 --no-plugin-registry --batch-mode --fail-at-end -e $ARGS clean:clean install - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mailing list
Thank you. Now I see, that I haven't received any commit message for 8 hours because SVN was down (there were no commits) ;-) Today everything works well. By the way, what tool is monitoring commits and sends mails for maven projects? I like it very much and I want such functionality in my repository. Is it Maven, Continuum, or something else? How is it configured. Similar messages from codehaus projects are even better because they are formatted and the diffs are coloured. We tried to implement such functionality inside our cvs repository, but the results are not satisfying me. Can you help me? Greg - Original Message - From: John Casey [EMAIL PROTECTED] To: Maven Developers List dev@maven.apache.org Sent: Wednesday, October 05, 2005 4:38 PM Subject: Re: Mailing list -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I forwarded this thread on to the guy (Roy Fielding, I think?) who did the work last night, so we'll see what he says. - -j Allison, Bob wrote: | I just tried that and it said I was already a subscriber. Was the email address in the SVN stuff updated correctly? | | -Original Message- | From: John Casey [mailto:[EMAIL PROTECTED] | Sent: Wednesday, October 05, 2005 10:28 | To: Maven Developers List | Subject: Re: Mailing list | | | Last night, we split out dev list into dev and commits. I thought | everyone was supposed to have been automatically subscribed to the new | list, but apparently this is not the case. You should be able to remedy | this with an email to: | | mailto:[EMAIL PROTECTED] | | IIRC | | good luck, | | john | | Grzegorz Słowikowski wrote: | | Hi | | | | I'm on developer list. I don't get any svn/continuum mails | | today. I read about new mailing lists, but links to then | | are not present on maven site. What's going on? | | | | Thanks | | | | Greg Slowikowski | | Poland | | - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDQ+WDK3h2CZwO/4URArltAJ0fmzRNu6X6mppfU1a9kCv6YXKgmwCgggWe Bt5v/10gWaMkOiIr9SufNrY= =Vwyf -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mailing list
Hi I'm on developer list. I don't get any svn/continuum mails today. I read about new mailing lists, but links to then are not present on maven site. What's going on? Thanks Greg Slowikowski Poland
