Re: scopeperi/scope
Brett Porter wrote: On 28/06/2011, at 7:46 AM, Benson Margulies wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Right - you should be declaring a new type in a plugin that can turn off addedToClasspath/ A component descriptor is normally enough. A plugin is only needed if such an archive requires a very special handling that cannot be accomplished easily with the dependency or assembly plugin. - or use a packaging type like zip which wasn't already. Just as a side node: ZIP *is* added to the classpath - unfortunately. We use therefore a simple jar file with a plexus component descriptor that turns that off: % = component-set components component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintzip/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typezip/type addedToClasspathfalse/addedToClasspath includesDependenciestrue/includesDependencies /configuration /component /components /component-set % = This jar is added as extension to our global parent POM. Additionally you have to set the extensions flag for all plugins to true that have to respect this (e.g. compiler plugin) which is also done in this parent POM in the pluginMgmt section. [snip] - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
Stan Devitt, Platform Group - Original Message - From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] Sent: Tuesday, June 28, 2011 02:40 AM To: dev@maven.apache.org dev@maven.apache.org Subject: Re: scopeperi/scope Brett Porter wrote: On 28/06/2011, at 7:46 AM, Benson Margulies wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Right - you should be declaring a new type in a plugin that can turn off addedToClasspath/ A component descriptor is normally enough. A plugin is only needed if such an archive requires a very special handling that cannot be accomplished easily with the dependency or assembly plugin. - or use a packaging type like zip which wasn't already. Just as a side node: ZIP *is* added to the classpath - unfortunately. We use therefore a simple jar file with a plexus component descriptor that turns that off: % = component-set components component roleorg.apache.maven.artifact.handler.ArtifactHandler/role role-hintzip/role-hint implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation configuration typezip/type addedToClasspathfalse/addedToClasspath includesDependenciestrue/includesDependencies /configuration /component /components /component-set % = This jar is added as extension to our global parent POM. Additionally you have to set the extensions flag for all plugins to true that have to respect this (e.g. compiler plugin) which is also done in this parent POM in the pluginMgmt section. [snip] - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
Apologies: I hit the wrong button. I am enjoying this thread. My main observation so far is that if you need one custom scope (and I think you do) then you will need more. Provided is not enough. The custom scope seems to let you get at lists of dependencies that have a special purpose. They seem to do this without breaking anything or interfering with the existing classpaths.. There can be more than one special purpose. There is more than just Java. Stan Stan Devitt, Platform Group - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] ReleaseMaven Release plugin version 2.2
+1 LieGrue, strub --- On Mon, 6/27/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: [VOTE] ReleaseMaven Release plugin version 2.2 To: Maven Developers List dev@maven.apache.org Date: Monday, June 27, 2011, 9:23 AM Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=16778 Staging repo: https://repository.apache.org/content/repositories/maven-061/ Source distribution: https://repository.apache.org/content/repositories/maven-061/org/apache/maven/release/maven-release/2.2/maven-release-2.2-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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] ReleaseMaven Release plugin version 2.2
On Mon, 27 Jun 2011 10:23:27 +0100 Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 (non-binding) Thanks, Tony Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=16778 Staging repo: https://repository.apache.org/content/repositories/maven-061/ Source distribution: https://repository.apache.org/content/repositories/maven-061/org/apache/maven/release/maven-release/2.2/maven-release-2.2-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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: core integration tests trunk
I get the same failure on my Mac. I recommend to configure a jenkins job as multi-configuration type, see eg https://builds.apache.org/job/doxia/ (Just choose multi-configuration-project instead of maven2/3 project when adding the job) HTH, -Lukas Benson Margulies wrote: I just added an IT for MNG-5062. When I run the whole set, I get: Tests run: 697, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,520.853 sec FAILURE! Results : Failed tests: testitMNG3951(org.apache.maven.it.MavenITmng3951AbsolutePathsTest): expected:/private/tmp but was:/tmp Tests run: 697, Failures: 1, Errors: 0, Skipped: 0 This looks like a macosx incompatibity to me. Anyone else with a view? - 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: scopeperi/scope
I was pretty sleepy last night. My residual disagreement is that 'provided' doesn't just mean 'copy to local repo'. It means 'copy to local repo and put in test classpath.' Yes, I now get it, an appropriate packaging avoids any classpath. The word 'provided' is used because it's 'provided' by the environment by magic at runtime. I end up thinking that one more scope would make this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that I provide a specific GAV in my pom so that you don't bother trying to pull it in for another dep... eg. log4j-over-slf4 would provides log4j test-compile test-runtime some scope that is like compile runtime but not the test classpath... Actually the more I think about it what you really want to specify, in a standardized way is the list of classpaths to add to, and whether it is transitive on that classpath... And of course in the non-maven world, classpath does not make sense... but there are equivalents dependency groupId.../groupId artifactId.../artifactId
Re: scopeperi/scope
On 28 June 2011 11:31, Benson Margulies bimargul...@gmail.com wrote: I was pretty sleepy last night. My residual disagreement is that 'provided' doesn't just mean 'copy to local repo'. It means 'copy to local repo and put in test classpath.' Yes, I now get it, an appropriate packaging avoids any classpath. The word 'provided' is used because it's 'provided' by the environment by magic at runtime. I end up thinking that one more scope would make this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use import - nobody has a clue what exactly this does Critically missing from my PoV are: provides - needs a better name, but I want to signify that
Re: scopeperi/scope
On 28 June 2011 11:38, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 11:31, Benson Margulies bimargul...@gmail.com wrote: I was pretty sleepy last night. My residual disagreement is that 'provided' doesn't just mean 'copy to local repo'. It means 'copy to local repo and put in test classpath.' Yes, I now get it, an appropriate packaging avoids any classpath. The word 'provided' is used because it's 'provided' by the environment by magic at runtime. I end up thinking that one more scope would make The critical scope to add for me is something along the lines of provides or supplies or embeds-equivalent So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that
maven-war-plugin problem - jar file unexpectedly trimmed (truncated)
Hi all, Sorry for annonying you, but i have searched my problem in the wiki, in the documentation, on the web, post it in various forums, in user-list and no one seems to be able to answer me. Here it is : I have a web-app configured with a pom.xml. This web-app relies on another maven module that produce a jar file. When i check the produced jar file size it is 8Ko in my local repo. When i check this same jar file in my /lib web application, it is 5Ko. A bunch of classes are simply ignored when the jar file reaches my /lib directory, causing ClassNotFoundException when running the web application. Why is my jar trimmed ? Stephan ** Maven 2.2.1 maven-war-plugin: 2.1.1 ** Web-app pom.xml ** project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent artifactIdrecord/artifactId groupIdcom.company.record/groupId version1.0.0/version /parent groupIdcom.company.record/groupId artifactIdrecord-webapp/artifactId packagingwar/packaging namerecord-webapp/name version1.0.0/version dependencies !-- JSF 2.0 -- dependency groupIdcom.sun.faces/groupId artifactIdjsf-api/artifactId version2.0.3-b02/version typejar/type scopecompile/scope /dependency dependency groupIdcom.sun.faces/groupId artifactIdjsf-impl/artifactId version2.0.3-b02/version typejar/type scopecompile/scope /dependency !-- Primefaces -- dependency groupIdorg.primefaces/groupId artifactIdprimefaces/artifactId version2.2/version typejar/type scopecompile/scope /dependency dependency groupIdorg.primefaces.themes/groupId artifactIdredmond/artifactId version1.0.0/version /dependency !-- Internal dependencies -- dependency groupIdcom.company.record/groupId artifactIdrecord-dao/artifactId version1.0.0/version typejar/type scopecompile/scope /dependency /dependencies build finalNamerecord/finalName plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId version1.5.0/version configuration serverNameweb/serverName /configuration /plugin plugin artifactIdmaven-war-plugin/artifactId version2.1.1/version executions execution iddefault-war/id phasepackage/phase goals goalwar/goal /goals /execution /executions configuration useCachefalse/useCache /configuration /plugin /plugins /build repositories repository idprime-repo/id namePrime Technology Maven Repository/name urlhttp://repository.prime.com.tr/url layoutdefault/layout /repository /repositories /project ** record-dao pom.xml ** project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion parent artifactIdrecord/artifactId groupIdcom.company.record/groupId version1.0.0/version /parent groupIdcom.company.record/groupId artifactIdrecord-dao/artifactId version1.0.0/version packagingjar/packaging namerecord-dao/name dependencies !-- Hibernate -- dependency groupIdorg.hibernate/groupId artifactIdhibernate-entitymanager/artifactId version3.6.4.Final/version exclusions exclusion artifactIdcglib/artifactId groupIdcglib/groupId /exclusion exclusion artifactIdantlr/artifactId groupIdantlr/groupId /exclusion exclusion artifactIdjta/artifactId groupIdjavax.transaction/groupId /exclusion exclusion artifactIdcommons-collections/artifactId groupIdcommons-collections/groupId /exclusion exclusion artifactIdhibernate-commons-annotations/artifactId groupIdorg.hibernate/groupId /exclusion /exclusions /dependency !-- Postgresql -- dependency groupIdpostgresql/groupId artifactIdpostgresql/artifactId version8.3-606.jdbc4/version typejar/type scopecompile/scope /dependency !-- Internal dependencies -- dependency groupIdcom.company.record/groupId artifactIdrecord-commun/artifactId version1.0.0/version typejar/type scopecompile/scope /dependency /dependencies /project - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
The critical scope to add for me is something along the lines of provides or supplies or embeds-equivalent Why is this a scope and not just more configuration inside the dependency/ element? dependency !-- gav -- alsoProvides alsoProvide !-- gav -- /alsoProvide /alsoProvides /dependency So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact type unless i mis-understand your case So, what would you think of dependency !-- gav -- scopenon-classpath/scope listtomcat/list /dependency That is, define the concept of a named list of dependencies, which seems harmlessly extensible, while defining exactly one more scope, to use for this purpose? On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Allowing people to have custom scopes is a thin end of the wedge... The scopes we have are not sufficient, so I am +1 to expanding them Custom scopes are a recipe for disaster... the whole point of standardization is that everyone knows what they mean. Currently we have: compile - which we have borked to be transitive but shouldn't be runtime - fair enough provided - which is closer to what compile should have been test - not good enough for the multitude of testing phases system - Eeek! don't use
Re: maven-war-plugin problem - jar file unexpectedly trimmed (truncated)
I finally find a solution. In the web-app/web-inf/lib directory, there was a jar file who was sharing the same name with the dependent jar file. For a reason i don't understand, maven-war-plugin used to take this old jar file rather than the freshly one i installed in my local repository. - Original Message - From: Stéphan BEUZE stephan.be...@douane.finances.gouv.fr To: dev@maven.apache.org Sent: Tuesday, June 28, 2011 2:05 PM Subject: maven-war-plugin problem - jar file unexpectedly trimmed (truncated) Hi all, Sorry for annonying you, but i have searched my problem in the wiki, in the documentation, on the web, post it in various forums, in user-list and no one seems to be able to answer me. Here it is : I have a web-app configured with a pom.xml. This web-app relies on another maven module that produce a jar file. When i check the produced jar file size it is 8Ko in my local repo. When i check this same jar file in my /lib web application, it is 5Ko. A bunch of classes are simply ignored when the jar file reaches my /lib directory, causing ClassNotFoundException when running the web application. Why is my jar trimmed ? Stephan ** Maven 2.2.1 maven-war-plugin: 2.1.1 ** Web-app pom.xml ** project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion parent artifactIdrecord/artifactId groupIdcom.company.record/groupId version1.0.0/version /parent groupIdcom.company.record/groupId artifactIdrecord-webapp/artifactId packagingwar/packaging namerecord-webapp/name version1.0.0/version dependencies !-- JSF 2.0 -- dependency groupIdcom.sun.faces/groupId artifactIdjsf-api/artifactId version2.0.3-b02/version typejar/type scopecompile/scope /dependency dependency groupIdcom.sun.faces/groupId artifactIdjsf-impl/artifactId version2.0.3-b02/version typejar/type scopecompile/scope /dependency !-- Primefaces -- dependency groupIdorg.primefaces/groupId artifactIdprimefaces/artifactId version2.2/version typejar/type scopecompile/scope /dependency dependency groupIdorg.primefaces.themes/groupId artifactIdredmond/artifactId version1.0.0/version /dependency !-- Internal dependencies -- dependency groupIdcom.company.record/groupId artifactIdrecord-dao/artifactId version1.0.0/version typejar/type scopecompile/scope /dependency /dependencies build finalNamerecord/finalName plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-maven-plugin/artifactId version1.5.0/version configuration serverNameweb/serverName /configuration /plugin plugin artifactIdmaven-war-plugin/artifactId version2.1.1/version executions execution iddefault-war/id phasepackage/phase goals goalwar/goal /goals /execution /executions configuration useCachefalse/useCache /configuration /plugin /plugins /build repositories repository idprime-repo/id namePrime Technology Maven Repository/name urlhttp://repository.prime.com.tr/url layoutdefault/layout /repository /repositories /project ** record-dao pom.xml ** project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; modelVersion4.0.0/modelVersion parent artifactIdrecord/artifactId groupIdcom.company.record/groupId version1.0.0/version /parent groupIdcom.company.record/groupId artifactIdrecord-dao/artifactId version1.0.0/version packagingjar/packaging namerecord-dao/name dependencies !-- Hibernate -- dependency groupIdorg.hibernate/groupId artifactIdhibernate-entitymanager/artifactId version3.6.4.Final/version exclusions exclusion artifactIdcglib/artifactId groupIdcglib/groupId /exclusion exclusion artifactIdantlr/artifactId groupIdantlr/groupId /exclusion exclusion artifactIdjta/artifactId groupIdjavax.transaction/groupId /exclusion exclusion artifactIdcommons-collections/artifactId groupIdcommons-collections/groupId /exclusion exclusion artifactIdhibernate-commons-annotations/artifactId groupIdorg.hibernate/groupId /exclusion /exclusions /dependency !-- Postgresql -- dependency groupIdpostgresql/groupId artifactIdpostgresql/artifactId version8.3-606.jdbc4/version typejar/type scopecompile/scope /dependency !-- Internal dependencies -- dependency groupIdcom.company.record/groupId artifactIdrecord-commun/artifactId version1.0.0/version typejar/type scopecompile/scope /dependency /dependencies /project - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,
Re: scopeperi/scope
On 28 June 2011 14:01, Benson Margulies bimargul...@gmail.com wrote: The critical scope to add for me is something along the lines of provides or supplies or embeds-equivalent Why is this a scope and not just more configuration inside the dependency/ element? dependency !-- gav -- alsoProvides alsoProvide !-- gav -- /alsoProvide /alsoProvides /dependency Because why should I have to always state that I'm using org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much better that the pom for org.slf4j:log4j-over-slf4j says oh and by the way I provide log4j:log4j myself so you don't need to pull it in transitively if you depend on me maven could then break the build for you if you pull in log4j:log4j and org.slf4j:log4j-over-slf4j just as it does if you try to pull in two different versions of log4j:log4j and it could ensure that a project that depends on org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency tree. People will say that OSGi is the real answer here, and that you have to... blah blah blah... we are in the real world here, OSGi is good for some things and not for others, Maven needs a solution that is better than having to add excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes to _all_ the dependencies in your project just because you have added a dependency on org.slf4j:log4j-over-slf4j So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the
Re: scopeperi/scope
Because why should I have to always state that I'm using org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much better that the pom for org.slf4j:log4j-over-slf4j says oh and by the way I provide log4j:log4j myself so you don't need to pull it in transitively if you depend on me I think that you are abusing the term 'dependency' here. I think that, if this is worth doing, it's worth adding a new element to the POM at the same level as 'dependencies' to declare that the project's artifact also provides a list of additional gavs. maven could then break the build for you if you pull in log4j:log4j and org.slf4j:log4j-over-slf4j just as it does if you try to pull in two different versions of log4j:log4j and it could ensure that a project that depends on org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency tree. People will say that OSGi is the real answer here, and that you have to... blah blah blah... we are in the real world here, OSGi is good for some things and not for others, Maven needs a solution that is better than having to add excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes to _all_ the dependencies in your project just because you have added a dependency on org.slf4j:log4j-over-slf4j So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here, depends on that giant artifact of data, there. In both cases, the dependency *does* need to be copied to the local repo, but does *not* want to be in classpath. then that is a non-classpath artifact
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
Sebb, I think that you are pointing at the dilemma at the center of this. Anything like this that we put into the top pom is inherited unless overriden, and people are skittish about accidently making everything part of the Maven project. Where would you propose that we put a link to that it would help? -benson On Mon, Jun 27, 2011 at 6:40 PM, sebb seb...@gmail.com wrote: May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - 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 - 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: scopeperi/scope
On 28 June 2011 14:38, Benson Margulies bimargul...@gmail.com wrote: Because why should I have to always state that I'm using org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much better that the pom for org.slf4j:log4j-over-slf4j says oh and by the way I provide log4j:log4j myself so you don't need to pull it in transitively if you depend on me I think that you are abusing the term 'dependency' here. I think that, if this is worth doing, it's worth adding a new element to the POM at the same level as 'dependencies' to declare that the project's artifact also provides a list of additional gavs. I agree, but if you stick to the cannot change the pom format the only thing you can just about do is introduce a new scope. maven could then break the build for you if you pull in log4j:log4j and org.slf4j:log4j-over-slf4j just as it does if you try to pull in two different versions of log4j:log4j and it could ensure that a project that depends on org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency tree. People will say that OSGi is the real answer here, and that you have to... blah blah blah... we are in the real world here, OSGi is good for some things and not for others, Maven needs a solution that is better than having to add excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes to _all_ the dependencies in your project just because you have added a dependency on org.slf4j:log4j-over-slf4j So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a non-classpath dependency... compile (default) makes sense for overlays provided - supplied by the container... in this case tomcat My use case: This artifact of code, here,
Re: scopeperi/scope
I agree, but if you stick to the cannot change the pom format the only thing you can just about do is introduce a new scope. Is this, let's make this feature before we're willing to change the pom or let's never change the pom. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: scopeperi/scope
I would offer scopealsoProvides/scope for the feature you propose. On Tue, Jun 28, 2011 at 11:11 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 14:38, Benson Margulies bimargul...@gmail.com wrote: Because why should I have to always state that I'm using org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much better that the pom for org.slf4j:log4j-over-slf4j says oh and by the way I provide log4j:log4j myself so you don't need to pull it in transitively if you depend on me I think that you are abusing the term 'dependency' here. I think that, if this is worth doing, it's worth adding a new element to the POM at the same level as 'dependencies' to declare that the project's artifact also provides a list of additional gavs. I agree, but if you stick to the cannot change the pom format the only thing you can just about do is introduce a new scope. maven could then break the build for you if you pull in log4j:log4j and org.slf4j:log4j-over-slf4j just as it does if you try to pull in two different versions of log4j:log4j and it could ensure that a project that depends on org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency tree. People will say that OSGi is the real answer here, and that you have to... blah blah blah... we are in the real world here, OSGi is good for some things and not for others, Maven needs a solution that is better than having to add excludesexcludegroupIdlog4j/groupIdartifactIdlog4j/artifactId/exclude/excludes to _all_ the dependencies in your project just because you have added a dependency on org.slf4j:log4j-over-slf4j So that when computing the dependency tree, we could automatically exclude dependencies that are already provided or supplied or embedded in another dependency. The sticking point for me is that it needs a good name different from provided this easier to explain. Try writing a paragraph of doc that we'd put in the pom doc to explain 'provided' if we decide to just stick with this. However, I have a really simple idea. What if we permitted *no scope at all* for non-jar artifacts to serve this purpose? no scope = compile (modello default value) also dependency on war artifacts is used for war overlays what I am thinking is that if we change the war plugin so that only scope compile wars are used for overlays, then tomcat maven plugin is free to use either provided and/or runtime as the scope for side-deployment... runtime could be good if you always needed it as a side webapp (e.g. the ear plugin could then pull those runtime wars in transitively, while the provided would behave as non-transitive) On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wars are really side web apps that are provided by somebody else at deployment time in the runtime container. just as the server api is provided by somebody else. the tomcat plugin is providing the container, so as it knows those side apps are not present it would make sense to me if it provided them for me. just like when running unit tests, surfer will provide the provided deps on my test classpath. what i am saying is tomato does not need a special scope. symmantically their required scope is provided. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 00:46, Benson Margulies bimargul...@gmail.com wrote: The tomcat wars are NOT provided. The idea is to grab them from the repositories, copy them to the local repo, and have the tomcat plugin 'collect them all.' I didn't know that maven already had the concept of non-classpath artifact types. I've been laboring under the idea that these things would end up in the classpath if not excluded somehow. Tomcat could stop using the special scope, but then it would need to redundantly list these artifacts in its own config, unless the author were willing to take the attitude that *all* war dependencies should be launched. Using foo:bar syntax instead of a nest of XML that is perhaps not too awful, but it still feels like listing the same thing twice. Hmm: how does the new site plugin avoid this? With the new site plugin, can you built a reporting plugin in the reactor and then use it in a site? I bet not. In short, I'm arguing for some idea of annotating dependencies to avoid redundantly calling them out in plugins, but I'm not arguing terribly loudly. On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 28 June 2011 00:15, Benson Margulies bimargul...@gmail.com wrote: Consider the tomcat use case, and then mine. The tomcat use-case is: declare additional artifacts of type/packaging 'war'. The plugin launches them as additional webapps. Why won't provided work for this? war is a
Re: scopeperi/scope
On 28 June 2011 16:27, Benson Margulies bimargul...@gmail.com wrote: I agree, but if you stick to the cannot change the pom format the only thing you can just about do is introduce a new scope. Is this, let's make this feature before we're willing to change the pom or let's never change the pom. We, as of yet, do not have a good story for how we can change the pom format... without breaking all the clients of poms out there... Keeping in mind that some of the clients are not using Maven's tooling to parse the pom. The best story so far is to deploy a side-pom that is of the new format, so you would be deploying for example foo-1.0.pom and foo-1.0.pom5 for the version 5 format pom. And our deploy tooling would convert a pom5 into an old modelVersion 4.0.0 pom... this gives the issue of how do we extend again... will we then end up with .pom, .pom5, .pom6, .pom7, .pom8 all being deployed at the same time? So then the story goes that we get an extensible format right and that is what we deploy (perhaps with a classifier, since poms do not yet have classifiers, and that way we are not baking version numbers into the file extension... foo-1.0.pom and foo-1.0-extensible.pom if you are building with a maven version that knows of extensible poms it would try for the extensible pom first and fail-back to the 4.0.0 pom. Old builds will only see the 4.0.0 poms... Maven repo managers can forward convert the 4.0.0 poms to extensible through an established mapping rule or such if we want to reduce bandwidth... but then what about the checksums of those poms... and the gpg signatures... we could do it for central as a one-time operation with a known gpg signature though as a work-around... What I have not seen is a concrete solid proposal for an extensible pom format... and until we have one of those, that can be proven to be extensible enough that we don't have to dance around again to accomodate older clients, essentially the pom format is frozen. -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
done [1] site deployed [2] any comments appreciated to continue to improve the documentation Regards, Hervé [1] http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?view=markup [2] http://maven.apache.org/pom/asf/ Le mardi 28 juin 2011, sebb a écrit : May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - 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 - 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] ReleaseMaven Release plugin version 2.2
+1 Thanks ! -- Olivier 2011/6/27 Stephen Connolly stephen.alan.conno...@gmail.com: Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=16778 Staging repo: https://repository.apache.org/content/repositories/maven-061/ Source distribution: https://repository.apache.org/content/repositories/maven-061/org/apache/maven/release/maven-release/2.2/maven-release-2.2-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] ReleaseMaven Release plugin version 2.2
+1 Regards, Hervé notice: the staging site is http://maven.apache.org/staging/maven-release/ Le lundi 27 juin 2011, Stephen Connolly a écrit : Hi, We solved 12 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName= Htmlversion=16778 Staging repo: https://repository.apache.org/content/repositories/maven-061/ Source distribution: https://repository.apache.org/content/repositories/maven-061/org/apache/mav en/release/maven-release/2.2/maven-release-2.2-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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: core integration tests trunk
FYI I have created some jobs for core integration testing : * ubuntu (1.5 and 1.6) * windows (I have to investigate why it failed currently) * osx (not yet osx here to debug :-) : I wonder if there any symlink on osx for /tmp ?) See jobs here https://builds.apache.org/view/M-R/view/Maven/ with names started with : core-integration-testing-maven-3-trunk 2011/6/28 Lukas Theussl ltheu...@apache.org: I get the same failure on my Mac. I recommend to configure a jenkins job as multi-configuration type, see eg https://builds.apache.org/job/doxia/ (Just choose multi-configuration-project instead of maven2/3 project when adding the job) HTH, -Lukas Benson Margulies wrote: I just added an IT for MNG-5062. When I run the whole set, I get: Tests run: 697, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,520.853 sec FAILURE! Results : Failed tests: testitMNG3951(org.apache.maven.it.MavenITmng3951AbsolutePathsTest): expected:/private/tmp but was:/tmp Tests run: 697, Failures: 1, Errors: 0, Skipped: 0 This looks like a macosx incompatibity to me. Anyone else with a view? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Pom changes
This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core integration tests trunk
On Tue, Jun 28, 2011 at 6:23 PM, Olivier Lamy ol...@apache.org wrote: FYI I have created some jobs for core integration testing : * ubuntu (1.5 and 1.6) * windows (I have to investigate why it failed currently) * osx (not yet osx here to debug :-) : I wonder if there any symlink on osx for /tmp ?) /tmp is really /private/tmp, /Users/benson/asf/mvn/plugins/maven-changes-plugin ls -l /tmp lrwxr-xr-x@ 1 root wheel 11 Aug 14 2009 /tmp - private/tmp /Users/benson/asf/mvn/plugins/maven-changes-plugin See jobs here https://builds.apache.org/view/M-R/view/Maven/ with names started with : core-integration-testing-maven-3-trunk 2011/6/28 Lukas Theussl ltheu...@apache.org: I get the same failure on my Mac. I recommend to configure a jenkins job as multi-configuration type, see eg https://builds.apache.org/job/doxia/ (Just choose multi-configuration-project instead of maven2/3 project when adding the job) HTH, -Lukas Benson Margulies wrote: I just added an IT for MNG-5062. When I run the whole set, I get: Tests run: 697, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1,520.853 sec FAILURE! Results : Failed tests: testitMNG3951(org.apache.maven.it.MavenITmng3951AbsolutePathsTest): expected:/private/tmp but was:/tmp Tests run: 697, Failures: 1, Errors: 0, Skipped: 0 This looks like a macosx incompatibity to me. Anyone else with a view? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
On 28 June 2011 15:40, Benson Margulies bimargul...@gmail.com wrote: Sebb, I think that you are pointing at the dilemma at the center of this. Anything like this that we put into the top pom is inherited unless overriden, and people are skittish about accidently making everything part of the Maven project. Where would you propose that we put a link to that it would help? In a comment near the top of the file. -benson On Mon, Jun 27, 2011 at 6:40 PM, sebb seb...@gmail.com wrote: May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - 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 - 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: Pom changes
On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies bimargul...@gmail.com wrote: But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? the new poms will arrive to central for everyone to use.. Milos On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - 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
