Re: Multi project release without SCM
The concept is what I am looking for, but it doesn't do exactly what I need. For example: the parent pom has version 1.11-SNAPSHOT, all child poms refer to this version. If I want to release 1.11, I remove "-SNAPSHOT" in the parent pom and do an versions:update-parent. But the 1.11 pom is not released yet, so this action will replace all child 1.11-SNAPSHOT references with 1.10 instead of 1.11. What I would need to do is: - replace 1.11-SNAPSHOT with 1.11 in parent pom - run release on the parent (childeren will still refer to 1.11-SNAPSHOT) - run versions:update-parent - run release again But that does not work, because then I will release the 1.11 parent twice, which will fail. I'll see if I can find another way to get this working with this plugin. -- View this message in context: http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p512571.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: Multi project release without SCM
Nevermind: versions:update-child-modules -- View this message in context: http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p512572.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
Multi project release without SCM
I have a good working multiproject release but no SCM setup yet (I'm waiting for BRZ to be installed to replace CVS). Currently the parent pom has version 1.10-SNAPSHOT configured. The component's pom refer to this pom. If I want to release 1.10, do I need to modify all the pom's and remove "-SNAPSHOT"? release:prepare does not work because of the missing SCM. -- View this message in context: http://maven.40175.n5.nabble.com/Multi-project-release-without-SCM-tp511922p511922.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: extending WAR
What about this one? http://www.jfrog.org/sites/mvn-anno-mojo/latest/ -- View this message in context: http://old.nabble.com/extending-WAR-tp28742485p28753463.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: extending WAR
Stephen Connolly-2 wrote: > > Nope. you will still have the issue of the plugin metadata being > incorrect. > > Short answer: [image: donny_dont_22.jpg] Don't do what Donny Don't Does > Ahh, ofcourse, this make it clear: "when you extend a maven-plugin artifact, the maven-plugin-plugin cannot see the javadoc annotations of the parent mojo classes (because they are javadoc annotations and it only has access to the .class files)". I'm so used to Java annotations that this slipped me. So code (plugin) reusage simply is a no-no. I could copy all properties + javadoc annotations in my own class and forward them to the parent. Hm. What will be the gain... Thanks! -- View this message in context: http://old.nabble.com/extending-WAR-tp28742485p28753414.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: extending WAR
This will work for M3? Because we're still introducing Maven, so I could require that. (Although the last version of M3 does not seem to handle -U correctly.) -- View this message in context: http://old.nabble.com/extending-WAR-tp28742485p28750984.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: extending WAR
Wayne Fay wrote: > > Before working any more on extending plugins, you should read the > following thread from last week: > from: Lachlan Deck > to: Maven Users List > date: Mon, May 24, 2010 at 8:54 PM > subject: mojo help > OMH, "the maven-plugin-plugin not merging plugin metadata design issue"? This the third mojo I'm developing and it (Maven) keeps being complex. Thanks for the pointer! -- View this message in context: http://old.nabble.com/extending-WAR-tp28742485p28750648.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
extending WAR
I'm in the process of migrating some ANT build scripts to Maven by creating mojo's that will provided the same functionality. One of the processes I need to migrate is a customized WAR creation; I need to copy in some additional files and I also need to create a second zip containing all static content. I figured I reused the maven-war-plugin, so I wrote a class that extends WarMojo (2.0) and aside from just writing a log statement in the buildExplodedWebapp it didn't do anything. This caused a NullPointerException (NPE). Then I started on several permutations of this approach and all end in a NPE. So I googled to see if anyone had done this before and found a few that had (a.o. Seam). I tried copying their code, but the NPE still came along. Even copying the source of WarMojo.java to my class causes the NPE. All the NPEs revolve around not having null directories, in this case "outputDirectory" is null. What I do not get is why the behavior is different if I put the WarMojo code in my own class (and thus causes a NPE); these setting should be initialized by Maven... java.lang.NullPointerException at java.io.File.(File.java:222) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:129) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6 0) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.0/src/main/java/org/apache/maven/plugin/war/WarMojo.java?revision=406221&view=markup Aside from the technical issue; what would be the correct way to extend the WAR plugin? I'm still believe I should be extending WarMojo and override & enhance the buildExplodedWebapp method. The WarMojo can then finish up creating the War, after I copied in the extra files, and I can also create the additional zip at that time. -- View this message in context: http://old.nabble.com/extending-WAR-tp28742485p28742485.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: install after deploy?
Wayne Fay wrote: > > > What does your repo declaration look like in settings.xml? I'm > guessing you've got an "always" in the updatePolicy field. > Nope, just id, user and password. I do use -U (if the repository can be pinged) so snapshots are always checked, but that does not change that once it is in the local repo it is not downloaded anymore. Deploy could put it in the local repo. -- View this message in context: http://old.nabble.com/install-after-deploy--tp28243701p28245134.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: install after deploy?
Wayne Fay wrote: > > What version(s) are you working with -- I am guess they're snapshots? > Maven 3 alpha 5 I believe. Yes, they are snapshots. -- View this message in context: http://old.nabble.com/install-after-deploy--tp28243701p28244155.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
install after deploy?
What I see when I deploy a business model to be used by other components, is that install is run before deploy. This is quite logical and the deploy then uploads the artifact to Nexus. When I then build the other component, the artifact is downloaded from Nexus. This seems strange to me, since the version in my local repository is the same as the one in Nexus. If I run an explicit install after the deploy there is no download. What is the best way to prevent that unnecessary download? Should install-to-local-repository not be a part of deploy instead of a previous run separate target, so that the timestamps are correct? -- View this message in context: http://old.nabble.com/install-after-deploy--tp28243701p28243701.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: update snapshots always but do not block when unreachable
BRIAN FOX-5 wrote: > > You can use the offline mode when it's unreachable. This is settable > by -o from the command line. > But it will not do that automatically? If unreachable then add -o, if reachable add -U. Correct? But there is no update-if-reachable? -- View this message in context: http://old.nabble.com/update-snapshots-always-but-do-not-block-when-unreachable-tp27479906p27491105.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
update snapshots always but do not block when unreachable
I'm busy fine tuning our maven (3) based environment. One of the behaviors I want is this: - always check if there is a newer version of snapshots in Nexus - but do not fail when Nexus is unreachable The first is done with --update-snapshots, but if the repository is unreachable (for whatever reason; e.g. you're on a train and the connection is down), the developer cannot compile anymore because Maven fails with an error. I also tried: kp-snapshots ... false always But then it does not check for a newer version in Nexus. Is it possible to configure: check-and-update-always-if-available? -- View this message in context: http://old.nabble.com/update-snapshots-always-but-do-not-block-when-unreachable-tp27479906p27479906.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: pom without artifacts?
Anders Hammar wrote:
>
> When you specify 'pom' as package type in a project you mostly konfigure
> the
> lifecycle of that project.
>
> When in your dependency, you need to specify the type as well ("pom"),
> otherwise Maven is going to look for a jar dependency.
>
> It's two different things. This is just how things work, you need to
> appreciate that...:-)
>
Well. Maven is complex to fully understand. It seems to simple at first;
phases, goals, and there you go. One day I will understand this as well, but
right now I cannot appreciate it :-)
--
View this message in context:
http://old.nabble.com/pom-without-artifacts--tp27381618p27390933.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: pom without artifacts?
Jörg Schaible-2 wrote: > > No, it cannot. If you omit the type, it defaults to "jar" and that is a > different artifact. > I understand that the PACKAGING type needs to be set to "pom", but I do not understand (and that was my error) that the DEPENDENCY type, so the other side of the relation, also must be set to "pom". -- View this message in context: http://old.nabble.com/pom-without-artifacts--tp27381618p27385253.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: pom without artifacts?
Anders Hammar wrote: > > If you want a pom project, > you MUST specify 'pom' as package type. > The problem was that one also needs to specify "pom" as the type in the dependency (see your link, thanks!). That is strange; it can derrive that from packaging type in the referred pom. -- View this message in context: http://old.nabble.com/pom-without-artifacts--tp27381618p27383694.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: pom without artifacts?
Alexander-129 wrote: > > You are defining this pom project as dependency in module? Right? > I have a series of POM + JARs uploaded to Nexus, e.g. - xxx-1.1.jar - xxx-skinA-1.1.jar - xxx-skinB-1.1.jar - xxx-skinC-1.1.jar This works fine. Now I want a "xxx-all:1.1" pom which will download the whole bunch above. In a project I indeed have a denpendency: ... xxx-all1.1 When resolving that project it tries to download "xxx-all-1.1.jar" and fails on a missing dependency. -- View this message in context: http://old.nabble.com/pom-without-artifacts--tp27381618p27383258.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: pom without artifacts?
Tranquil wrote: > > what about setting the packaing to "pom" instead of "jar" ? > No, it keeps trying to download xxx-all:jar:2.9.1 The artifact id is "xxx-all". -- View this message in context: http://old.nabble.com/pom-without-artifacts--tp27381618p27382885.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
pom without artifacts?
I have uploaded a swing look-and-feel to our internal repository. The LaF contains a main jar plus a separate jar for each skin. In order to minimize the end result, each skin is uploaded separately with its own pom referring to the main jar. But sometimes I want it all skins, so I figured I create a pom with refers to all skins (which in turn refer to the main), but does not contain any artifacts itself. I can upload the pom without problems, leaving out the packaging. But when refering to it, it tries to download "xxx-all.jar", so it assumes a default packaging. Is there any way to create such a artifact-less pom? -- View this message in context: http://old.nabble.com/pom-without-artifacts--tp27381618p27381618.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
