Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. Ralph On Jul 3, 2011, at 10:54 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 10:42 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Out of curiosity, you said you are putting building your jars and putting them in a shared library. What are you going to do with SLF4J, Log4J, Commons Logging and Logback? slf4j, commons-logging etc. will also be installed at /usr/share as usual. Maven needs to shade these jars and few others. So, these jars will be shaded, and packaged together to make an uber-jar. slf4j, commons-logging system jars won't be changed. What exactly the point you are trying to make? And, how does log4j and Logback relates to core maven? I haven't seen these as dependencies! --Kasun Ralph On Jul 3, 2011, at 9:57 AM, Kasun Gajasinghe wrote: On Sun, Jul 3, 2011 at 6:30 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure that the operation you are asking for is well-defined. Shade combines, renames, and transforms, using arbitrary Java plugins that operate entirely on binaries, which can themselves be the output of, well, shade. Trying to read the source and perform the same transformations would be very, very, hard. You might be able to grab jarjar, a non-maven tool with similar capabilities, build it from source, and use it for these simple cases as part of your bootstrap. Or, for bootstrap, you could leave out the shading and just depend on Xerces unrenamed, go all the way around, build shade, and then rebuild. I've ran jarjar with some samples and checked. This would indeed do the job. I hope there is no concerning bugs. I see a bug report saying it fails with ant 1.8. Well, I'm going to go ahead with this. Thanks for the suggestion Benson! --Kasun Or you might be able to cherry-pick the maven-shade-plugin source. It could be that there is a clean separation in there between code connected to the plugin framework and code that does the work. On Sun, Jul 3, 2011 at 7:38 AM, Kasun Gajasinghe kasu...@gmail.com wrote: On Sun, Jul 3, 2011 at 4:23 PM, Benson Margulies bimargul...@gmail.com wrote: I'm not sure what you are asking. Shade is a binary operation that uses asm. It renames packages. There is no feature of creating corresponding source. I see. It means what I asked is not possible. I wasn't aware that it's a binary operation. What I want to do is to relocate the packages such as org.codehaus.plexus.util, org.apache.xerces that are shaded by maven in the official build. As you know, these should be shaded, else these classes will conflict with a different version of the same class that a project would be using. Because of the approach we are taking, we can't invoke maven-shade-plugin and get the job done. I think I'll have to manually patch the maven sources to get the said functionality. Have to proceed on this track if there's no other way. Can you please let me know the changes required to get this done? Thanks, --Kasun If you just want the original source, the plugin doesn't get into that business either, that would be a whole 'nother plugin. On Sun, Jul 3, 2011 at 6:39 AM, Kasun Gajasinghe kasu...@gmail.com wrote: Hi, Is it possible to have the .java source files which got shaded by maven-shade-plugin? Currently, it generates the uberjar without leaving the shaded sources files. There's obviously an intermediary step in which these source files will be transformed to shaded java packages like hidden.org.codehaus.plexus.util.*. So, like to know whether it's possible to have those .java files. Any complications involved? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: svn commit: r1142512 - in /maven/plugins/trunk/maven-plugins: pom.xml src/site-docs/apt/index.apt
On 3 July 2011 23:29, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jul 3 22:29:37 2011
New Revision: 1142512
URL: http://svn.apache.org/viewvc?rev=1142512view=rev
Log:
[MPOM-21] added run-its profile with common maven-invoker-plugin setup
Modified:
maven/plugins/trunk/maven-plugins/pom.xml
maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
Modified: maven/plugins/trunk/maven-plugins/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugins/pom.xml?rev=1142512r1=1142511r2=1142512view=diff
==
--- maven/plugins/trunk/maven-plugins/pom.xml (original)
+++ maven/plugins/trunk/maven-plugins/pom.xml Sun Jul 3 22:29:37 2011
@@ -252,6 +252,38 @@ under the License.
/build
/profile
profile
+ idrun-its/id
+ build
+ plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-invoker-plugin/artifactId
+ configuration
+ debugtrue/debug
+ projectsDirectorysrc/it/projectsDirectory
+
cloneProjectsTo${project.build.directory}/it/cloneProjectsTo
+ preBuildHookScriptsetup/preBuildHookScript
+ postBuildHookScriptverify/postBuildHookScript
+
localRepositoryPath${project.build.directory}/local-repo/localRepositoryPath
+ settingsFilesrc/it/settings.xml/settingsFile
+ pomIncludes
+ pomInclude*/pom.xml/pomInclude
+ /pomIncludes
+ /configuration
+ executions
+ execution
+ idintegration-test/id
+ goals
+ goalinstall/goal
+ goalrun/goal
should be
goalintegration-test/goal
goalverify/goal
or else a failing integration test will stop the lifecycle before it
gets to post-integration test. the run goal is best for when just
testing from the cli or when you want to stop the lifecycle on
failure. in general for a parent pom we should be using the split
pair.
+ /goals
+ /execution
+ /executions
+ /plugin
+ /plugins
+ /build
+ /profile
+ profile
idmaven-3/id
activation
file
Modified: maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt?rev=1142512r1=1142511r2=1142512view=diff
==
--- maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt (original)
+++ maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt Sun Jul 3
22:29:37 2011
@@ -31,9 +31,11 @@ Maven Plugins Parent POM
This POM is the common parent of all of the Maven plugins
in the Apache Maven project.
- Every Maven plugin provide ITs (Integration Tests) to check real plugin
execution.
- Nothing is defined in this parent POM about ITs since every project has
its own requirements
- to run its ITs, but by convention, these ITs are defined by every plugin
in a run-its profile:
+The run-its Profile
+
+ This POM provides run-its profile for running Integration Tests to
check real plugin execution.
+ A default configuration for maven-invoker-plugin is defined, that
every plugin needs to enhance
+ to match its prerequisite. Then ITs are launched in every plugin with
following command:
+---
mvn -Prun-its verify
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.comwrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.comwrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers ralph.go...@dslextreme.comwrote: The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. This isn't the case. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. And, we have a concept called SLOT which is almost acts like the first level of a two level index if you are familiar with DBMS. A particular SLOT contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible with each other. So, only one jar can be installed in a particular SLOT. There can be several SLOTs, implying we can have more than one version of an artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be specific not intended for maven. These are for system use. Any application maven or not is able to benefit from these. What we are doing is using these jars under maven, so we don't have to download these again. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. To reiterate, our main usecase is supporting packagers at system level. There's a need to have a custom build for them. It's not like we blind-foldly building maven again instead of using official maven build! To answer your question; at system-level, maven should be run completely offline (even at first time!). We have mechanisms in place to take care of the deps via DEPEND in ebuilds, which I'm not going to explain. Read about Gentoo if you got spare time. It'll be interesting! :) --Kasun Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.com wrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
On 2011-07-03 00:14, Hervé BOUTEMY wrote: AFAIK, code is ok: I'm closing MSITE-560 Great, thanks! the only thing to confirm is the documentation: there is a TODO in maven-3.apt.vm that we should check carefully: I'm personnally lost on this one. I'll have a look at it. To pull off this release we must also make a first release of maven-reporting-exec, right? Since you have done most of the work on it, would you like to release it? If not I can do it. Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... - 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 4 Jul 2011 16:56, Kasun Gajasinghe kasu...@gmail.com wrote: On Mon, Jul 4, 2011 at 8:34 PM, Ralph Goers ralph.go...@dslextreme.com wrote: The question I asked was, will you be putting the slf4j, Log4j, commons-logging, and Logback into your shared library - presumably under /usr/shared. This has nothing to do with Maven, per se. Maybe I'm not clear on what you are doing but I see two possibilities: 1. You are placing all the resultant jars in a common directory, such as /usr/share/lib, where applications will use them. This won't work for the reasons below. This isn't the case. 2. You are building all these projects as independent entities under /usr/share. If this is the case then it sounds like you are (sort of) duplicating the Maven repository and I have no idea why this is of benefit to anyone, especially since you will only support a single version of an artifact. Almost true. For example, slf4j jar is under /usr/share/slf4j/lib/slf4j.jar. And, we have a concept called SLOT which is almost acts like the first level of a two level index if you are familiar with DBMS. A particular SLOT contains a set of versions (ex. 1.1, 1.12, 1.2 etc.) which are compatible with each other. So, only one jar can be installed in a particular SLOT. There can be several SLOTs, implying we can have more than one version of an artifact. ex. jarjar new version is in SLOT 1, i.e. /usr/share/jarjar-1/ And, these jars in /usr/share/*/lib/*.jar are not only for maven. To be specific not intended for maven. These are for system use. Any application maven or not is able to benefit from these. What we are doing is using these jars under maven, so we don't have to download these again. I could understand this if you are building applications end users can use that are written in Java, but in that case I'd wonder why you don't just use out-of-the-box Maven and either a) just download the dependencies from the central repo or b) build the dependencies from their source and deploy them to your local repository. Of course, with the second option you would have to build several versions of the dependencies. To reiterate, our main usecase is supporting packagers at system level. There's a need to have a custom build for them. It's not like we blind-foldly building maven again instead of using official maven build! To answer your question; at system-level, maven should be run completely offline (even at first time!). We have mechanisms in place to take care of the deps via DEPEND in ebuilds, which I'm not going to explain. Read about Gentoo if you got spare time. It'll be interesting! :) --Kasun Ralph On Jul 4, 2011, at 6:11 AM, Kasun Gajasinghe wrote: On Mon, Jul 4, 2011 at 11:31 AM, Ralph Goers ralph.go...@dslextreme.com wrote: The point I am making is that if you have all those jars together something is not going to work correctly. SLF4J only allows one logging implementation. If you have all of SLF4J's jars, including the binding for Log4j as well as Logback, then SLF4J will throw a runtime exception. Commons Logging also has quirks. If Log4j is present then it will be used by default, otherwise it will do something else. When you start dumping a whole bunch of jars together in one directory you had better understand how they are all going to relate to each other. I don't get it. log4j and logback won't be included in gentoo's uber-jar since they aren't dependencies of apache-maven [1]. commons-logging and slf4j will be integrated since they are integrated in the upstream official build as well. What makes you think that I'm bundling together all the available logging implementations? Is there a need to? [1] http://maven.apache.org/ref/2.2.1/apache-maven/dependencies.html Regards, --Kasun - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
Re: [maven-shade-plugin] Factor Out ResourceMerger ...?
On Mon, Jul 4, 2011 at 2:39 AM, Daniel Kulp dk...@apache.org wrote: On Sunday, July 03, 2011 7:19:36 PM Benson Margulies wrote: So, I'm a mostly a monkey here, but it seems very sensible to me. Perhaps Dan Kulp would chime in? It sounds reasonable to me. I know I copied one of the transforms into CXF at one point to make some small modifications. If it could have been accomplished as a subclass of some sort, that may have been avoidable. ApacheNoticeResourceTransfomer currently builds it's contents within the class. I was wondering whether something involving velocity templating (say) would allow improved customisation by projects. Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Hello, 2011/7/4 Dennis Lundberg denn...@apache.org: On 2011-07-03 00:14, Hervé BOUTEMY wrote: AFAIK, code is ok: I'm closing MSITE-560 Great, thanks! the only thing to confirm is the documentation: there is a TODO in maven-3.apt.vm that we should check carefully: I'm personnally lost on this one. I'll have a look at it. To pull off this release we must also make a first release of maven-reporting-exec, right? Since you have done most of the work on it, would you like to release it? If not I can do it. So it looks Hervé just nominate myself as volunteer while chating on irc :-). I will release this component. Regards, Hervé Le samedi 2 juillet 2011, Dennis Lundberg a écrit : Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Ralph On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... Robert - 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: r1142512 - in /maven/plugins/trunk/maven-plugins: pom.xml src/site-docs/apt/index.apt
done
thanks for your review
Regards,
Hervé
Le lundi 4 juillet 2011, Stephen Connolly a écrit :
On 3 July 2011 23:29, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jul 3 22:29:37 2011
New Revision: 1142512
URL: http://svn.apache.org/viewvc?rev=1142512view=rev
Log:
[MPOM-21] added run-its profile with common maven-invoker-plugin setup
Modified:
maven/plugins/trunk/maven-plugins/pom.xml
maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
Modified: maven/plugins/trunk/maven-plugins/pom.xml
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugins/pom.xml?r
ev=1142512r1=1142511r2=1142512view=diff
== --- maven/plugins/trunk/maven-plugins/pom.xml (original)
+++ maven/plugins/trunk/maven-plugins/pom.xml Sun Jul 3 22:29:37 2011
@@ -252,6 +252,38 @@ under the License.
/build
/profile
profile
+ idrun-its/id
+ build
+plugins
+ plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-invoker-plugin/artifactId
+configuration
+ debugtrue/debug
+ projectsDirectorysrc/it/projectsDirectory
+
cloneProjectsTo${project.build.directory}/it/cloneProjectsTo +
preBuildHookScriptsetup/preBuildHookScript
+ postBuildHookScriptverify/postBuildHookScript
+
localRepositoryPath${project.build.directory}/local-repo/localReposi
toryPath + settingsFilesrc/it/settings.xml/settingsFile
+ pomIncludes
+pomInclude*/pom.xml/pomInclude
+ /pomIncludes
+/configuration
+executions
+ execution
+idintegration-test/id
+goals
+ goalinstall/goal
+ goalrun/goal
should be
goalintegration-test/goal
goalverify/goal
or else a failing integration test will stop the lifecycle before it
gets to post-integration test. the run goal is best for when just
testing from the cli or when you want to stop the lifecycle on
failure. in general for a parent pom we should be using the split
pair.
+/goals
+ /execution
+/executions
+ /plugin
+/plugins
+ /build
+/profile
+profile
idmaven-3/id
activation
file
Modified: maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
URL:
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-plugins/src/site-
docs/apt/index.apt?rev=1142512r1=1142511r2=1142512view=diff
== --- maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt
(original) +++
maven/plugins/trunk/maven-plugins/src/site-docs/apt/index.apt Sun Jul 3
22:29:37 2011 @@ -31,9 +31,11 @@ Maven Plugins Parent POM
This POM is the common parent of all of the Maven plugins
in the Apache Maven project.
-Every Maven plugin provide ITs (Integration Tests) to check real
plugin execution. -Nothing is defined in this parent POM about ITs
since every project has its own requirements -to run its ITs, but by
convention, these ITs are defined by every plugin in a run-its
profile: +The run-its Profile
+
+This POM provides run-its profile for running Integration
Tests to check real plugin execution. +A default configuration for
maven-invoker-plugin is defined, that every plugin needs to
enhance +to match its prerequisite. Then ITs are launched in every
plugin with following command:
+---
mvn -Prun-its verify
-
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: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
Ralph Goers wrote: From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Actually not every Gentoo user would ever install a Gentoo-built Maven. At least not me ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
How to replace an old MavenEmbedder?
Hi I'm trying to replace an old version 2.0 MavenEmbedder in the aspectj-maven-plugin, over at mojo@codehaus. That's because we can't upgrade other Maven core dependencies while the embedder is being used. In a class that extends AbstractMojoTestCase we have this code: MavenEmbedder embedder = new MavenEmbedder(); embedder.setClassLoader( Thread.currentThread().getContextClassLoader() ); embedder.setLogger( new MavenEmbedderConsoleLogger() ); embedder.start(); ArtifactRepository localRepository = embedder.getLocalRepository(); Now the only thing the embedder is used for is to create the localRepository variable. There must be a better way to do this, but I can't find out how. Does anyone have an idea they can share? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to replace an old MavenEmbedder?
Settings.getLocalRepository()?
Alternatively filter a test resource and have
${settings.localRepository} as the filtered value
On 4 July 2011 23:11, Dennis Lundberg denn...@apache.org wrote:
Hi
I'm trying to replace an old version 2.0 MavenEmbedder in the
aspectj-maven-plugin, over at mojo@codehaus. That's because we can't
upgrade other Maven core dependencies while the embedder is being used.
In a class that extends AbstractMojoTestCase we have this code:
MavenEmbedder embedder = new MavenEmbedder();
embedder.setClassLoader(
Thread.currentThread().getContextClassLoader() );
embedder.setLogger( new MavenEmbedderConsoleLogger() );
embedder.start();
ArtifactRepository localRepository = embedder.getLocalRepository();
Now the only thing the embedder is used for is to create the
localRepository variable. There must be a better way to do this, but I
can't find out how. Does anyone have an idea they can share?
--
Dennis Lundberg
-
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: How to replace an old MavenEmbedder?
On 2011-07-05 00:22, Stephen Connolly wrote:
Settings.getLocalRepository()?
Alternatively filter a test resource and have
${settings.localRepository} as the filtered value
Well, I really need an ArtifactRepository object, not just the path to
the local repository. I suppose this can be looked up by Plexus somehow.
On 4 July 2011 23:11, Dennis Lundberg denn...@apache.org wrote:
Hi
I'm trying to replace an old version 2.0 MavenEmbedder in the
aspectj-maven-plugin, over at mojo@codehaus. That's because we can't
upgrade other Maven core dependencies while the embedder is being used.
In a class that extends AbstractMojoTestCase we have this code:
MavenEmbedder embedder = new MavenEmbedder();
embedder.setClassLoader(
Thread.currentThread().getContextClassLoader() );
embedder.setLogger( new MavenEmbedderConsoleLogger() );
embedder.start();
ArtifactRepository localRepository = embedder.getLocalRepository();
Now the only thing the embedder is used for is to create the
localRepository variable. There must be a better way to do this, but I
can't find out how. Does anyone have an idea they can share?
--
Dennis Lundberg
-
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
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to replace an old MavenEmbedder?
On Mon, Jul 4, 2011 at 6:11 PM, Dennis Lundberg denn...@apache.org wrote: Hi I'm trying to replace an old version 2.0 MavenEmbedder in the aspectj-maven-plugin, over at mojo@codehaus. That's because we can't upgrade other Maven core dependencies while the embedder is being used. In a class that extends AbstractMojoTestCase we have this code: Start at git://git.eclipse.org/gitroot/m2e/m2e-core.git. Then look in org.eclipse.m2e.core. To see how the new m2e code does this stuff. MavenEmbedder embedder = new MavenEmbedder(); embedder.setClassLoader( Thread.currentThread().getContextClassLoader() ); embedder.setLogger( new MavenEmbedderConsoleLogger() ); embedder.start(); ArtifactRepository localRepository = embedder.getLocalRepository(); Now the only thing the embedder is used for is to create the localRepository variable. There must be a better way to do this, but I can't find out how. Does anyone have an idea they can share? -- Dennis Lundberg - 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: [Gentoo-maven-intg] Intermediary shaded source files generated by maven-shade-plugin
On Tue, Jul 5, 2011 at 1:57 AM, Ralph Goers ralph.go...@dslextreme.comwrote: From Kasun's answers it is quite clear to me that we will need to add something to Jira where it asks for the operating system for all the Java projects I work on at the ASF. If the O.S. is Gentoo then we will have to reject any issues coming from the stuff that comes as part of the O.S. as it can't be trusted. Binary official build also available in Gentoo already. On Jul 4, 2011, at 11:48 AM, Robert Burrell Donkin wrote: On Mon, Jul 4, 2011 at 7:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: look, what you are trying to do is move an object of infinite mass, keeping the lever length and force applied finite. good luck, it will be fun for us watching from the sidelines... fundamentally maven is about downloading dependencies on demand from the network rather than building from source... gentoo is about building from source rather than downloading binaries from the network... (as a gentoo user myself...) The bytecode languages don't fit well into the Gentoo model. Even though bytecode is an intermediary source form compiled from source, Gentoo tries to treat it as a platform dependent binary. The Java team then fights a losing battle to cobble together enough accurate builds for the library chain to get anything useful to work. Even then, because the source bytecode doesn't necessarily match the official release, strange issue keep cropping up. After many problems, I've now opted to uninstall the official Maven and Ant packages (and Eclipse...), and use instead a set of scripts which accurately and flexibly allow me to configure exactly the official bytecode I want to use (a little bit like a better eselect). By official did you meant the upstream packages available as binary like maven-bin? If that's the case, these -bins are the same as upstream build. I guess you meant that since there's only the binary maven is available now. What did you find wrong? It has always struck me as somewhat ironic that if the Gentoo team donned their clue-hats and treated bytecode as the source form then they might quickly have one of the best development environments for the bytecode languages... I too kind of agree to this since the point being the built jars are platform independent. If anybody like to know the points for it - http://www.gentoo.org/proj/en/java/why-build-from-source.xml I'm not going to discuss why building from source is good or bad any further and is off-topic! ;) Regards, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa, Sri Lanka. Blog: http://blog.kasunbg.org Twitter: http://twitter.com/kasunbg
