Re: Undocumented Feature: Usage of negation for profile activation
Wendy Smoak-3 wrote: > > It could go on > http://maven.apache.org/guides/introduction/introduction-to-profiles.html > . > > Can you open a JIRA issue if there isn't one, and possibly suggest a > patch? > Done, cf. http://jira.codehaus.org/browse/MNGSITE-86 -- Thorsten -- View this message in context: http://www.nabble.com/Undocumented-Feature%3A-Usage-of-negation-for-profile-activation-tp23446509p23480546.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
Undocumented Feature: Usage of negation for profile activation
Hello, I just found a---to my best knowledge---undocumented feature and though I should share it with the community in the hope that it will made its way into the Maven documentation. The feature is that you can use the negation symbol "!" within a profile activation specifification not only to test the absence of a property but also within the tag, for instance, to express something like "activate the profile if the OS family name is _not_ xyz". The following example illustrates this: tools-jar-windows windows tools-jar-unix unix !mac os x tools-jar-mac unix mac os x So in this example I use !mac os x to specify that the profile tools-jar-unix should be applied to all UNIX family operating systems _except_ Mac OS X. This example was tested with Maven 2.0.9, 2.0.10, 2.1.0 on Windows, Linux, and Mac OS X and it works for all of them. Nice :-) Cheers, Thorsten -- View this message in context: http://www.nabble.com/Undocumented-Feature%3A-Usage-of-negation-for-profile-activation-tp23446509p23446509.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: [Vote] findbugs-maven-plugin v 2.0 release
-1 Background: According to http://jira.codehaus.org/browse/MFINDBUGS-66, the plugin integrates Findbugs version 1.3.6. Meanwhile, version 1.3.8 was released. I suggest to catch up with that release before releasing the plugin. -- Thorsten Garvin LeClaire-2 wrote: > > The Maven Findbugs team would like to release Maven Findbugs Plugin > version 2.0 > > This plugin allows the developer to run Findbugs analysis against a > Maven project and produce site output in HTML to match other site > reports. There are option to produce other XML outputs which are used > by other plugins. > > Issues fixed in this release: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&fixfor=14335&pid=11701&status=6&sorter/field=issuekey&sorter/order=DESC&sorter/field=issuetype&sorter/order=DESC > > > More information can be found at the plugin site: > http://mojo.codehaus.org/findbugs-maven-plugin/ > > > Issues Can be registered in JIRA at: > http://jira.codehaus.org/browse/MFINDBUGS > > > More information on FindBugs > http://findbugs.sourceforge.net/index.html > > > > You can test the Maven Findbugs Plugin in your own project by adding the > following dependency: > > > org.codehaus.mojo > findbugs-maven-plugin > 2.0-SNAPSHOT > > > > > *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will > require Maven to be run with a minimum of Java 5. This is consistent > with Findbugs requirement for their versions of 1.3.X and greater. > > > > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > > Regards, > > > > Garvin LeClaire > garvin.lecla...@gmail.com > > > -- View this message in context: http://www.nabble.com/-Vote--findbugs-maven-plugin-v-2.0--release-tp22715803p22723449.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
Activation of multiple profiles at the same time
Hello,
I'm facing some behavior regarding activation of multiple profiles within a
pom.xml, which is contrary to what I was expecting. Maybe someone can help.
I have a pom consisting of three profiles:
default
true
${java.home}/../lib/tools.jar
tools-jar-mac
false
Mac
${java.home}/../Classes/classes.jar
jdk1.5
false
1.5
org.codehaus.woodstox
woodstox-core-asl
4.0.3
What I want to achieve is that for platforms other than Mac OS _and_ Java
version 1.5.* the profiles "default" _and_ "jdk1.5" will be activated. For
platforms other than Mac OS _and_ Java 1.6 only the profile "default" should
be activated. Finally, for the Mac OS platform the profile "tools-jar-mac"
_and_ "jdk1.5" should be activated for Java 1.5; while only profile
"tools-jar-mac" should be activated for Java 1.6.
It seems to me that activation of profiles is exclusive, i.e., only one
profile is activated at a time. For instance, when using mvn
help:active-profiles on a Linux machine with Java 1.5 SDK, I see only
profile "jdk1.5" activated, but what I was expecting is that "default" would
be activated as well. Is there any way to achieve automatic activation of
multiple profiles apart from explicitly stating profiles via -P on the
command line.
-- Thorsten
--
View this message in context:
http://www.nabble.com/Activation-of-multiple-profiles-at-the-same-time-tp22576838p22576838.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: Doesn't suppress box around APT text
I can confirm your observation, i.e., it doesn't work for me either (using Maven 2.0.9 and site plugin 2.0-beta-7). But I havn't checked if there is already an issue about that in JIRA. -- Thorsten Czollli wrote: > > Hello, > > according to the APT format a text like this: > > > Some text > > > should look without box around in the html, but there is a box around... > > I tried the sample in the format description but the result is the same. > > Does it work for anybody? Or it can be a bug? > > Thanks a lot! > > Czollli > -- View this message in context: http://www.nabble.com/Doesn%27t-suppress-box-around-APT-text-tp21931250p21932504.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
How to refer to SNAPSHOT timestamp from Web site
Hello,
I'm creating a project Web site using the Maven site plugin. The project is
currently in a SNAPSHOT state, that is, the assembly that I create (and
artifacts) have a timestamp suffix attached to their file name when the get
deployed to some Maven repository.
Assuming that the build process runs "mvn deploy site-deploy" I would like
the Web site to render the link referring the the current assembly file,
i.e., using the current snapshot timestamp. How can this be achieved? Is
there a property like "${timestamp}" that I could use to get the current
value?
Thanks,
Thorsten
--
View this message in context:
http://www.nabble.com/How-to-refer-to-SNAPSHOT-timestamp-from-Web-site-tp21730328p21730328.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: Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Sorry, the subject of this posting is false. I used Nabble to post that message and for some strange reason it used a subject from an earlier posting. I re-posted this message with the correct subject. -- Thorsten TM wrote: > > Hello, > > we face a rather advanced requirement regarding creation of various > assemblies in a multimodule project. What we are trying to achieve is as > follows. > > Assume there is a root project P consisting of multiple module projects > M1, ..., Mn (hierarchy depth max. 1). From the root POM we create various > assemblies in the usual way (one descriptor file for each assembly; not > attached to the build lifecycle). That works fine. Now, we also need to > create yet another assembly just for one module, say M1. Whatever we have > tried so far, we were not able to get it working without the overall build > to fail, or at least without achieving exactly what we need. > > The only configuration where the overall build did not fail is to put the > assembly descriptor for M1 to the root POM together with the other ones. > Unfortunately, the file name of the packaged assembly will then always > start with the artifactId and version number of P, rather than the > artifactId and version of M1. > > Whenever we put the maven assembly plugin in the POM of M1, in addition to > the assembly plugin in the root POM, the build does fail with various > error messages. We tried both to attach execution to the package > lifecycle, or to use standalone execution using assembly:assembly on the > command line. We also tried almost every combination of single, attached, > and assembly mojo when execution is attached to the package build > lifecycle. All without success. > > The question is whether this constellation was taken into account at > design time of the assembly plugin, thus, whether it is possible at all. > If not, should I file a feature request. > > BTW, we use assembly plugin 2.2-beta-3 and Maven 2.0.9. > > Regards, > Thorsten > -- View this message in context: http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp21602014p21602133.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
Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Hello, we face a rather advanced requirement regarding creation of various assemblies in a multimodule project. What we are trying to achieve is as follows. Assume there is a root project P consisting of multiple module projects M1, ..., Mn (hierarchy depth max. 1). From the root POM we create various assemblies in the usual way (one descriptor file for each assembly; not attached to the build lifecycle). That works fine. Now, we also need to create yet another assembly just for one module, say M1. Whatever we have tried so far, we were not able to get it working without the overall build to fail, or at least without achieving exactly what we need. The only configuration where the overall build did not fail is to put the assembly descriptor for M1 to the root POM together with the other ones. Unfortunately, the file name of the packaged assembly will then always start with the artifactId and version number of P, rather than the artifactId and version of M1. Whenever we put the maven assembly plugin in the POM of M1, in addition to the assembly plugin in the root POM, the build does fail with various error messages. We tried both to attach execution to the package lifecycle, or to use standalone execution using assembly:assembly on the command line. We also tried almost every combination of single, attached, and assembly mojo when execution is attached to the package build lifecycle. All without success. The question is whether this constellation was taken into account at design time of the assembly plugin, thus, whether it is possible at all. If not, should I file a feature request. BTW, we use assembly plugin 2.2-beta-3 and Maven 2.0.9. Regards, Thorsten -- View this message in context: http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp21602014p21602014.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: [ANN] Maven Assembly Plugin 2.2-beta-3 Released
This was eagerly awaited. Thanks for the good work!
However, I've found one minor difference that caused a change in my assembly
descriptors when upgrading from 2.2-beta-1 to 2.2-beta-3. So far, it was
possible to exclude an entire directory from a fileset just by listening its
name, as in the following exclude ('bin' folder):
assemblies/minimal/src/main/release
/
bin
With the upgrade to beta-3 this does not to work any longer because the
target assembly contained the bin folder (and its content). I had to replace
the exclude tag as follows:
assemblies/minimal/src/main/release
/
bin/**
I cross checked the maven-assembly-plugin Web site for documentation of the
pattern format without success. I guess, somewhere, it is documented, but I
couldn't find it (as fast as I would like to). It would be good to update
the documentation and add links to the place where the pattern format is
documented.
Regards,
Thorsten
John Casey-7 wrote:
>
> The Maven team is pleased to announce the release of the Maven Assembly
> Plugin, version 2.2-beta-3
>
> This plugin is used to create custom archives using the build output,
> dependencies, and other files owned by a Maven project. You can find
> more information, including instructions and examples, at:
>
>
--
View this message in context:
http://www.nabble.com/-ANN--Maven-Assembly-Plugin-2.2-beta-3-Released-tp21298644p21329363.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: [PLEASE TEST] Maven 2.0.10-RC10
Multi-module project fails with NPE on assembly:assembly (assembly plugin
used 2.2-beta-1; command used was "mvn clean install assembly:assembly
eclipse:eclipse"). Same configuration works with Maven 2.0.9. Below you will
find relevant excerpt from the build trace.
Best regards,
Thorsten
[INFO]
[INFO] Building OSIRIS Next
[INFO]task-segment: [assembly:assembly] (aggregator-style)
[INFO]
[INFO] Preparing assembly:assembly
[INFO]
[INFO] Building OSIRIS Next
[INFO]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1426)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:410)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:682)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1037)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:546)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1194)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1032)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:634)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:377)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:274)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:189)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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)
[INFO]
[INFO] Total time: 55 minutes 18 seconds
[INFO] Finished at: Mon Aug 25 17:18:11 CEST 2008
[INFO] Final Memory: 36M/126M
[INFO]
--
View this message in context:
http://www.nabble.com/-PLEASE-TEST--Maven-2.0.10-RC10-tp19117054p19146039.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Assembly plugin 2.2-beta-2 shows odd behavior regarding dependencies inclusion
Hello,
today I tried to upgrade the Maven assembly plugin from 2.2-beta-1 to
2.2-beta-2. However, I noticed that for my project which consists of
multiple modules the resulting binary assembly now contains dependency JAR
files multiple times. The assembly descriptor contains the following excerpt
(with changed module names):
${pom.groupId}:a
${pom.groupId}:b
${pom.groupId}:c
true
false
/lib
The projects a, b, c have several dependencies, whereby some of those
dependencies refer to identical artifacts (derived from a parent POM), e.g.,
commons-logging. The resulting ZIP and TAR.GZ assembly files then contain
those dependencies multiple times (in the lib folder) with equal names! Im
not sure if this is a bug or a feature and I might have missed something.
When I change the version back to 2.2-beta-1 it works as expected, i.e., all
files exist only once.
Any hints?
Thanks,
Thorsten
--
View this message in context:
http://www.nabble.com/Assembly-plugin-2.2-beta-2-shows-odd-behavior-regarding-dependencies-inclusion-tp16720569s177p16720569.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two question regarding the Eclipse plugin
nicolas de loof-3 wrote: > > For 1), you should use to block transitive dependencies. > > For 2), any code generation plugin that runs before generate-resource > phase > will get executed by mvn eclipse:eclipse and the generated source folder > added to the .classpath. If you don't get this behaviour, maybe you > missuse > the plugin, or this one is not compliant with maven standards. > I'm sorry to say that but are not an option. The effort to maintain them for large projects are too high. I guess I have to live with that for the time being. Maybe I should open a feature request for the Eclipse plugin and see if there are more people wishing that. Regarding the second point: I tried to run "mvn install eclipse:eclipse" and it works, i.e., it will include the additional source folder. Thanks! Thorsten -- View this message in context: http://www.nabble.com/Two-question-regarding-the-Eclipse-plugin-tp15207989s177p15231842.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Two question regarding the Eclipse plugin
Hello, I'm facing two issues regarding the Maven Eclipse plugin for which I havn't found a soulution yet. 1.) Consider the simple scenario: project A depends on project B, B depends on JAR xyz. If I run mvn eclipse:eclipse for A it will add xyz to the classpath; so far so good. What if I want to prevent that xyz is added to A's classpath? Is this possible? I didn't find an option for that. The reason is that for complex project structures with lots of JARs and transitive JAR/project dependencies this will blow up the classpath with JAR's which are actually not referenced (if they derive from transitive dependencies). In the forum I found a "solution" that proposes to set the scope for JARs to 'optional'. But I consider this a hack and would rather prefer a switch like "addTransitiveDependenciesToClasspath=true|false" for the Eclipse plugin. 2.) I have a maven build that creates some source code (via jaxws-maven-plugin) which will be stored in a separate source folder (in order no to interfere with other source code under version control). This generated source code is referenced by some test code in the same project. Is there a possibility to add additional source folders to the Eclipse .classpath file when running mvn eclipse:eclipse such that I do not get compile errors in Eclipse, because Eclipse does not know of any other folders than the default ones. Many thanks in advance for your help, Thorsten -- View this message in context: http://www.nabble.com/Two-question-regarding-the-Eclipse-plugin-tp15207989s177p15207989.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse plugin and project references
> Yes, when mvn eclipse:eclipse is run for a multi module project, the > dependencies between the modules will be project dependencies. > I see. After I started it from the root project it did work as wanted. Thanks. Still remains the (minor) question to me why does the plugin behaves different depending on whether it was started from the sub module resp. the parent project. In my opinion, this shouldn't make a difference. Thorsten -- View this message in context: http://www.nabble.com/Eclipse-plugin-and-project-references-tp14844945s177p14981288.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse plugin and project references
Hello, my question is about whether it is possible to let the Maven Eclipse plugin create the ".classpath" file in a way that it will directly reference dependency projects instead of referencing the JAR artifact from the local repository. The following example .classpath file for a project named "foo" illustrates this: The version above has three "direct" references to projects "common", "system", and "api" which are all sibling projects, i.e., are located in the same folder than project foo. Regarding Maven all four projects are modules of a parent project. When I now start "mvn eclipse:eclipse" in project foo it will create a .classpath file that looks like this: The three projects are now referenced by the JAR artifact from the repository. This is not optimal for me since changes to the code in one of the three projects are not instantly visible to project foo (provided that Eclipse' auto build is turned on); only after a Maven install rebuild. Is there any option that I can use to force the Eclipse plugin to reference dependency projects directly? If it doesn't exist yet, then take this as a feature request. Thanks, Thorsten -- View this message in context: http://www.nabble.com/Eclipse-plugin-and-project-references-tp14844945s177p14844945.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
