Re: maven-antrun-plugin
yes i can see it in build log but i can't intervene after checking dependencies, ant script runs before creating war file. any suggestions ? thanks in advance -- View this message in context: http://maven.40175.n5.nabble.com/maven-antrun-plugin-tp3236582p3238246.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
Re: maven-antrun-plugin
The antrun-plugin execution must be bound to the wrong phase then. /Anders On Wed, Oct 27, 2010 at 09:01, paladine yasinma...@yahoo.com wrote: yes i can see it in build log but i can't intervene after checking dependencies, ant script runs before creating war file. any suggestions ? thanks in advance -- View this message in context: http://maven.40175.n5.nabble.com/maven-antrun-plugin-tp3236582p3238246.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
Re: maven-antrun-plugin
paladine wrote: yes i can see it in build log but i can't intervene after checking dependencies, ant script runs before creating war file. any suggestions ? Can you hava look at help:effective-pom? Maybe you inherit another executionfrom your parent. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven 3 snapshot resolving
We use Nexus as our repository manager and publish all artifacts (snapshot and release) through one url. This was a suggested setup to solve a Maven 2.2.1 resolve behavior (I can't remember what exactly, so off the top of my head). We have switched to Maven 3 and the following behavior occurs: a new snapshot of an entity is uploaded to Maven, but the using project keeps downloading the old version. It turned out that in Nexus there were two snapshots: - one with a date-time in the name (put there by Maven 3) - one without a date-time in the name (put there previously by Maven 2) Maven 3 seems to keep resolving to the old version. So I deleted the whole folder and rebuild it, now there only is a snapshot with date-time in the name: /[ERROR] Failed to execute goal on project CheyenneWebProject: Could not resolve dependencies for project nl.innovationinvestments:CheyenneWebProject:pom:1.0-SNAPSHOT: Could not find artifact nl.innovationinvestments:CheyenneServlet:jar:1.11-SNAPSHOT in kp (http://alaya.applicationplaza.com:8081/nexus/content/groups/pub lic) - [Help 1] / The artifact nl.innovationinvestments:CheyenneServlet:jar:1.11-SNAPSHOT indeed is not in the repository, it's called nl.innovationinvestments:CheyenneServlet:jar:1.11-20101027.120857.4 and Maven 3 does not find it? Switching back to Maven 2.2.1 for now. Tom
Re: profile activation confusion
On 27/10/2010 1:51 AM, Anders Hammar wrote: While on the topic, I'd like to mention that having a different build (through profiles for example) for each environment is not good. In Maven, there can only be one flavor of a released artifact. So if you build v1.0 of your war, cannot rebuild it with a different content. What you should do is build different artifacts for each environment. Use classifiers or, in my opinion even better, different Maven projects. This have been discussed several times on this list about a month ago or so. And should be in the Best Practices section of the documentation so that people know that this is settled law. /Anders On Tue, Oct 26, 2010 at 23:42, Jon Paynterkittl...@gmail.com wrote: Im trying to setup some build profiles for our various build environments (dev, qa, prod, etc). but I cant get the 'dev' profile to be active. The envType property is set to a default value of 'dev' in my top level pom, but it will sometimes be given on the command line, and in that case, activate the appropiate profile for qa, or production. The problem is I cant get the dev profile to activate by just setting property values inside my pom. Fragment from my pom: properties envTypedev/envType project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding fwVersionSFP401/fwVersion /properties and then the profiles: profile iddev/id activation property nameenvType/name valuedev/value /property /activation based on the documentation I would think the dev profile would be active all the time. but when I run 'mvn help:active-profiles' I see: Active Profiles for Project 'myCompoany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) however if I run: 'mvn help:active-profiles -DenvType=dev' then I see: Active Profiles for Project 'myCompany:app:pom:2.1': The following profiles are active: - nexus (source: settings.xml) - dev (source: settings.xml) what am I missing here? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3 snapshot resolving
Tom wrote: Could not find artifact nl.innovationinvestments:CheyenneServlet:jar:1.11-SNAPSHOT in kp (http://alaya.applicationplaza.com:8081/nexus/content/groups/pub lic) Could be related to [0], i.e. a problem with the metadata that Maven requires to locate the timestamped snapshot. Either try using the system property mentioned in the wiki article to deploy legacy metadata or update/patch your Nexus instance. Benjamin [0] https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-UniqueSnapshotVersionsandClassifiers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: profile activation confusion
Anders Hammar wrote: You need Maven 3.0 to be able to activate profiles in the pom by properties set in a profile in settings.xml. The point is that this functionality is superfluous. If you want a profile be activated based on properties in settings.xml, you may as well simply add it there to your activeProfiles section. Works also for M2. - Jörg /Anders On Wed, Oct 27, 2010 at 01:44, Jörg Schaible joerg.schai...@gmx.de wrote: Jon Paynter wrote: On Tue, Oct 26, 2010 at 4:12 PM, Jörg Schaible joerg.schai...@gmx.dewrote: Hi Jon, what am I missing here? It does simply not work this way. You cannot activate a profile by a property defined in the current or parent POM. Profiles are resolved first to build the final POM in use. See help:effective-pom. - Jörg Well that explains the source of my confusion. I'll just find another way to accomplish the same thing. You can set system properties calling Maven or define properties in your settings.xml (IIRC). Those are respected for the profile activation. - 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 3 snapshot resolving
This wiki refers to Maven 2 clients having problems accessing Maven 3 artifacts. In my situation Maven 3 clients are the problem; they does not seem to find the artifacts it deployed itself. So that would not be activating legacy behavior. On 27-10-2010 14:47, Benjamin Bentmann wrote: Tom wrote: Could not find artifact nl.innovationinvestments:CheyenneServlet:jar:1.11-SNAPSHOT in kp (http://alaya.applicationplaza.com:8081/nexus/content/groups/pub lic) Could be related to [0], i.e. a problem with the metadata that Maven requires to locate the timestamped snapshot. Either try using the system property mentioned in the wiki article to deploy legacy metadata or update/patch your Nexus instance. Benjamin [0] https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-UniqueSnapshotVersionsandClassifiers - 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: Invoking a plugin programmatically using maven 3 and scala
Andreas Gies wrote: [INFO] org.scala-tools:scala-mojo-support:jar:0.3-SNAPSHOT ... [INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile ... [INFO] +- org.sonatype.spice:spice-inject-plexus:jar:1.3.4.1:compile [INFO] | \- org.sonatype.spice:spice-inject-bean:jar:1.3.4:compile [INFO] | \- org.sonatype.spice.inject:guice-patches:jar:noaop:2.1.6:compile Those are duplicates/conflicts, sisu:1.4.2 should be used. No idea whether that causes your linkage error but it definitely isn't a clean class path. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Benjamin, Benjamin Bentmann wrote: Andreas Gies wrote: [INFO] org.scala-tools:scala-mojo-support:jar:0.3-SNAPSHOT ... [INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile ... [INFO] +- org.sonatype.spice:spice-inject-plexus:jar:1.3.4.1:compile [INFO] | \- org.sonatype.spice:spice-inject-bean:jar:1.3.4:compile [INFO] | \- [org.sonatype.spice.inject:guice-patches:jar:noaop:2.1.6:compile Those are duplicates/conflicts, sisu:1.4.2 should be used. No idea whether that causes your linkage error but it definitely isn't a clean class path. Is it save now in M3 to declare a different plugin artifact as dependency? In M2 this was a no-no. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3 snapshot resolving
Tom wrote: This wiki refers to Maven 2 clients having problems From that wiki: Additionally, some repository managers [...] may not cope with the additional XML elements in the metadata file. This applies to (unpatched) Nexus versions before 1.8 where the issue manifests itself as the server not being able to serve the metadata from a group repository. And the failure to deliver this metadata prevents Maven from finding the snapshot. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3 snapshot resolving
My snapshot repositories were configured using uniqueVersionfalse/uniqueVersion. Maven 3 does not seem to respect that when releasing and releases with a date-time anyhow, but does respect it when resolving and does not find the date-time files. By modifying uniqueVersion to true, it seems to work. Further testing is required, but this matches the behavior. Tom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Jörg Schaible wrote: Is it save now in M3 to declare a different plugin artifact as dependency? You mean plugin A having a dependency on plugin B? This shouldn't cause an issue for Maven 3 when running the plugin (it should also work in recent Maven 2.x releases IIRC). That inheriting from other plugins isn't really recommended and not supported by the plugin tooling, is a different story. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3 snapshot resolving
On 27-10-2010 15:04, Tom wrote: My snapshot repositories were configured using uniqueVersionfalse/uniqueVersion. Maven 3 does not seem to respect that when releasing and releases with a date-time anyhow, but does respect it when resolving and does not find the date-time files. By modifying uniqueVersion to true, it seems to work. Further testing is required, but this matches the behavior. This seems to work, now versioned artifacts are resolved, but not versioned plugins. /[ERROR] Unresolveable build extension: Plugin nl.innovationinvestments:CheyenneMavenPlugin:1.11-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact nl.innovationinvestments:CheyenneMavenPlugin:jar:1.11-SNAPSHOT in kp (http://alaya.applicationplaza.com:8081/nexus/content/groups/public) - [Help 2] / There is a versioned plugin available in Nexus. So upgrading Nexus to 1.8 could solve this? Tom
Re: avoiding dependency version number duplication
I may be over my head here, but I think that when you do a *release* (using the release plugin), there is an option to have a version of the pom created for the tag that has the properties fully resolved. See http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html Does this address your use case? -Marshall Schor On 10/26/2010 12:05 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict pbened...@apache.org wrote: I don't believe that's supposed to happen. I realized how vague my answer was. Sorry! I mean the replacement is NOT supposed to happen. It's a substitution variable. You won't get the real value in there because it's resolved at build time. Which is a problem because there's lots of other ways for that variable to be set that aren't going to be available after the pom is deployed. This has been argued about several times, and it looks like it's not going to get fixed because the maven people have something against having a build generate an appropriate pom for deployment. Babak, if you really want to make this work right, you're probably going to have to end up with a weird multi-stage build where first you generate the pom.xml file (perhaps with another pom.xml, or an ant build) and then build using the generated one. 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: Invoking a plugin programmatically using maven 3 and scala
Benjamin Bentmann wrote: Jörg Schaible wrote: Is it save now in M3 to declare a different plugin artifact as dependency? You mean plugin A having a dependency on plugin B? This shouldn't cause an issue for Maven 3 when running the plugin (it should also work in recent Maven 2.x releases IIRC). No, it does not really work in M2, since the plugin is loaded only once and this can break your build in unexpected ways. Imagine B is the assembly plugin and A depends on version 2.1 of it that allows the id/classifier to be empty. The user however uses the assembly plugin in the latest version 2.2. If at build time version 2.1 is active, the project may fail simply because that version cannot read the latest assemblies. If at build time version 2.2 is active, it will fail because of empty id/classifier. M3 was supposed to use separate classloaders for its plugins. In that case A would use assembly plugin version 2.1 while the build itself would use 2.2. Does this work now? That inheriting from other plugins isn't really recommended and not supported by the plugin tooling, is a different story. Until now (M2) for a very good reason. Sadly there has been never any emphasis on that recommendation (better: requirement?). We've been bitten by this (xmlbeans plugin depending on antrun plugin) and we currently do not allow the usage of any plugin that uses another one as dependency. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven 3 snapshot resolving
Upgrading to Nexus 1.8 did solve it, it seems. Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Including scope:provided dependencies in a shaded jar ?
Hi Greg, Grégory Joseph wrote: Hi, I have a project for which I'd like to create a shaded jar. It has a bunch of dependencies in scope:provided, because they really are, in the normal use-case of this artifact; it's meant to be deployed as a plugin in another app, so, for example, myapp-api really is provided. The project also has an assembly, which depends on these deps to be scope:provided (so they're not included in the assembly) If a webapp project is made and depends on this project, the scope:provided also helps avoiding duplicated dependencies in some cases. (I might have to double-check what I'm saying here ...) .. but yes, this project now also needs a standalone/executable jar; some of the provided dependencies are needed at runtime for this. As far as I can tell, the shade plugin currently does not propose any solution for this. Is there any way this could be considered for the plugin ? Or am I looking at it the wrong way ? Are there any alternatives ? I suppose I could split my project and have 2 modules, one simply being the standalone/shaded version of the other, but it seems overkill, since they're really the same source. I've also looked at the assembly plugin, but as far as I can tell it doesn't have a minify feature yet. (and we're talking 12mb vs 500k when minified) I reported this as http://jira.codehaus.org/browse/MSHADE-89 yesterday, before figuring it might be better discussed here beforehand. Thanks for any tip or hint, Did you see this: http://maven.apache.org/plugins/maven-shade-plugin/shade- mojo.html#keepDependenciesWithProvidedScope - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Including scope:provided dependencies in a shaded jar ?
could split my project and have 2 modules, one simply being the standalone/shaded version of the other, but it seems overkill, since they're really the same source. This is the correct approach (imo). Two artifacts, one for the provided artifact, another for the shaded artifact. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Including scope:provided dependencies in a shaded jar ?
2010/10/27 Grégory Joseph greg@gmail.com: .. but yes, this project now also needs a standalone/executable jar; some of the provided dependencies are needed at runtime for this. As far as I can tell, the shade plugin currently does not propose any solution for this. Is there any way this could be considered for the plugin ? Or am I looking at it the wrong way ? Are there any alternatives ? I suppose I could split my project and have 2 modules, one simply being the standalone/shaded version of the other, but it seems overkill, since they're really the same source. The multi-module path is the best. Why do you say that they share the same source? The shaded project must have a dependency on the original project, so it takes the compiled version, not the source. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 3 + site plugin + tycho
Am using maven 3 + tycho to build eclipse plugins:
i wrote a windows batch file to simulate a CI setup locally:
1. checkout projects from SVN
2. Build from parent
It fails with following err:
[ERROR] Failed to execute goal org.apache.maven.plugins:
maven-site-plugin:3.0-be
ta-2:attach-descriptor (attach-descriptor) on project
XXXhttp://com.ebay.rules.ci/:
Executi
on attach-descriptor of goal org.apache.maven.plugins:
maven-site-plugin:3.0-beta
-2:attach-descriptor failed: Unable to load the mojo 'attach-descriptor' in
the
plugin 'org.apache.maven.plugins:maven-site-plugin:3.0-beta-2'. A required
class
is missing: org.apache.maven.doxia.tools.SiteTool
However strange thing is that, i have another small batch that does just
1. move to previously downloaded projects (by prev batch)
2. build from parent
and this passes (atleast above err didn't come)
-
https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html
https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-SiteandReporting
i already saw these maven 3 changes against maven 2 and hence i have
profiles
profile
idmaven-3/id
activation
file
This employs that the basedir expression is only
recognized by
Maven 3.x (see MNG-2363)
exists${basedir}/exists
/file
/activation
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0-beta-1/version
/plugin
/plugins
/pluginManagement
plugins
plugin
artifactIdmaven-site-plugin/artifactId
Automatic execution of this goal in maven-2 is
not done any more
in maven-3
executions
execution
idattach-descriptor/id
goals
goalattach-descriptor/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/profile
/profiles
i already tried commenting above profile and giving something like
..
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0-beta-2/version
!--
Automatic execution of this goal in maven-2 is not done
any more in
maven-3
--
executions
execution
idattach-descriptor/id
goals
goalattach-descriptor/goal
/goals
/execution
/executions
/plugin
/plugins
/build
but both didn't work. Any help is highly appreciated. Thanks much
p.s. also i verified that in my local maven repo, the class in error is
present in a plugin named maven-doxio-tools (or something). This plugin is
seemed to be referenced by maven-site-plugin
Re: profile activation confusion
You either need to separate the configuration from the binaries, or have different artifacts. Your current solution does not work if you do deploys to a repo and adhere to the very important Maven rule that a release may NEVER be altered. /Anders On Wed, Oct 27, 2010 at 18:52, Jon Paynter kittl...@gmail.com wrote: On Wed, Oct 27, 2010 at 5:51 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Anders Hammar wrote: You need Maven 3.0 to be able to activate profiles in the pom by properties set in a profile in settings.xml. The point is that this functionality is superfluous. If you want a profile be activated based on properties in settings.xml, you may as well simply add it there to your activeProfiles section. Works also for M2. im using maven 3.0. I ended up defining a property inside an already alwaysActive profile in the settings.xml. Rather a kludge - but it works. On Wed, Oct 27, 2010 at 5:44 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 27/10/2010 1:51 AM, Anders Hammar wrote: While on the topic, I'd like to mention that having a different build (through profiles for example) for each environment is not good. In Maven, there can only be one flavor of a released artifact. So if you build v1.0 of your war, cannot rebuild it with a different content. What you should do is build different artifacts for each environment. Use classifiers or, in my opinion even better, different Maven projects. This have been discussed several times on this list about a month ago or so. And should be in the Best Practices section of the documentation so that people know that this is settled law. I need something that supports parallel releases. We have 3 QA environments, 1 or more of which can have a release that is being tested to go into production. So for example: QA1 would have v3.0 currently under test with a scheduled release date in september, and then QA2 would have v3.1 under test with a scheduled release date in November. Currently each environment has a properties fie containing environment specific values and the build. So based on the target environment for a given build, the appropiate properties file is used for filtering. While this doesnt seem to fit well with the maven way - it works for us. What would you suggest as an alternative?
Re: profile activation confusion
On Wed, Oct 27, 2010 at 11:41 AM, Anders Hammar and...@hammar.net wrote: You either need to separate the configuration from the binaries, or have different artifacts. The configuration is separated from the binaries for the most part. however some artifacts (like a war file) have environment specific class path names in them. But an integral part of our build process is to generate the config files read by the binary artifacts at runtime. Add to that some of the almost source files like wsdl endup having server names embedded in them (compliments of oracle). But what do you mean by different artifacts? Its not practical to have the build create artifacts for every environment due to our parallel releases process. if Im testing the 3.0 release in the QA2 environment, thats all I want to build. Creating artifacts for an environment that will never be used is a waste of time and resources. Your current solution does not work if you do deploys to a repo and adhere to the very important Maven rule that a release may NEVER be altered. Unfortunately I cant change that. The only thing that doesnt change between environments is the source code.
How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
We have a common project parent-pom, and a build-resources-bundle project containing various build resources, bundled into a Jar artifact. One of these resources is used in configuring the maven remote-resources-plugin, for instance. We start with the configuration where both the parent-pom and build-resources-bundle are at version 1-SNAPSHOT. The parent-pom is set up as an aggregator pom, with one child: the build-resources-bundle project. Executing mvn release:prepare on the parent-pom causes the prepare phase to go and update the versions of these from 1-SNAPSHOT to 1 for the tag. However, this process does not notice that the remote-resource-plugin's configuration in the parent-pom is specifying the build-resources-bundle at version 1-SNAPSHOT - so that version is *not* updated. If a release:perform were to be done, it would build from the tag checkout, and configure the remote-resources-plugin to use the 1-SNAPSHOT version of the build-resources-bundle; I want it to be using the 1 version of the bundle. To work around this, I could run the release:prepare, and then update manually, the tag, to update the reference from 1-SNAPSHOT to 1. The other thing I could imagine doing is uncoupling these two artifacts, and releasing the build-resources-bundle separately. This would require that I duplicate a bunch of things from the common project parent-pom, into the build-resources-bundle, and do a separate release cycle, just for it, and then have the parent-pom depend on the released version. What is the maven way for doing this kind of thing? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
arguments versus useReleaseProfiles versus the the release plugin
Using release plugin 2.1: org.apache:apache:7 uses arguments to turn on a profile. I don't want that profile in prepare. I have another profile I'd like instead. So, I've got .. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.1/version configuration arguments-P!apache-release,everything/arguments useReleaseProfiletrue/useReleaseProfile releaseProfilesrelease,mahout_release,release_perform/releaseProfiles remoteTaggingtrue/remoteTagging goalsdeploy/goals autoVersionSubmodulestrue/autoVersionSubmodules allowTimestampedSnapshotstrue/allowTimestampedSnapshots /configuration /plugin Evidence suggests that the release profiles are not being activated. Does a -P in arguments disable releaseProfiles altogether somehow? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On 27/10/2010 1:28 PM, Wayne Fay wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Or just move to Eclipse/STS(free) and get everything, all included. 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
using the CheckoutMojo in my own plugin
I'm writting a plugin that checks the dependencies and seperates my company
dependencies out. That works fine but now I would like to run a checkout on
those.
I have the connectionUrl set in the poms. I just need to call checkout.
I have tried getting an object of CheckoutMojo type but it always comes back
as a Null.
I thought maybe to bag that and just do a CommandLine call but I like the
idea of a universal scm plugin.
This is the latest iteration:
CheckoutMojo co = (CheckoutMojo) lookupCheckoutMojo();
...
co.execute();
protected Mojo lookupCheckoutMojo()
{
PlexusContainer container = new DefaultPlexusContainer();
container.initialize();
container.start();
return (Mojo) container.lookup( Mojo.ROLE,
org.apache.maven.plugins:maven-scm-plugin:1.4:checkout);
}
[ANN] Maven Archetype Plugin 2.0 Released
The Maven team is pleased to announce the release of the Maven Archetype Plugin, version 2.0 Archetype is a Maven project templating toolkit. http://maven.apache.org/archetype/maven-archetype-plugin/ Release Notes - Maven Archetype - Version 2.0 ** Bug * [ARCHETYPE-202] - Can't download archetype-catalog.xml via proxy connection * [ARCHETYPE-242] - The remote archchetype-catalog doesn't really exist. * [ARCHETYPE-271] - archetype create swallows exception information * [ARCHETYPE-304] - problem with mvn archetype:generate for ear-jee5 (168) * [ARCHETYPE-306] - archetypes downloaded are not downloaded with their poms * [ARCHETYPE-320] - Generator contacts central repo although archetype is available on local Nexus * [ARCHETYPE-322] - archetype:generate throws Too many open files error * [ARCHETYPE-323] - FilesetArchetypeCreator.getGeneratedSourcesDirectory() returns hardcoded directory * [ARCHETYPE-324] - (null) displayed when there is no archetype description * [ARCHETYPE-326] - fail on mvn install with a archetype created from create-from-project command * [ARCHETYPE-327] - Inadequate error diagnosis for archetype problems * [ARCHETYPE-330] - Incorrect information on maven-archetype- plugin/source-repository.html * [ARCHETYPE-331] - No archetype repository found. ... should not be a warning * [ARCHETYPE-333] - Errors creating project from previously accepted archetype * [ARCHETYPE-337] - remove goals and properties elements from archetype- catalog ** Improvement * [ARCHETYPE-206] - Document how to generate a project from archetype with authenticated repository * [ARCHETYPE-282] - When reading the archetype-metadata.xml file, would be helpful to know if the XML was badly formed * [ARCHETYPE-286] - Use System.getProperty(line.separator) for line ending terminators of generated source files * [ARCHETYPE-299] - create-from-project doesn't need to add extensionstrue/extensions to template pom * [ARCHETYPE-325] - order versions when selecting archetype * [ARCHETYPE-336] - Plugin documentation refers to Maven 2 * [ARCHETYPE-338] - add documentation about maven-archetype vs jar packaging ** Task * [ARCHETYPE-317] - upgrade source to java 5 Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Setting class path with Shade plugin
Hi all,
We're creating an uber jar using the shade plugin. This is working
well, but I'm having trouble getting the class path set properly in my
manifest. Our deployment directory structure is as follows.
/appdir/service.jar
/appdir/conf/log4j.properties
/appdir/conf/zookeeper.properties
etc etc.
All our class files will be in the service.jar that is created by shade.
All the configuration information is loaded as a resource from the
classpath, so I need any item in ./conf to also be in the classpath.
Below is my configuration.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration
shadedArtifactAttachedtrue/shadedArtifactAttached
minimizeJartrue/minimizeJar!-- may not work, test this --
finalNamesystemservice/finalName
transformers
transformer
implementation=org.apache.maven.plugins.shade.resource.ManifestResourceTransformer
mainClasscom.spidertracks.aviator.systemservice.ServiceRunner/mainClass
manifestEntries
Class-Path./conf//Class-Path
Version${version}/Version
/manifestEntries
/transformer
/transformers
/configuration
/execution
/executions
/plugin
Any help would be greatly appreciated. I've tried ./conf, conf, conf/,
and conf/*. None seem to work.
Thanks,
Todd
Re: Maven SQL plugin
Yup, I would like to do that. However, I settled for an alternative for my project. If someone could help me with a starting point in the code(Am I asking for too much? ) I will take it from there. Thanks, Chris. On Wed, Oct 20, 2010 at 2:25 AM, Wayne Fay wayne...@gmail.com wrote: In this case, I cannot use the fileset as the ordering mechanism is alphabetical. srcFiles seems a good choice however I cannot specify wildcards :( Have you considered simply modifying the Maven SQL plugin to add the functionality you require, and then offering your changes back for inclusion in a future release of the plugin? Adding a feature like you're proposing should be relatively simple, I'd assume. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
