Only deploying dependencies instead of the whole pom
Hey, Someone told me that in recent versions of Maven, it is possible to publish a pom that only includes dependencies (basically strip all the information about plugin configuration). What is the configuration to achieve that? Thanks, Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Only deploying dependencies instead of the whole pom
My question that was not really clear. Let's say that I have a multi module build that produces a number of jars. The pom.xml for these modules use a number of specific plug-ins which are necessary for my build to produce the appropriate jars. From the point of view of the consumers of my jars, these plugins and configurations are details that he/she should not see. So the question is, how would I go to produce a pom.xml that does not include all the plugins configuration for each jar ? On 06/09/2015 01:07 PM, Anders Hammar wrote: An artifact with a packaging of pom. And that was possible in Maven 2 as well. /Anders On Tue, Jun 9, 2015 at 6:52 PM, Pascal Rapicault pas...@rapicault.net wrote: Hey, Someone told me that in recent versions of Maven, it is possible to publish a pom that only includes dependencies (basically strip all the information about plugin configuration). What is the configuration to achieve that? Thanks, Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Only deploying dependencies instead of the whole pom
Yes! Thanks :) On 06/09/2015 01:38 PM, Vincent Latombe wrote: I think http://www.mojohaus.org/flatten-maven-plugin/ should help Vincent 2015-06-09 19:27 GMT+02:00 Pascal Rapicault pas...@rapicault.net: My question that was not really clear. Let's say that I have a multi module build that produces a number of jars. The pom.xml for these modules use a number of specific plug-ins which are necessary for my build to produce the appropriate jars. From the point of view of the consumers of my jars, these plugins and configurations are details that he/she should not see. So the question is, how would I go to produce a pom.xml that does not include all the plugins configuration for each jar ? On 06/09/2015 01:07 PM, Anders Hammar wrote: An artifact with a packaging of pom. And that was possible in Maven 2 as well. /Anders On Tue, Jun 9, 2015 at 6:52 PM, Pascal Rapicault pas...@rapicault.net wrote: Hey, Someone told me that in recent versions of Maven, it is possible to publish a pom that only includes dependencies (basically strip all the information about plugin configuration). What is the configuration to achieve that? Thanks, Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Use of Multiple Local Repositories
You can take a look at https://github.com/takari/tesla-split-localrepo I remember seeing a demo of this, but I don't know if it is working with recent versions of Maven / Aether HTH On 06/04/2015 04:30 AM, Mehdi Hayani wrote: Hello, I'm actually working on a continuous integration platform, and most of the projects are using Maven as a build tool. We've found that there is a list of dependencies and plugins most of the projects have to download in addition of there specific dependencies. Therefore, I though it could be great if we can use multiple local reposiry for a build, the idea is: - Local repo 1 : Is the shared folder where we will put dependencies that are download by each project. - Local repo 2 : this one is created for each project and it will contains dependencies that are specific to that project. So while running the build, maven will check in local repo 1, if it can't find the required librairy it will download it and put it in local repo 2 It there a way to implement this solution :) ? Thanks in advance - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Kepler m2eclipse plugin?
http://download.eclipse.org/releases/kepler On 05/01/2015 07:10 AM, Martin Gainty wrote: anyone know where I can download m2eclipse or m2e or m2e-wtp plugin for Eclipse Kepler? Thanks! Martin __ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Build extension not found when specifying different local repository
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T12:29:23-05:00) On 03/07/2015 02:44 AM, Jeff MAURY wrote: Which version of Maven are you using ? Jeff On Sat, Mar 7, 2015 at 12:53 AM, Pascal Rapicault pas...@rapicault.net wrote: Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven-plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Build extension not found when specifying different local repository
Hi, I'm trying to do a set of builds where I'm trying to make sure I'm not getting extraneous artifacts. The first step of the build consists in building Tycho (a set of maven plugins for building OSGi / Eclipse things) and to ensure I get clean artifacts, I deleted the ~/.m2 folder and now I use the -Dmaven.repo.local parameter (I know I should not need the two but nonetheless...). The build completes and I'm happy. Now when I try to build my real project, which uses the freshly built maven plugin, here again specifying the -Dmaven.repo.local parameter, I get an error saying that Maven can't find the build extension (see error below). I tried many workarounds but none of them are working. Is this expected? Do you have any idea on how to avoid this? Thx. Unresolveable build extension: Plugin org.eclipse.tycho:tycho-maven-plugin:0.23.0-SNAPSHOT or one of its dependencies could not be resolved: Failure to find org.eclipse.tycho:tycho-maven-plugin:jar:0.23.0-SNAPSHOT in https://oss.sonatype.org/content/repositories/public/ was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced - [Help 2] Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Complex Maven projects - Tutorials? Books?
If you are really aiming at doing continuous delivery (any potential build can be pushed to prod), then SNAPSHOT is not a great way to deal with dependencies since you will not be able to exactly know what you ship. To avoid this, one practice is to use the build number in the artifact version (1.0.0-b1 or 1.0.1). This has of course had the drawback that now you have to update the pom.xml of components using a specific artifact (move from build 1 to 2) but this also gives you greater control on the rate at which you consume libraries. You may be interested in these articles: - http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-td3245370.html - http://stackoverflow.com/questions/18456111/what-is-the-maven-way-for-project-versions-when-doing-continuous-delivery That said, if you add Artifactory to the mix, you can leverage its capabilities of obtaining specific versions of a SNAPSHOT through matrix parameters (https://www.jfrog.com/confluence/display/RTF/Using+Properties+in+Deployment+and+Resolution) quite handy. One example where this comes handy is when you split your build process over multiple jenkins jobs and you want to make sure that you use the same artifact throughout the process and this w/o blocking the whole pipeline for the whole duration of the process. HTH Pascal On 12/06/2014 10:46 AM, Hohl, Gerrit wrote: Hello everyone, :) I have a question which is not about a specific problem with Maven, but more a general question. I hope it is okay to ask this question here. We use Maven and Jenkins for about 1.5 years now, I guess. Until now the Maven projects have been very simple and - let's say - very monolithic. But recently we identify more and more internal libraries in our products. Of course we don't want to share this libraries by copy-n-paste between the products - especially as we have Maven. So we started to read books, tutorials on the Internet and so on. But most of them only deal with simple projects. They don't cover e.g. versioning the build process (especially if your build process consists of more than just one step). They also don't cover the problems of developing the libraries while your developing the products which depend on them. Especially at the beginning your libraries will go through a lot of changes. A few name snapshots as a solution, but don't explain how you can work using them, how you can use them in your pom.xml and how you deal with them if you finally switch your product and/or your library from the snapshot state to the release state. A few also say that you shouldn't use snapshots at all because it will result in many problems (e.g. having -SNAPSHOT entries in your pom.xml). Nightly builds or build triggered by the SCM are also an issue here. Does someone know a good book or tutorial which handles all of these issues around Maven and CI/CD in more depth? Regards, Gerrit - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven on a Terminal Server
I'm currently doing work for Ericsson where we have a similar setup (Terminal Server on windows and AFS on *nix). The difficulty in this setup is not network access but limited user storage so the goal is to try to share as much as possible among the users. This was such a concern for Ericsson that they built extensions to Eclipse to make sure that users would not have copies of the plugins they install in their user folder but would run them from a shared location. Now to go back to Maven I can see how the desire to share artifacts applies since I've had the same discussion last week :). Basically the local maven repo is made of 3 things: - released versions of non-corporate artifacts (e.g. content from central, jboss, etc.) - released versions of corporate artifacts - snapshots versions of corporate artifacts (yes there is snapshot of non corporate but I think they represent a minority) Using this as a starting point, I think it would be possible to address this in a clean way the problem if we were to make the local maven repository a bit smarter (i.e. code change :)) . For example I think a solution that could work is to have a read only shared cache that only contains the released artifacts and have that chained to the local maven repository. This way when an artifact is looked up, it is first looked up in the local cache, then in the shared cache, and if it is not availble, then it is downloaded and stored into the local cache (note that this solution of chained maven repo could also be used to isolate snapshot from released artifacts) Since the shared cache is read only, its population could be done by doing a dump of the repo manager content into the shared folder at regular interval. Pascal On 2012-09-28, at 4:58 AM, Barrie Treloar wrote: On Fri, Sep 28, 2012 at 1:15 PM, Brett Porter br...@apache.org wrote: Hi Terry, On 28/09/2012, at 9:41 AM, Sposato, Terry terry.spos...@team.telstra.com wrote: Hi, We currently use Nexus as our project’s local repository server which works well. We also have a Terminal server which offshore developers access to do their development/testing/building etc. I want to know if there is a way of having all these users access the same .m2 local repository which maven3 is using in a safe way? I have currently set the path in settings.xml to use a local path, which at a high level works, I am just not sure if this will cause issues moving forward? Please reply all as I am currently not subscribed to the list. Sharing the local repository is not advised. There's no external locking on files written there. Given you have a repository manager, as long as you have one geographically close to that terminal server (or on the machine), you typically give each user a local repository and are free to clean it out frequently if needed. And for other non-Maven security reasons, you would want to have each person have a separate account on your terminal server anyway. So shared accounts aren't advised are generally considered a bad thing(tm) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
catch block like behavior
Hi, I would like to know if there is a way to have a plugin be executed right at the end of the build no matter what. The situation I have is as follow. Early on in the build I rename a file from a.txt.off to a.txt and at the end I rename it back such that no problems are being caused for subsequent builds. This works great when the module build is executed in its entirety, however when it fails part way through, then the file is not renamed and subsequent build fails. Therefore my question, is there a way to enforce the execution of a plugin no matter what. Thx Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: catch block like behavior
I'm well aware that this is not a great practice but this is the only pragmatic solution to trick the desired mojos into doing what I want. Using bash scripts would end up being worst since then I would have to have such a script into every level where the build can be fired from. Anyway, thanks for your insights. Pascal On 2012-08-23, at 11:42 AM, John Kramer wrote: Am 23.08.2012 14:56, schrieb Pascal Rapicault: Hi, I would like to know if there is a way to have a plugin be executed right at the end of the build no matter what. The situation I have is as follow. Early on in the build I rename a file from a.txt.off to a.txt and at the end I rename it back such that no problems are being caused for subsequent builds. This works great when the module build is executed in its entirety, however when it fails part way through, then the file is not renamed and subsequent build fails. Therefore my question, is there a way to enforce the execution of a plugin no matter what. Hi, ensure that you REALLY want to change files in your src folder during maven build. This looks like a bad practice. Always do things in the target folder. It is there to provide clean builds. I concur. If you ABSOLUTELY need to modify something in your src folder, DON'T DO IT AS PART OF A MAVEN BUILD. That violates the pattern that maven uses. Instead, think about doing it as part of a larger process (i.e. do it as part of a bash script, or something else). Or better yet, work in your target folder. John Kramer email: jkra...@mojiva.com mobile: 314.435.2370 twitter: @KramerKnowsTech https://twitter.com/KramerKnowsTech 0xCAFEBABE0032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: catch block like behavior
Sadly not and requesting a fix from this particular vendor will take time that I don't have before shipping. It almost sound easier to me to add the feature in maven :) Oh well, next time :) On 2012-08-23, at 12:09 PM, Wayne Fay wrote: I'm well aware that this is not a great practice but this is the only pragmatic solution to trick the desired mojos into doing what I want. Using bash scripts would end up being worst since then I would have to have such a script into every level where the build can be fired from. Are those plugins open source so that instead of tricking anything, you could just change the code to suit your needs? And make it configurable, donate the code back, etc? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: catch block like behavior
Thx. On 2012-08-23, at 12:49 PM, Hilco Wijbenga wrote: On 23 August 2012 05:56, Pascal Rapicault pas...@rapicault.net wrote: I would like to know if there is a way to have a plugin be executed right at the end of the build no matter what. The situation I have is as follow. Early on in the build I rename a file from a.txt.off to a.txt and at the end I rename it back such that no problems are being caused for subsequent builds. This works great when the module build is executed in its entirety, however when it fails part way through, then the file is not renamed and subsequent build fails. Therefore my question, is there a way to enforce the execution of a plugin no matter what. More than likely, you can do what you want (or at least something similar) using a Maven extension. See [1] (there isn't much documentation but I managed to figure it out so I'm sure you can too. :-) ). Just hook into the org.apache.maven.execution.ExecutionListener. [1] http://maven.apache.org/examples/maven-3-lifecycle-extensions.html. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: write maven plugin that operate Sonar
did you try mvn sonar:sonar On 2012-07-19, at 10:56 AM, dror wrote: Hi all, Somebody knows how can i write a maven plugin in pom.xml that operate Sonar? i looking for a way to operate Sonar's checks via maven build. Thanks, Dror. -- View this message in context: http://maven.40175.n5.nabble.com/write-maven-plugin-that-operate-Sonar-tp5714457.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Inspector for Eclipse
As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Inspector for Eclipse
Hello Anthony Thanks for your feedback. To answer your question in full disclosure. I'm an m2e committer. However I'm doing this to promote myself and my consulting services, therefore merging it back into m2e at this point would do me a disservice. Pascal On 2012-07-13, at 5:40 PM, Anthony Dahanne wrote: Hello Pascal, Thanks for contributiong this plugin, this is a very good idea, and will save users a lot of time debugging maven builds. One remark though : * do you think it would be possible to contribute this view directly into m2e ? did you contact m2e team ? I mean, that would ease adoption of the plugin, and it seems to me that it would be useful for all m2e users. Thanks again Pascal, Anthony On Fri, Jul 13, 2012 at 11:06 AM, Pascal Rapicault pas...@rapicault.net wrote: As much as Maven makes it easy to deal with builds, the plethora of XML and the varying life cycles phases can sometimes make it hard to figure out what a build will actually do. To help with this, I'm happy to make available the Eclipse plugin called the Maven Inspector. This plugin provides a simple View called Maven Execution that presents for a given POM file the phases and associated MOJOs. Go check it out on http://prapicault.github.com/MavenInspector/ or directly install it from http://prapicault.github.com/MavenInspector/repository Hope you'll find this useful. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for Software Installation
The approach you are describing is akin to what the Eclipse provisioning platform (aka p2) provides with its concept of bundle pool (equivalent of GAC). From experience, while this works in practice (for example a commercial distro of Eclipse called Yoxos ships like this (I'm not affiliated with them)), depending on the sort of applications you are delivering, it happens that consumers like being able to have access to an all-in-one download for ease of consumption and avoid uncertainties at install time. After all it is much easier for someone to validate the checksum of a zip rather than the proper behaviour of an installer. The other thing to consider in this space is the ever growing size of the cache. While in Maven this is quite easily handled by just deleting the .m2 folder, this approach would not work for such a cache, and then requires some GC to be put in place. All in all I think it is definitely a space to look into where the simplicity of expressing dependencies and metadata with maven coupled to the runtime characteristics of p2 (thread safe local repo, transactional install, GC) could really allow to put together a solution quite rapidly. On 2012-06-21, at 3:53 PM, Eric Kolotyluk wrote: I have brought this notion up before, but I have been thinking about it a bit more. Would it make sense to use Maven technology for software deployment and installation as opposed to just builds? What I envision is something akin to the Global Assembly Cache in .NET, but for Maven artifacts. In particular, the local repository would act like a GAC, but you might want to separate a system local repository from the user local repositories. The basic idea is that when deploying/installing software you would not bundle all your dependent artifact into your installer, rather you would just bundle their coordinates. At installation time you would install the Maven Installer if it was not already there, then your installer would work in conjunction with the Maven Installer. Basically the Maven Installer subsystem would simply download the dependent artifacts from Maven Central or elsewhere, and put them in the System Repository (similar to the GAC). One benefit of this is that if you have a lot of software that all reference the same artifacts, they can share copies. Other benefits would be similar to those for the .NET GAC, although hopefully we could avoid some of the problems the GAC has created. Another benefit is that installers could be smaller by not bundling in dependent artifacts. Installation could be faster in that if dependent artifacts are already in the System Repository downloading and installing them is unnecessary. So am I just thinking crazy, or is there any potential benefit to this idea? Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: list of phases defined by the lifecycle of a packaging type
Thx
On 2012-06-11, at 1:15 AM, Milos Kleint wrote:
public ListString getLifecyclePhases() {
LifecycleMapping lifecycleMapping =
lookupComponent(LifecycleMapping.class);
if (lifecycleMapping != null) {
SetString phases = new TreeSetString();
MapString, Lifecycle lifecycles =
lifecycleMapping.getLifecycles();
for (Lifecycle lifecycle : lifecycles.values()) {
phases.addAll(lifecycle.getPhases().keySet());
}
return new ArrayListString(phases);
}
return Collections.StringemptyList();
}
is what we use for certain code completions in netbeans..
Milos
On Sun, Jun 10, 2012 at 9:48 PM, Pascal Rapicault pas...@rapicault.net
wrote:
Hi,
Given a packaging type, is there a way to programmatically know all the
phases that are associated with the various lifecycle?
For example during the execution with -X I see the following output. This is
pretty much what I want.
[DEBUG] Lifecycle clean - [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy]
[DEBUG] Lifecycle default - [validate, initialize, generate-sources,
process-sources, generate-resources, process-resources, compile,
process-classes, generate-test-sources, process-test-sources,
generate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy]
Thx in advance,
Pascal
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Hooking before and after a phase
Thx On 2012-06-09, at 11:06 AM, Aliaksei Lahachou wrote: Hi, this is tricky and may involve some trial and error. Maven executes mojos in the same phase in the order their plugins are listed in the POM. You can try to define all plugins, including plugins automatically defined by the eclipse-plugin lifecycle, in the required order. The relative order is maintained even when plugins are merged from parents and profiles. I don't remember now exactly the whole algorithm, but I hope this can help you. Also, this behavior may change in future. Regards, htfv (Aliaksei Lahachou) On Fri, Jun 8, 2012 at 11:25 PM, Pascal Rapicault pas...@rapicault.netwrote: Hi, I have a situation where I need to execute a mojo just before the execution of the mojo bound to the phase. Is there a way to achieve this without binding my mojo to the previous phase but to the phase that I'm interested in? For example, the eclipse-plugin packaging type has the following phases: - […] - process-test-resources - package (which itself executes 2 mojos) - […] I would like to execute a mojo just before the first mojo of the package phase is executed, or even better in between the execution of the two mojos executed by the package phase. I could hook my mojo to the process-test-resources but I feel that this is incorrect since the execution of my mojo should only happen if the package phase does, otherwise it may screw up following builds. Thanks. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Questions about property resolution
It could mostly likely be specified on the command line.
On 2012-06-11, at 9:44 AM, Cédric Teyton wrote:
Hello,
I've a question with respect to some POM.xml files i've observed recently. In
some cases like the following one :
project
modelVersion4.0.0/modelVersion
groupIdactivemq-web/groupId
artifactIdactivemq-web/artifactId
nameActiveMQ :: Web/name
version4.0-M2/version
descriptionWeb Connector for REST API and Streamlets support/description
dependencies
...
dependency
groupIdspringframework/groupId
artifactIdspring/artifactId
version${spring_version}/version
/dependency
...
/dependencies
/project
I just don't figure out how the variable /${spring_version}/ can be matched
to something.
Indeed, there's no property specified in this POM, and there is also no
parent.
Have you an idea about how this property can find an actual value ?
Thanks a lot,
Cheers
Cédric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
list of phases defined by the lifecycle of a packaging type
Hi, Given a packaging type, is there a way to programmatically know all the phases that are associated with the various lifecycle? For example during the execution with -X I see the following output. This is pretty much what I want. [DEBUG] Lifecycle clean - [pre-clean, clean, post-clean] [DEBUG] Lifecycle site - [pre-site, site, post-site, site-deploy] [DEBUG] Lifecycle default - [validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy] Thx in advance, Pascal
Hooking before and after a phase
Hi, I have a situation where I need to execute a mojo just before the execution of the mojo bound to the phase. Is there a way to achieve this without binding my mojo to the previous phase but to the phase that I'm interested in? For example, the eclipse-plugin packaging type has the following phases: - […] - process-test-resources - package (which itself executes 2 mojos) - […] I would like to execute a mojo just before the first mojo of the package phase is executed, or even better in between the execution of the two mojos executed by the package phase. I could hook my mojo to the process-test-resources but I feel that this is incorrect since the execution of my mojo should only happen if the package phase does, otherwise it may screw up following builds. Thanks. Pascal - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
