Re: Any plugins or tools that alert users to new versions of Jars?
avixbaouxx wrote at Donnerstag, 25. Juni 2009 20:38: Basically that...I'm curious if there's a way to email or otherwise alert users that new versions of their dependencies exist at build time? Well, I could imagine such a behaviour quite annoying especially when you know that you want to use not the latest version. However, the idea is good, but it could be added as another dependency report. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven with Hibernate/Multiple POM files
Hi David,
David Weintraub wrote at Donnerstag, 25. Juni 2009 17:34:
1/ A POM is not a programming language, but a project description. It is
pointless to define the properties section in the top of the file in the
hope that Maven sees the values first before you use them. You can
call mvn help:effective-pom to see what Maven actually uses for the
project description in the end.
It could be that I simply don't understand how to do something. We
have a continuous build system, and label each of our builds with a
build number. We like that build number to part of the maven artifact
itself. For example, aim-2.1.2-D-32-bin.tar.gz where 2.1.2-D-32 is our
build number.
However, there is no need to put these builds into our Maven
repository since our continuous build system makes them available and
manages them. Otherwise, I would have to do a constant purge our our
Maven repository since we can do 10 to 20 builds each day.
This is why I have the product's version as a property. I can pass it
into the pom when a build is done. At the same time, I need to allow
developers to run the builds themselves, and not have
aim-${aim.version}-bin.tar.gz as the name of the maven artifact. In
order to avoid this, I put the property inside of the POM. I could put
this anywhere directly under the project/, but putting it at top
allows the developers to easily find it when they do want to change
the default (such as when we start work on version 2.1.3).
So, what is the correct way to set my projects in order to be able to
have a default version number, yet allow me to override it on the
command line?
At least I can now understand why you try to do this and that you actually
understood, that declaring the property right in the top does not change
anything.
However, with using a property for the parent's version you're more or less
building on undefined Maven behavior. Main reason is that Maven has to
resolve the parent before it can generate the resulting project model.
Did you had a look at the buildnumber plugin instead? It might help you in
this case.
That also doesn't cover my other problem: I am using
net.sf.maven-har:maven-har-plugin which requires me to have my service
file called jboss-service.xml living in the resource's META-INF
directory. Unfortunately, our service file is called
hibernate-service.xml.
Is it possible to somehow redefine the name of this file in your
pom.xml? If I was writing this code from scratch, I would simply use
the default name. But, I have to make sure that the structure of my
Maven artifact matches the output of our current build artifact.
Where can I at least find documentation on this plugin? I got the
basic POM structure by doing a mvn archetype:generate and requesting a
har project.
This plugin is obviously developed by an independent project at SourceForge,
you will have to ask the developers there.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Local/proxy dependency resolution when the artifact's metadata is the same
In our team we are using a Proxy repository where the artifacts are uploaded on mvn deploy. Let's consider the following artifact : groupIdcom.acme/groupId artifactIdfoo/artifactId version1.0/version I have it in my local repository, and it's also on the proxy repo. My colleague decides to do a very minor change to the corresponding foo Maven project, and redeploys this artifact to the proxy repository, but without changing the artifact's version. Does this mean that as long as this artifact is in my local repo, I will never be using the latest version (the one on the proxy) when resolving dependencies? -- View this message in context: http://www.nabble.com/Local-proxy-dependency-resolution-when-the-artifact%27s-metadata-is-the-same-tp24216134p24216134.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
Special build for modules - how to?
Hi
We have a build which consists of several projects which each consists of
several modules. We also have a global parent which defines how the build works.
Now, I had the problem that some modules need special steps in their build,
e.g. JAXB2 generation, creating an OSGi module etc.
Of course, I tried to stick to the Don't Repeat Yourself principle and wanted
to administer these special steps myself, instead of leaving it to the
individual developers to copy paste the build configuration over and over.
Since including parts of XML into a POM seems to be impossible, I did it with
profiles. For example:
!-- Use this profile if you want to generate XML binding classes using
JAXB2. --
profile
idjaxb/id
build
plugins
plugin
groupIdorg.jvnet.jaxb2.maven2/groupId
artifactIdmaven-jaxb2-plugin/artifactId
executions
execution
goals
goalgenerate/goal
/goals
/execution
/executions
configuration
schemaDirectory${jaxb.schema.directory}/schemaDirectory
generatePackage${jaxb.package}/generatePackage
removeOldOutputtrue/removeOldOutput
forceRegeneratetrue/forceRegenerate
/configuration
/plugin
/plugins
/build
properties
jaxb.schema.directorysrc/main/resources/jaxb.schema.directory
jaxb.packagech.ipi.${project.artifactId}.xml/jaxb.package
/properties
/profile
Now, if a module wants to use JAXB2, it just has to specify -Pjaxb; so far, so
good.
I thought this was a nifty solution, but there's a problem with reactor builds:
Let's say that I want to build the whole project (modules A, B, C), and module
A needs JAXB generation, module B needs an OSGi build etc.
The only way I saw until recently was to specify all the profiles required by
all the modules when building the whole project. However, for some plugins,
this fails miserably, since the plugin *expects* to see certain files, and if
it doesn't have them, it breaks the build. Besides, I tell every module to do
these special steps, and they only don't execute them because some
file/directory is missing (e.g. the XML schema directory), which for me is kind
of shaky...
The best thing for me would have been to activate a profile based on a Maven
property, so I could set the property it in the module's POM. Alas, this idea
doesn't work, since Maven only activates profiles based on system properties.
Next, I tried activating using files, something like
!-- Use this profile if you want to generate XML binding classes using
JAXB2. --
profile
idjaxb/id
activation
file
existsjaxb.profile/exists
/file
/activation
...
So, module A has a file 'jaxb.profile' in its root directory, module B has
'osgi.profile' etc. This works well on an individual module level, but as soon
as I build the whole project, it's totally ignored by the reactor.
In other words, I'm stuck!
Does anyone have the same kind of build that we have and what's your solution?
Is my idea of using profiles for this a valid one or am I totally off the
Maven way?
Should I file a request for enhancement that profiles should be activated by
Maven properties?
Best regards,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Special build for modules - how to?
Lewis, Eric wrote at Freitag, 26. Juni 2009 10:03:
Hi
We have a build which consists of several projects which each consists of
several modules. We also have a global parent which defines how the build
works.
Now, I had the problem that some modules need special steps in their
build, e.g. JAXB2 generation, creating an OSGi module etc.
Of course, I tried to stick to the Don't Repeat Yourself principle and
wanted to administer these special steps myself, instead of leaving it to
the individual developers to copy paste the build configuration over and
over.
Since including parts of XML into a POM seems to be impossible, I did it
with profiles. For example:
!-- Use this profile if you want to generate XML binding classes
using JAXB2. -- profile
idjaxb/id
build
plugins
plugin
groupIdorg.jvnet.jaxb2.maven2/groupId
artifactIdmaven-jaxb2-plugin/artifactId
executions
execution
goals
goalgenerate/goal
/goals
/execution
/executions
configuration
schemaDirectory${jaxb.schema.directory}/schemaDirectory
generatePackage${jaxb.package}/generatePackage
removeOldOutputtrue/removeOldOutput
forceRegeneratetrue/forceRegenerate
/configuration
/plugin
/plugins
/build
properties
jaxb.schema.directorysrc/main/resources/jaxb.schema.directory
jaxb.packagech.ipi.${project.artifactId}.xml/jaxb.package
/properties
/profile
Now, if a module wants to use JAXB2, it just has to specify -Pjaxb; so
far, so good.
I thought this was a nifty solution, but there's a problem with reactor
builds: Let's say that I want to build the whole project (modules A, B,
C), and module A needs JAXB generation, module B needs an OSGi build etc.
The only way I saw until recently was to specify all the profiles required
by all the modules when building the whole project. However, for some
plugins, this fails miserably, since the plugin *expects* to see certain
files, and if it doesn't have them, it breaks the build. Besides, I tell
every module to do these special steps, and they only don't execute them
because some file/directory is missing (e.g. the XML schema directory),
which for me is kind of shaky...
The best thing for me would have been to activate a profile based on a
Maven property, so I could set the property it in the module's POM. Alas,
this idea doesn't work, since Maven only activates profiles based on
system properties.
Next, I tried activating using files, something like
!-- Use this profile if you want to generate XML binding classes
using JAXB2. -- profile
idjaxb/id
activation
file
existsjaxb.profile/exists
/file
/activation
...
So, module A has a file 'jaxb.profile' in its root directory, module B has
'osgi.profile' etc. This works well on an individual module level, but as
soon as I build the whole project, it's totally ignored by the reactor.
To get this right: You've defined the plugin in the profile section of the
parent and you try to activate it in the individual modules? Interesting
idea. Are you sure that it simply does not work in reactor, because it is
looking for the file in the wrong working dir then? Did you try
exists${basedir}/jaxb.profile/exists ?
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding Dependency of other Child Project
Thanks for your reply Wendy. I did try the same, but maven cannot resolve the
artifact. Do I need to install the artifact somewhere (we are using an
archiva online repository, but I would prefer to have the artifact installed
to some local directory), so that it can be used for the Child Project B
from the local dir.
Any way to achieve this?
Thanks!
Wendy Smoak-3 wrote:
On Thu, Jun 25, 2009 at 7:51 AM, n000busman_r...@yahoo.com wrote:
How can I
let the Child B to know that the Child A has been build the jar is
added
to the class path while building the Child B project.
I think you answered it in your subject line. :) Add a dependency in B's
pom:
dependency
groupIdmy.group/groupId
artifactIdA/artifactId
version${project.version}/version
/dependency
--
Wendy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
View this message in context:
http://www.nabble.com/Adding-Dependency-of-other-Child-Project-tp24204718p24216869.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: how to generally skip pre and post-integration test phase
I did it now with working with profiles and profile-activation by env-var. So I don't have to give a -P option but can use the -Dskip.integration.test parameter to activate the profile, this way I don't mess around with multiple -P and -D options: profile activation property !-- trigger profile if value is false -- nameskip.integration.test/name valuefalse/value /property /activation ... /profile - aldana wrote: Wendy Smoak-3 wrote: On Thu, Jun 25, 2009 at 7:41 AM, aldanaald...@gmx.de wrote: I am controlling running integration-tests by setting a property skip.integration.test (easier as setting up an integration test profile). problem is that I also want to skip the pre-integration and post-integration phase for that (jetty start/stop plugin runs under this phases). unfortunately jetty plugin does not offer a skip parameter itself. You can't skip phases, but you can put the Jetty plugin executions into a profile, and activate that with a property. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org I know that profiles would work for that, but I wanted to avoid all these extra verbose profile definitions for this little skip distinction But I guess I have to go this path :( - manuel aldana aldana((at))gmx.de software-engineering blog: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/how-to-generally-skip-pre-and-post-integration-test-phase-tp24204569p24217268.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
AW: Special build for modules - how to?
Hi Jörg
To get this right: You've defined the plugin in the profile
section of the
parent and you try to activate it in the individual modules?
Yes
Interesting idea.
Thanks, but born out of sheer despair ;-)
I don't really know if this is how such builds are supposed to be done in
Maven...
Are you sure that it simply does not work in reactor,
because it is
looking for the file in the wrong working dir then? Did you try
exists${basedir}/jaxb.profile/exists ?
Thanks, good idea! I just tried it, just building the specific module, not the
whole project.
existsosgi-bundle.profile/exists
works:
[INFO] [compiler:compile]
[INFO] Compiling 11 source files to
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
However
exists${basedir}/osgi-bundle.profile/exists
doesn't work:
[INFO] [compiler:compile]
[INFO] Compiling 11 source files to
[INFO] [resources:testResources]
Also, to be sure, I added help:active-profiles, but this doesn't seem to work
in this case. For the successful build, it only lists the profile which is
active by default
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'ch.ipi:util-di:jar:1.0.0-SNAPSHOT':
The following profiles are active:
- local (source: settings.xml)
- local (source: settings.xml)
(and God only knows why it's listed twice...)
Best regards,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How remove exclude **/*.java from resources
Thank you, Wayne, very much. Sipungora Wayne Fay wrote: i try to get two source folders in my project. As a second source folder I'm going to use resources directory. I can set **/*.java in include. But in conflicts between include and exclude, exclude wins. You should use the build-helper-maven-plugin to add the second source directory. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://www.nabble.com/How-remove-exclude-**-*.java-from-resources-tp24184164p24217538.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: Local/proxy dependency resolution when the artifact's metadata is the same
I have it in my local repository, and it's also on the proxy repo. My colleague decides to do a very minor change to the corresponding foo Maven project, and redeploys this artifact to the proxy repository, but without changing the artifact's version. This is very explicitly not allowed if you are using Maven. If your artifact will change, it must be named -SNAPSHOT. If it is not a SNAPSHOT, then it must not change. This is part of the contract you sign when you start using Maven. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Builing Eclipse plugins with Maven2 ?
Hi, we have some Eclipse Plugin projects, that are based on libraries build with Maven. Now, I want to build these eclipse plugins with Maven, too. I´ve read about Tycho, maven-bundle-plugin, pde-maven.plugin and so on. Is there any recommendation from anyone? I don´t want to spent a lot of time in making my own experiences with all of them Thanx for any advice, if someone is also building eclipse-plugins with Maven (coming from the pom.xml side) Torsten
Re: Special build for modules - how to?
Set it up in pluginManagement instead of plugins in the parent?
On Fri, Jun 26, 2009 at 4:03 AM, Lewis, Ericeric.le...@ipi.ch wrote:
Hi
We have a build which consists of several projects which each consists of
several modules. We also have a global parent which defines how the build
works.
Now, I had the problem that some modules need special steps in their build,
e.g. JAXB2 generation, creating an OSGi module etc.
Of course, I tried to stick to the Don't Repeat Yourself principle and wanted
to administer these special steps myself, instead of leaving it to the
individual developers to copy paste the build configuration over and over.
Since including parts of XML into a POM seems to be impossible, I did it with
profiles. For example:
!-- Use this profile if you want to generate XML binding classes using
JAXB2. --
profile
idjaxb/id
build
plugins
plugin
groupIdorg.jvnet.jaxb2.maven2/groupId
artifactIdmaven-jaxb2-plugin/artifactId
executions
execution
goals
goalgenerate/goal
/goals
/execution
/executions
configuration
schemaDirectory${jaxb.schema.directory}/schemaDirectory
generatePackage${jaxb.package}/generatePackage
removeOldOutputtrue/removeOldOutput
forceRegeneratetrue/forceRegenerate
/configuration
/plugin
/plugins
/build
properties
jaxb.schema.directorysrc/main/resources/jaxb.schema.directory
jaxb.packagech.ipi.${project.artifactId}.xml/jaxb.package
/properties
/profile
Now, if a module wants to use JAXB2, it just has to specify -Pjaxb; so far,
so good.
I thought this was a nifty solution, but there's a problem with reactor
builds: Let's say that I want to build the whole project (modules A, B, C),
and module A needs JAXB generation, module B needs an OSGi build etc.
The only way I saw until recently was to specify all the profiles required by
all the modules when building the whole project. However, for some plugins,
this fails miserably, since the plugin *expects* to see certain files, and if
it doesn't have them, it breaks the build. Besides, I tell every module to do
these special steps, and they only don't execute them because some
file/directory is missing (e.g. the XML schema directory), which for me is
kind of shaky...
The best thing for me would have been to activate a profile based on a Maven
property, so I could set the property it in the module's POM. Alas, this idea
doesn't work, since Maven only activates profiles based on system properties.
Next, I tried activating using files, something like
!-- Use this profile if you want to generate XML binding classes using
JAXB2. --
profile
idjaxb/id
activation
file
existsjaxb.profile/exists
/file
/activation
...
So, module A has a file 'jaxb.profile' in its root directory, module B has
'osgi.profile' etc. This works well on an individual module level, but as
soon as I build the whole project, it's totally ignored by the reactor.
In other words, I'm stuck!
Does anyone have the same kind of build that we have and what's your
solution? Is my idea of using profiles for this a valid one or am I totally
off the Maven way?
Should I file a request for enhancement that profiles should be activated by
Maven properties?
Best regards,
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: Dependency Management
thx! That thread Told me all I needed to know! :-) Peter
AW: Special build for modules - how to?
If I understand you correctly, you suggest configuring the plugins generally in
the pluginManagement and then adding the plugin in the specific build in the
module's POM?
If so, this is too simple for my case, because for instance the OSGi profile
also reconfigures the maven-jar-plugin, since the maven-bundle-plugin creates
its own MANIFEST.MF file (an OSGi one) which means that the JAR plugin must not
create one itself, making its configuration different from the default
configuration.
Best regards,
Eric
-Ursprüngliche Nachricht-
Von: Benson Margulies [mailto:bimargul...@gmail.com]
Gesendet: Freitag, 26. Juni 2009 13:51
An: Maven Users List
Betreff: Re: Special build for modules - how to?
Set it up in pluginManagement instead of plugins in the parent?
On Fri, Jun 26, 2009 at 4:03 AM, Lewis, Ericeric.le...@ipi.ch wrote:
Hi
We have a build which consists of several projects which
each consists of several modules. We also have a global
parent which defines how the build works.
Now, I had the problem that some modules need special steps
in their build, e.g. JAXB2 generation, creating an OSGi module etc.
Of course, I tried to stick to the Don't Repeat Yourself
principle and wanted to administer these special steps
myself, instead of leaving it to the individual developers to
copy paste the build configuration over and over.
Since including parts of XML into a POM seems to be
impossible, I did it with profiles. For example:
!-- Use this profile if you want to generate XML
binding classes using JAXB2. --
profile
idjaxb/id
build
plugins
plugin
groupIdorg.jvnet.jaxb2.maven2/groupId
artifactIdmaven-jaxb2-plugin/artifactId
executions
execution
goals
goalgenerate/goal
/goals
/execution
/executions
configuration
schemaDirectory${jaxb.schema.directory}/schemaDirectory
generatePackage${jaxb.package}/generatePackage
removeOldOutputtrue/removeOldOutput
forceRegeneratetrue/forceRegenerate
/configuration
/plugin
/plugins
/build
properties
jaxb.schema.directorysrc/main/resources/jaxb.schema.directory
jaxb.packagech.ipi.${project.artifactId}.xml/jaxb.package
/properties
/profile
Now, if a module wants to use JAXB2, it just has to specify
-Pjaxb; so far, so good.
I thought this was a nifty solution, but there's a problem
with reactor builds: Let's say that I want to build the whole
project (modules A, B, C), and module A needs JAXB
generation, module B needs an OSGi build etc.
The only way I saw until recently was to specify all the
profiles required by all the modules when building the whole
project. However, for some plugins, this fails miserably,
since the plugin *expects* to see certain files, and if it
doesn't have them, it breaks the build. Besides, I tell every
module to do these special steps, and they only don't execute
them because some file/directory is missing (e.g. the XML
schema directory), which for me is kind of shaky...
The best thing for me would have been to activate a profile
based on a Maven property, so I could set the property it in
the module's POM. Alas, this idea doesn't work, since Maven
only activates profiles based on system properties.
Next, I tried activating using files, something like
!-- Use this profile if you want to generate XML
binding classes using JAXB2. --
profile
idjaxb/id
activation
file
existsjaxb.profile/exists
/file
/activation
...
So, module A has a file 'jaxb.profile' in its root
directory, module B has 'osgi.profile' etc. This works well
on an individual module level, but as soon as I build the
whole project, it's totally ignored by the reactor.
In other words, I'm stuck!
Does anyone have the same kind of build that we have and
what's your solution? Is my idea of using profiles for this a
valid one or am I totally off the Maven way?
Should I file a request for enhancement that profiles
should be activated by Maven properties?
Best regards,
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Any plugins or tools that alert users to new versions of Jars?
2009/6/26 Jörg Schaible joerg.schai...@gmx.de avixbaouxx wrote at Donnerstag, 25. Juni 2009 20:38: Basically that...I'm curious if there's a way to email or otherwise alert users that new versions of their dependencies exist at build time? Well, I could imagine such a behaviour quite annoying especially when you know that you want to use not the latest version. However, the idea is good, but it could be added as another dependency report. Which is why I asked for a JIRA to be filed against versions-maven-plugin - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Special build for modules - how to?
Lewis, Eric wrote at Freitag, 26. Juni 2009 11:36:
Hi Jörg
To get this right: You've defined the plugin in the profile
section of the
parent and you try to activate it in the individual modules?
Yes
Interesting idea.
Thanks, but born out of sheer despair ;-)
I don't really know if this is how such builds are supposed to be done in
Maven...
Are you sure that it simply does not work in reactor,
because it is
looking for the file in the wrong working dir then? Did you try
exists${basedir}/jaxb.profile/exists ?
Thanks, good idea! I just tried it, just building the specific module, not
the whole project.
existsosgi-bundle.profile/exists
works:
[INFO] [compiler:compile]
[INFO] Compiling 11 source files to
[INFO] [bundle:manifest {execution: bundle-manifest}]
[INFO] [resources:testResources]
However
exists${basedir}/osgi-bundle.profile/exists
doesn't work:
[INFO] [compiler:compile]
[INFO] Compiling 11 source files to
[INFO] [resources:testResources]
What happens if you move the activation part also to the parent? Hint: Maven
cannot activate a profile from child to parent since the profiles in the
parent have already be processed when the child is interpreted. However,
it is not clear to me if ${basedir} used in the parent is relative to the
parent's physical location or to the one of the child.
Also, to be sure, I added help:active-profiles, but this doesn't seem to
work in this case. For the successful build, it only lists the profile
which is active by default
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'ch.ipi:util-di:jar:1.0.0-SNAPSHOT':
The following profiles are active:
- local (source: settings.xml)
- local (source: settings.xml)
(and God only knows why it's listed twice...)
Don't use activeByDefault. Set it explicitly active in an activeProfiles
section. Hint: Normally a profile activated by default should be not active
if a different one is activated. However, it is not clear what another one
is activated really means: another one is activated by command line or is
activated by condition. Even worse that different maven versions do behave
differently in this respect ;-)
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: Special build for modules - how to?
What happens if you move the activation part also to the
parent? Hint: Maven
cannot activate a profile from child to parent since the
profiles in the
parent have already be processed when the child is
interpreted. However,
it is not clear to me if ${basedir} used in the parent is
relative to the
parent's physical location or to the one of the child.
Ok, so as I described, we have the master POM, then as a child we have the
project POM and then every module of course has its POM.
The problem is that the activation of the profile is in the master POM already,
since I don't want to reconfigure it several times.
So the only place to activate it would be the project POM, but as you write,
it's not possible to do that.
I don't think it's possible to configure a profile in some POM and then
reference it (for instance for activation) in a child POM. But I could be
wrong... :-)
As for ${basedir}, according to some discussions I read in the mailing list
archive, Maven properties are not resolved in profiles.
Also, to be sure, I added help:active-profiles, but this
doesn't seem to
work in this case. For the successful build, it only lists
the profile
which is active by default
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'ch.ipi:util-di:jar:1.0.0-SNAPSHOT':
The following profiles are active:
- local (source: settings.xml)
- local (source: settings.xml)
(and God only knows why it's listed twice...)
Don't use activeByDefault. Set it explicitly active in an
activeProfiles
section. Hint: Normally a profile activated by default should
be not active
if a different one is activated. However, it is not clear
what another one
is activated really means: another one is activated by
command line or is
activated by condition. Even worse that different maven
versions do behave
differently in this respect ;-)
Thanks, I'm going to try this one of these days.
Best regards,
Eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Authentication error missing from Maven
Hi, We have some external developer around the world, so I have enabled the security in Nexus and it works fine. Every developer need to setup his own maven/ settings.xml and I have to trust that this will be correct. But for some reason it can be happen that he will enter wrong password or username. When he try now to deploy some stuff, maven gives a partial error message because: Downloading: http://:8081/nexus/content/groups/public/junit/junit/3.8... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Sniffing the traffic will show the more important part of the errror (in my mind) GET /nexus/content/groups/public/junit/junit/3.8.1/junit-3.8.1.jar HTTP/1.1 Accept-Encoding: gzip Pragma: no-cache User-Agent: Java/1.6.0_13 Host: :8081 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive HTTP/1.1 401 Unauthorized WWW-Authenticate: BASIC realm=Sonatype Nexus Repository Manager Content-Length: 0 Server: Jetty(6.1.11) Is this a bug or a feature, or with other words how can I make it possible that the user see the whole error. Thanks for your support -- View this message in context: http://www.nabble.com/Authentication-error-missing-from-Maven-tp24219912p24219912.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: how to generally skip pre and post-integration test phase
Wayne Fay wrote: unfortunately jetty plugin does not offer a skip parameter itself. You could also work with the Jetty plugin people to add a skip parameter... Wayne Filed a ticket: http://jira.codehaus.org/browse/JETTY-1051. - manuel aldana aldana((at))gmx.de software-engineering blog: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/how-to-generally-skip-pre-and-post-integration-test-phase-tp24204569p24220046.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
Newbie question - Resuming lifecycles
Hello everyone, My team has been evaluating Maven as a solution for a data-processing pipeline. I've created a prototype of what our project would look like, and it includes a Mojo plug-in and a custom default lifecycle. My question regards resuming failed runs: If a goal inside the plugin throws an exception and fails, will the entire lifecycle be repeated when I re-execute the lifecycle? Will it know not to execute previous successful goals, or do I need to design each goal so that it checks if its output already exist? Please keep in mind that I'm using a custom packaging/lifecycle, if it makes a difference. Resume is an important function in our case, since the pipeline has many fail points out of our control, and some goals can take days to execute. Thank you! -- View this message in context: http://www.nabble.com/Newbie-question---Resuming-lifecycles-tp24220125p24220125.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: passing through -D params from CLI to other plugins
filed a ticket: http://jira.codehaus.org/browse/SUREFIRE-554
Stephen Connolly-2 wrote:
afaik, it is surefire that forks the jvm, so surefire is where I would
file the jira
if you roll your surefire version back to perhaps 2.3 you'd see the
system properties being passed through
Sent from my [rhymes with myPod] ;-)
On 24 Jun 2009, at 22:49, aldana ald...@gmx.de wrote:
I also think this would be a nice enhancement.
You mentioned filing JIRA ticket against surefire-plugin, but isn't
this
more related to the maven core handling of -D envs and is better
placed in
maven2-JIRA?
Stephen Connolly-2 wrote:
what I think would be a good idea is allowing the specification of a
list of regexs to match properties to pass through and a list of
regexs to match properties to exclude... with exclude taking priority
over include, and exclude having a default set to exclude the pain
points that drove the properties not being passed through in the
first
place
perhaps you could file a JIRA for such an enhancement
-Stephen
P.S. file it against surefire... i'll be picking up all changes to
maven-surefire-plugin and applying them to failsafe-maven-plugin when
surefire next rolls a release
2009/6/24 aldana ald...@gmx.de:
I see
but at least I won't forget this, it took me a while to find out why
passing
-D params on the CLI did not have any effect on my plugin-setting.
Stephen Connolly-2 wrote:
none that I know... the passthrough that used to happen
previously was
AFAIK considered a bug...
also consider that you need to purge certain properties from
passthrough, e.g. java debugger port to bind to
-Stephen
2009/6/24 aldana ald...@gmx.de:
when doing a:
mvn verify -DanyParam=true
anyParam property is available inside pom.xml, but not passed
through
to
my
running test-suite in surefire or failsafe plugin, which is very
annoying
because I have to manuall pass through these vars (by defining
custom
properties in pom and referring it with ${xxx}).
Is there a way in maven to tell plugins to pass through all -D
parameters
to
other fork processes (like test runnings)? Or is there a special
surefire
plugin setting for this?
thanks.
-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
--
View this message in context:
http://www.nabble.com/passing-through--D-params-from-CLI-to-other-plugins-tp24188981p24188981.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
-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
--
View this message in context:
http://www.nabble.com/passing-through--D-params-from-CLI-to-other-plugins-tp24188981p24189359.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
-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
--
View this message in context:
http://www.nabble.com/passing-through--D-params-from-CLI-to-other-plugins-tp24188981p24193517.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
-
manuel aldana
aldana((at))gmx.de
software-engineering blog: http://www.aldana-online.de
--
View this message in context:
http://www.nabble.com/passing-through--D-params-from-CLI-to-other-plugins-tp24188981p24220209.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: Order of Execution For Classes Included In A Surefire Plugin Execution
Thanks I am attempting to avoid any additional Java coding, though a Java test-suite file is fairly simple code and easy to maintain. I think you are right that surefire runs the test classes in the order it finds them. In fact failsafe runs the classes in the same order as surefire, not surprising since the failsafe code is a branch off of surefire. I am puzzled on how surefire/failsafe finds the files to test. I am running Windows XP and a directory listing from a cmd window shows 06/26/2009 10:15 AM 7,481 cleanupQA3.java 06/24/2009 03:41 PM35,593 QA3.java 06/24/2009 03:32 PM 8,761 SAM.java However both surefire and failsafe run the test classes in this order: QA3, cleanupQA3, SAM. That order is not by date, filename or size Bill Josephson Cengage Learning -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Friday, June 26, 2009 1:23 AM To: Maven Users List Subject: Re: Order of Execution For Classes Included In A Surefire Plugin Execution A couple of points: 1. Have you considered using failsafe-maven-plugin to run your integration tests? That way you can set up your integration test env using pre-integration-test phase, tear it down in post-integration-test phase and then check the results in the verify phase... it might simplify your surefire plugin config as well. 2. I think the philosophy of surefire is that it will run test classes in the order that it finds them. If you need to run test classes in a specific order, you need to create a test suite. -Stephen 2009/6/25 Josephson, William (APG) william.joseph...@cengage.com: I am using Maven 2.1.0, and the surefire plugin to run integration tests. I have the following execution element within my pom: execution idfirst/id phaseintegration-test/phase goals goaltest/goal /goals configuration includes include**\SAM.java/include include**\QA3.java/include include**\cleanupQA3.java/include /includes skipfalse/skip /configuration /execution I would expect that the tests within class SAM would be executed first, followed by the tests in class QA3 etc. But instead the tests in class QA3 are performed first. Shouldn't the tests be performed at least in the order that the classes are declared? Thanks, Bill Josephson Cengage Learning - 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
Valid id pattern
Hi,
this is my project structure:
parent
child1 child2
child11 child22
child11 depends from child22. Which is valid id pattern for this?
I thought ${parent.parent.artifactId}, but this doesn't work.
Thanks in advance.
--
View this message in context:
http://www.nabble.com/Valid-id-pattern-tp24221893p24221893.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: Packaging and artifact extension.
Perhaps this question was more appropriate to the dev list. Anyway, I figure out how and wanted to share it with you in case someone ever needs something like this. The mistery is in defining a new ArtifactHandler to provide the desired extension. This artifact handler will have to be declared in the components.xml file for the plugin. Hope it helps someone in the future. cheers. On Thu, Jun 25, 2009 at 11:28 AM, Erick Dovale edov...@gmail.com wrote: Folks, How could I have the artifact of a project use an extension different that the packaging name? I am writing a plugin that creates a zip file with content relevant to a particular application. I created a new packaging type called 'mypackaging' and it turns out that maven is installing a file called artifact-version.mypackaging. I need to have maven installed this file as a zip. Any ideas? Thanks. Erick.
Re: Adding Dependency of other Child Project
On Fri, Jun 26, 2009 at 1:40 AM, n000busman_r...@yahoo.com wrote: Thanks for your reply Wendy. I did try the same, but maven cannot resolve the artifact. Do I need to install the artifact somewhere (we are using an archiva online repository, but I would prefer to have the artifact installed to some local directory), so that it can be used for the Child Project B from the local dir. Any way to achieve this? What are you doing now, and what does the project structure look like? The dependency snippet I provided assumes that you have a parent pom above the two children. If so, then building from the top (from the directory with the parent pom) should work. Try 'mvn install' in A and then in B. This will install the artifacts into your local repository and they will be available for you to use when building other projects. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Valid id pattern
Hi,
this is my project structure:
parent
child1 child2
child11 child22
child11 depends from child22. How can I access my parent from child11?
I thought with ${parent.parent.artifactId}, but this doesn't work. Which is
valid id pattern for this?
Thanks in advance.
--
View this message in context:
http://www.nabble.com/Valid-id-pattern-tp24222135p24222135.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
This might be the easiest filter question you have ever seen
This might be the easiest filter question you have ever seen... I want to filter a properties file located related to the pom under /src/main/conf/db2was/com/silvermoongroup/fsa/jndi.properties, so I added the following entry: build resources resource directorysrc/main/conf/db2was/directory includes include**/*.properties/include /includes filteringtrue/filtering /resource /resources ... When I run this, the properties file is not filtered, but it shows up where I expect it: target\smg-iaa-fsa-web-1.0\WEB-INF\classes\com\silvermoongroup\fsa Now, when I set up the resource directory slightly incorrectly, and instead specify: directorysrc/main/conf/db2was/com/silvermoongroup/fsa/directory The properties file does get filtered! However, it shows up in target/classes which is the default and of course not desired. Any clues what I am doing wrong here? I must be doing something really stupid; which is why I can't figure it out! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
David Hoffer wrote: The resources is a standard maven folder and will be included in the build/jar/war/etc. Unfortunately there is no standard for the external stuff, you can put those in a different folder and then use the assembly or similar plugin to deal with them. -Dave On Thu, Jun 25, 2009 at 2:19 PM, sundar varadarajan sundarva...@gmail.comwrote: Hello, I m new to Maven and I m trying to place property and config.xml files outside the Jar files. Here is my current directory Src main java resources test java resources under java, i have all the java class files and in resources folder i have the properties and springbatch xml files. when i package the application, the property files which are under src/main/resources is also getting included. I need to place this outside the jar file so that the application can pickup when ever i make any changes to the property. currently i need to package again whenever a small change is made. please help. Thanks, Sundar -- View this message in context: http://n2.nabble.com/Maven---Property-files-Question-tp3159654p3162714.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 - Property files Question
By default, the resources:resources lifecycle automatically copies
everything in the resources folder over to the target/classes folder
when it builds the war or jar.
In order to avoid this, you need to move your property files to
another folder, or if that's not possible, configure the
resources:resources step to skip these files. I recommend that you
create another folder like src/main/properties and stick your property
files in there.
See
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html
for information on skipping packaging certain files in your jar/war.
You will also need the assembly plugin to package your war with your
properties files as maybe a zip or tarball. See
http://maven.apache.org/plugins/maven-assembly-plugin/ for
information about the assembly plugin.
Assemblies took me a while to understand. Basically, you create (by
convention) a folder called src/main/assemblies, and you define your
assembly XML files in there. You could have multiple ways of
packaging. For example, you might have one that includes only the
files you install while another includes some documents or source
files.
Normally, you call the assembly XML bin.xml, and the final package
will be something like foo-1.3-bin.zip. That is, this is version 1.3
of artifact foo, and this is a zip file built by the bin assembly.
You could have things like foo-1.3-src.zip, etc.
Then, in your pom.xml, you have to define where the assembly files are
located, and you might also want to modify the lifecycle, so that your
assemblies are built when you do the mvn package. Otherwise, you'll
have to run mvn assembly:assembly.
To give you a better idea, this is what I have in my project's pom.xml
file under the plugins section:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-3/version
configuration
descriptors
descriptorsrc/main/assemblies/bin.xml/descriptor
/descriptors
/configuration
executions
execution
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
The descriptor defines where my assembly file lives, and I could
have multiple descriptors.
The executions defines that my assembly should be built in the
package phase, so I don't have to remember to run mvn
assembly:assembly in order to build the assembly.
The assembly itself is pretty simple:
assembly
idbin/id
formats
formattar.gz/format
/formats
baseDirectory${artifactId}-${version}/baseDirectory
includeSiteDirectoryfalse/includeSiteDirectory
dependencySets
dependencySet
outputDirectorylib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
/dependencySet
/dependencySets
fileSets
fileSet
directorysrc/main/bin/directory
outputDirectorybin/outputDirectory
lineEndinglf/lineEnding
fileMode0755/fileMode
includes
include**/include
/includes
/fileSet
fileSet
directorysrc/main/config/directory
outputDirectoryclient/${client}/config/outputDirectory
lineEndinglf/lineEnding
fileMode0644/fileMode
includes
include**/include
/includes
/fileSet
/fileSets
/assembly
Hope this helps.
On Thu, Jun 25, 2009 at 4:19 PM, sundar
varadarajansundarva...@gmail.com wrote:
Hello,
I m new to Maven and I m trying to place property and config.xml files
outside the Jar files. Here is my current directory
Src
main
java
resources
test
java
resources
under java, i have all the java class files and in resources folder i have
the properties and springbatch xml files.
when i package the application, the property files which are under
src/main/resources is also getting included. I need to place this outside
the jar file so that the application can pickup when ever i make any changes
to the property. currently i need to package again whenever a small
Re: Logging Plugin Version Without Debug -X Mode
When I try:
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
The resulting string is null...
On Thu, Jun 25, 2009 at 9:04 PM, Mohan KRkmoh@gmail.com wrote:
Why don't you inject a parameter with expression ${plugin.version} in the
Mojo and
use the info level to log it? Don't know if that's what you are asking...
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Thursday, June 25, 2009 3:44 PM
To: users@maven.apache.org
Subject: Logging Plugin Version Without Debug -X Mode
Hello:
I am trying to find how to log the plugin version when running my plugin.
The reason I ask is that my plugin version is not explicitly set so
maven will bring down a new version with the default daily interval
(hopefully).
The question I have is how can I get the plugin version currently
running inside the mvn reaction without running in debug mode -X.
Any help is greatly appreciated.
Cheers,
Christiaan
-
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 - Property files Question
Hi Dave, Thanks for your reply. I m not trying to place resources folder outside the jar. I m trying to place the properties file that reside in resources folder outside the jar so that my application can pickup. What should i modify in my pom.xml? Thanks, Sundar On 6/25/09, sundar varadarajan sundarva...@gmail.com wrote: Hello, I m new to Maven and I m trying to place property and config.xml files outside the Jar files. Here is my current directory Src main java resources test java resources under java, i have all the java class files and in resources folder i have the properties and springbatch xml files. when i package the application, the property files which are under src/main/resources is also getting included. I need to place this outside the jar file so that the application can pickup when ever i make any changes to the property. currently i need to package again whenever a small change is made. please help. Thanks, Sundar
bug? strange resolution of commons-logging dependency
I ran into a strange dependency resolution problem at work, which a
colleague and I whittled down to a fairly simple test case. Consider
the following POM:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.example/groupId
artifactIdhtmlunitbug/artifactId
packagingjar/packaging
version2.71828/version
build
pluginManagement
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/pluginManagement
/build
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.6/version
scopetest/scope
/dependency
dependency
groupIdnet.sourceforge.htmlunit/groupId
artifactIdhtmlunit/artifactId
version2.5/version
scopetest/scope
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-ehcache/artifactId
version3.3.1.GA/version
scoperuntime/scope
/dependency
!-- hibernate-ehcache depends on a very old version. --
dependency
groupIdnet.sf.ehcache/groupId
artifactIdehcache/artifactId
version1.6.0/version
scoperuntime/scope
/dependency
/dependencies
/project
And, consider the following test class:
import com.gargoylesoftware.htmlunit.WebClient;
import org.junit.Test;
public class MyTest {
@Test public void test() { new WebClient(); }
}
Running this test with Maven 2.1.0 fails:
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
[ ... ]
The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
(compile-scope) dependency, so this seems wrong. There seems to be
some interaction between that POM and the dependent POMs. Indeed:
1. Moving the htmlunit dependency element below the
hibernate-ehcache and ehcache dependency elements causes
commons-logging to be a test-scope dependency, and the test
succeeds. This seems bizarre. Should the ordering of dependency
elements ever matter?
2. Adding an exclusion of commons-logging to the hibernate-ehcache
dependency causes the test to succeed. I tried this, because the
hibernate-ehcache POM depends on commons-logging version
99.0-does-not-exist, a rather famous JBoss kludge[1].
3. Removing the dependency on hibernate-ehcache causes the test to
succeed. This is perhaps not surprising, in light of (2).
4. Removing the dependency on ehcache causes the test to succeed.
This is very strange to me, since ehcache directly depends on
commons-logging 1.0.4; it contains no funny business.
Am I doing something wrong here? I'll be happy to follow this through
with a JIRA ticket, if somebody here can convince me that I haven't
done anything stupid; I'm not a very confident Maven user.
Best,
-- Lucas
Footnotes:
[1]
http://day-to-day-stuff.blogspot.com/2007/10/announcement-version-99-does-not-exist.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Where an artefact is being brought
Hello, I've got a multi-module project (more then 100 modules). Is it possible having the same result of the maven-dependency-plugin's tree goal on the Maven site. (http://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html). I want to know where an artefac is being brought. Thanks. Rémy -- View this message in context: http://www.nabble.com/Where-an-artefact-is-being-brought-tp24224988p24224988.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: bug? strange resolution of commons-logging dependency
Lucas Bergman wrote:
I ran into a strange dependency resolution problem at work, which a
colleague and I whittled down to a fairly simple test case. Consider
the following POM:
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.example/groupId
artifactIdhtmlunitbug/artifactId
packagingjar/packaging
version2.71828/version
build
pluginManagement
plugins
plugin
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/pluginManagement
/build
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.6/version
scopetest/scope
/dependency
dependency
groupIdnet.sourceforge.htmlunit/groupId
artifactIdhtmlunit/artifactId
version2.5/version
scopetest/scope
/dependency
dependency
groupIdorg.hibernate/groupId
artifactIdhibernate-ehcache/artifactId
version3.3.1.GA/version
scoperuntime/scope
/dependency
!-- hibernate-ehcache depends on a very old version. --
dependency
groupIdnet.sf.ehcache/groupId
artifactIdehcache/artifactId
version1.6.0/version
scoperuntime/scope
/dependency
/dependencies
/project
And, consider the following test class:
import com.gargoylesoftware.htmlunit.WebClient;
import org.junit.Test;
public class MyTest {
@Test public void test() { new WebClient(); }
}
Running this test with Maven 2.1.0 fails:
java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
[ ... ]
The POM for htmlunit 2.5 declares commons-logging 1.1.1 as a
(compile-scope) dependency, so this seems wrong. There seems to be
some interaction between that POM and the dependent POMs.
By default commons-logging tries to discover the logger in use on its own.
Somehow a log4j is available from somewhere else, but the classpath does
not match. Therefore disable the discovery by either providing a
commons-logging.properties file in src/test/resources or set a system
property in the surefire configuration for your tests.
See
http://commons.apache.org/logging/commons-logging-1.1.1/guide.html#Configuration
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven - Property files Question
How about src/main/filters?
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
From: David Weintraub qazw...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Friday, June 26, 2009 1:33:52 PM
Subject: Re: Maven - Property files Question
By default, the resources:resources lifecycle automatically copies
everything in the resources folder over to the target/classes folder
when it builds the war or jar.
In order to avoid this, you need to move your property files to
another folder, or if that's not possible, configure the
resources:resources step to skip these files. I recommend that you
create another folder like src/main/properties and stick your property
files in there.
See
http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html
for information on skipping packaging certain files in your jar/war.
You will also need the assembly plugin to package your war with your
properties files as maybe a zip or tarball. See
http://maven.apache.org/plugins/maven-assembly-plugin/ for
information about the assembly plugin.
Assemblies took me a while to understand. Basically, you create (by
convention) a folder called src/main/assemblies, and you define your
assembly XML files in there. You could have multiple ways of
packaging. For example, you might have one that includes only the
files you install while another includes some documents or source
files.
Normally, you call the assembly XML bin.xml, and the final package
will be something like foo-1.3-bin.zip. That is, this is version 1.3
of artifact foo, and this is a zip file built by the bin assembly.
You could have things like foo-1.3-src.zip, etc.
Then, in your pom.xml, you have to define where the assembly files are
located, and you might also want to modify the lifecycle, so that your
assemblies are built when you do the mvn package. Otherwise, you'll
have to run mvn assembly:assembly.
To give you a better idea, this is what I have in my project's pom.xml
file under the plugins section:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-3/version
configuration
descriptors
descriptorsrc/main/assemblies/bin.xml/descriptor
/descriptors
/configuration
executions
execution
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
The descriptor defines where my assembly file lives, and I could
have multiple descriptors.
The executions defines that my assembly should be built in the
package phase, so I don't have to remember to run mvn
assembly:assembly in order to build the assembly.
The assembly itself is pretty simple:
assembly
idbin/id
formats
formattar.gz/format
/formats
baseDirectory${artifactId}-${version}/baseDirectory
includeSiteDirectoryfalse/includeSiteDirectory
dependencySets
dependencySet
outputDirectorylib/outputDirectory
unpackfalse/unpack
scoperuntime/scope
/dependencySet
/dependencySets
fileSets
fileSet
directorysrc/main/bin/directory
outputDirectorybin/outputDirectory
lineEndinglf/lineEnding
fileMode0755/fileMode
includes
include**/include
/includes
/fileSet
fileSet
directorysrc/main/config/directory
outputDirectoryclient/${client}/config/outputDirectory
lineEndinglf/lineEnding
fileMode0644/fileMode
includes
include**/include
/includes
/fileSet
/fileSets
/assembly
Hope this helps.
On Thu, Jun 25, 2009 at 4:19 PM, sundar
varadarajansundarva...@gmail.com wrote:
Hello,
I m new to Maven and I m trying to place property and config.xml files
outside the Jar files. Here is my current directory
Src
main
java
resources
test
java
resources
under java, i have all the java class files and in resources folder i have
the
OutOfMemoryError when deploying large files
When deploying a large artifact we get the OutOfMemoryError (please check the attached stack trace). This is similar to error reported here: http://www.mail-archive.com/users@maven.apache.org/msg99157.html We traced the issue to wagon-http-lightweight using PosterOutputStream/ByteArrayOutputStream.write(). This method consumes lot of memory when dealing with large files as reported here: https://issues.alfresco.com/jira/browse/ETHREEOH-974 In our case, we are trying to deploy a around 600M file and have set the maximum heap space to 1024M (-Xmx1024m). We are still running out of memory. We are using maven 2.0.8 but had the same issue when tried with 2.1.0 version. Is there a way to use another Wagon provider (wagon-http ?) that can deal better with large files? If yes, how can we configure this? Should I raise a jira for this (against which component maven-deploy-plugin or wagon-http-lightweight)? Thanks, -Rakesh ;-STACK TRACE- [DEBUG] -- end configuration -- [INFO] [deploy:deploy-file] Uploading: http://repo_url/group/foo/1.0/foo-1.0.zip [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Java heap space [INFO] [DEBUG] Trace java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:338) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:305) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:267) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:2 38) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:143) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.put(Lightw eightHttpWagon.java:148) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(D efaultWagonManager.java:237) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(Def aultWagonManager.java:153) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(Def aultArtifactDeployer.java:80) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo. java:240) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) 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) [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jun 26 15:10:36 EDT 2009 [INFO] Final Memory: 4M/1016M [INFO]
RE: Logging Plugin Version Without Debug -X Mode
Hi, my mail client looks like messed up the formatting. Also I am assuming
that you do
have the maven-plugin-plugin configured, right?
/**
* @parameter expression=${plugin.version}
*
*/
private String pluginVersion;
Notice the quotes around the expression. I have been using this for my own
plugin and
it does work..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Friday, June 26, 2009 12:36 PM
To: Maven Users List
Subject: Re: Logging Plugin Version Without Debug -X Mode
When I try:
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
The resulting string is null...
On Thu, Jun 25, 2009 at 9:04 PM, Mohan KRkmoh@gmail.com wrote:
Why don't you inject a parameter with expression ${plugin.version} in the
Mojo and
use the info level to log it? Don't know if that's what you are asking...
/**
* @parameter expression=${plugin.version}
*/
private String pluginVersion;
..
Thanks,
mohan kr
-Original Message-
From: Christiaan Veerman [mailto:christiaan.veerman.ma...@gmail.com]
Sent: Thursday, June 25, 2009 3:44 PM
To: users@maven.apache.org
Subject: Logging Plugin Version Without Debug -X Mode
Hello:
I am trying to find how to log the plugin version when running my plugin.
The reason I ask is that my plugin version is not explicitly set so
maven will bring down a new version with the default daily interval
(hopefully).
The question I have is how can I get the plugin version currently
running inside the mvn reaction without running in debug mode -X.
Any help is greatly appreciated.
Cheers,
Christiaan
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Builing Eclipse plugins with Maven2 ?
On Fri, Jun 26, 2009 at 9:09 PM, torsten.reinh...@gi-de.com wrote: Hi, we have some Eclipse Plugin projects, that are based on libraries build with Maven. Now, I want to build these eclipse plugins with Maven, too. I´ve read about Tycho, maven-bundle-plugin, pde-maven.plugin and so on. Is there any recommendation from anyone? I don´t want to spent a lot of time in making my own experiences with all of them Thanx for any advice, if someone is also building eclipse-plugins with Maven (coming from the pom.xml side) Torsten pde will work (I have used it) but there is no longer a maintainer for that project. It is also a bit tedious to sort out getting it working. tycho is meant to be the better replacement but I have not tried it (and it didn't look obvious how to use it). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Newbie question - Resuming lifecycles
On Fri, Jun 26, 2009 at 10:48 PM, alexischrale...@thenull.net wrote: Hello everyone, My team has been evaluating Maven as a solution for a data-processing pipeline. I've created a prototype of what our project would look like, and it includes a Mojo plug-in and a custom default lifecycle. My question regards resuming failed runs: If a goal inside the plugin throws an exception and fails, will the entire lifecycle be repeated when I re-execute the lifecycle? Will it know not to execute previous successful goals, or do I need to design each goal so that it checks if its output already exist? Maven will *re-run* the lifecyle. Any goals that successfully worked before the exception was thrown will be re-run. It is therefore important to ensure those goals have some sort of smarts to avoid regenerating artifacts that do not need it. i.e. timestamp checking, etc. Please keep in mind that I'm using a custom packaging/lifecycle, if it makes a difference. Resume is an important function in our case, since the pipeline has many fail points out of our control, and some goals can take days to execute. Have a look at the release plugin, especially the prepare goal. This plugin manages its own lifecycle stages within that goal. They are not real maven lifecycles but rather resumable steps of the prepare goal. You may be able to leverage of that knowledge to allow you to build your mojo in a similar manner. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Failed to validate an ostensibly valid pom
dgr...@dgreen-desktop:~/redacted_renovation/workspace/dto$ mvn compileb
[WARNING] POM for 'com.redacted:utility:pom:1.0:compile' is invalid. It will
be ignored for artifact resolution. Reason: Failed to validate POM for
project com.redacted:utility at Artifact
[com.redacted:utility:pom:1.0:compile]
Downloading:
http://10.1.102.139:8081/artifactory/repo/org/apache/maven/doxia/doxia-converter/1.1-SNAPSHOT/doxia-converter-1.1-SNAPSHOT.pom
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 4 seconds
[INFO] Finished at: Fri Jun 26 19:52:22 EDT 2009
[INFO] Final Memory: 8M/16M
[INFO] ---
Notice the warning regarding com.redacted:utility:pom:1.0. However I can
compile com.redacted:utility without any complaints. I can also do a compile
of the parent pom.
dto/pom.xml:
?xml version=1.0 encoding=UTF-8?
project
parent
groupIdcom.redacted/groupId
artifactIdmaven/artifactId
version1.0/version
relativePath../maven/pom.xml/relativePath
/parent
modelVersion4.0.0/modelVersion
artifactIddto/artifactId
name${artifactId}/name
url../../${artifactId}/target/site/url
version1.0/version
descriptionDTO/description
dependencies
dependency
groupIdcom.redacted/groupId
artifactIdutility/artifactId
version1.0/version
/dependency
/dependencies
/project
And the one of utility/pom.xml
?xml version=1.0 encoding=UTF-8?
project
parent
groupIdcom.redacted/groupId
artifactIdmaven/artifactId
version1.0/version
relativePath../maven/pom.xml/relativePath
/parent
modelVersion4.0.0/modelVersion
artifactIdutility/artifactId
name${artifactId}/name
url../../${artifactId}/target/site/url
version1.0/version
descriptionUtility/description
/project
--
View this message in context:
http://www.nabble.com/Failed-to-validate-an-ostensibly-valid-pom-tp24229127p24229127.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
m2eclipse+galileo: index issue?
fresh install of galileo + m2eclipse, getting: 6/26/09 10:32:54 PM EDT: Error on adding indexing context http://repo1.maven.org/maven2/; read past EOF 6/26/09 10:32:56 PM EDT: Maven Builder: FULL_BUILD 6/26/09 10:32:59 PM EDT: Updating index http://repo1.maven.org/maven2/ 6/26/09 10:32:59 PM EDT: No index update available for http://repo1.maven.org/maven2/ - in the (maven) console, and then when i go to the add dependency panel of the pom editor dependencies panel and i punch in something like commons, i get (0) hits... this is on my corporate laptop, strange thing is on my personal laptop i don't have this issue. any suggestions on how to troubleshoot...? any guidance appreciated! -- View this message in context: http://n2.nabble.com/m2eclipse%2Bgalileo%3A-index-issue--tp3165039p3165039.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: m2eclipse+galileo: index issue?
forgot to mention, the other potentially relevant detail is that this also seems to work fine from ganymede on my corporate laptop... 6/26/09 10:46:23 PM EDT: Updating index http://repo1.maven.org/maven2/ 6/26/09 10:46:27 PM EDT: Downloading central : nexus-maven-repository-index.properties 6/26/09 10:46:27 PM EDT: Downloaded [central] - http://repo1.maven.org/maven2/.index/nexus-maven-repository-index.properties 6/26/09 10:46:27 PM EDT: Updated index for http://repo1.maven.org/maven2/ Sat Jun 20 04:27:25 EDT 2009 tony_k wrote: fresh install of galileo + m2eclipse, getting: 6/26/09 10:32:54 PM EDT: Error on adding indexing context http://repo1.maven.org/maven2/; read past EOF 6/26/09 10:32:56 PM EDT: Maven Builder: FULL_BUILD 6/26/09 10:32:59 PM EDT: Updating index http://repo1.maven.org/maven2/ 6/26/09 10:32:59 PM EDT: No index update available for http://repo1.maven.org/maven2/ - in the (maven) console, and then when i go to the add dependency panel of the pom editor dependencies panel and i punch in something like commons, i get (0) hits... this is on my corporate laptop, strange thing is on my personal laptop i don't have this issue. any suggestions on how to troubleshoot...? any guidance appreciated! -- View this message in context: http://n2.nabble.com/m2eclipse%2Bgalileo%3A-index-issue--tp3165039p3165073.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: m2eclipse+galileo: index issue? (solved)
i read somewhere about the the initial m2eclipse updating indexes phase taking a half hour and i recalled that i actually forcefully stopped that phase in eclipse by clicking the red button to the right of the progress bar. so on a lark, i reinstalled galileo and then m2eclipse and this time let the updating indexes phase run to completion (it actually did take about a half hour) and then things seemed ok. i must have corrupted something when i killed the index update in mid stream, so beware... is it normal to take that long, or is it possible that something about galileo is making that process suck wind? anyway just wanted to share in case anyone else gets plagued with this issue... party on! -- View this message in context: http://n2.nabble.com/m2eclipse%2Bgalileo%3A-index-issue--tp3165039p3165318.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
