Hi everyone,
currently I try to copy some files with the maven-resources-plugin. Is
there any chance to get rid of the /target/ folder during the copy of
files? I'm using the following lines:
resource
filteringtrue/filtering
directory${basedir}/src/site/directory
I have hit this bug
http://jira.codehaus.org/browse/MNG-4809
Quoting it,
We cannot specify variables to define a system path. Maven complains about
absolute path. This is a pain which forces us to either hard code the path
or use -DlocalRepository flag.
Is there a way to use settings from
I'm guessing that there is some jar missing in remote (Internet)
repositories, which you're adding to your local repo to solve this. And then
using system scope for your dependency. Right?
The solution is then to get a repository manager and upload the missing
artifact to it (making it available
2011/1/25 martin krüger brainm...@googlemail.com:
currently I try to copy some files with the maven-resources-plugin. Is
there any chance to get rid of the /target/ folder during the copy of
files? I'm using the following lines:
resource
filteringtrue/filtering
Looks a little strange to me, trying to do this kind of copy action
using the POMs build resources configuration. I'd suggest to use the
'resources:copy-resources' goal:
http://maven.apache.org/plugins/maven-resources-plugin/examples/copy-resources.html.
The 'outputDirectory' parameter should
+1 to Benson, is what we did on Google Doclava[1] to make the build
working on Google team's Ubuntu and my Mac.
just my 2cents,
Simo
[1] http://code.google.com/p/doclava/source/browse/trunk/pom.xml
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Jan 24, 2011 at 11:59
Hi all,
I'm sure I missed something, but when running integration tests using
maven-invoker-plugin, even if integration tests fail, the build
doesn't :(
This[1] is the plugin configuration and the related output[2] I can
get after ran `mvn clean integration-test`
Any hint would be much more than
Never ever run the goals
pre-integration-test
integration-test
post-integration-test
directly from the command line
to run integration tests use
mvn verify
the best practice for using the integration-test phase is to not fail
the build in that phase and defer checking the integration test
gotcha!!! just tried your suggestion and worked, kudos to you! :)
thanks a lot, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jan 25, 2011 at 11:51 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Never ever run the goals
Anders,
Is what you propose possible without repeating the War files? ie, I
currently have *one* WAR project, where I have all the xml, jsp and java
files for the web app.
The only difference between the development and production environments is a
few configs like: on line in the database.xml
2011/1/25 Miguel Almeida migueldealme...@gmail.com:
Is what you propose possible without repeating the War files? ie, I
currently have *one* WAR project, where I have all the xml, jsp and java
files for the web app.
The only difference between the development and production environments is a
On Tue, Jan 25, 2011 at 11:18 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
No, he means (correct me if I am wrong) that you should have a war for
each web application you have. Since you have *one* web application,
one war is ok.
Configuration like IP addresses, ports, etc. should
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing this, including using JNDI or putting a properties file on the
classpath.
I understand this would require changes to your code base. Major changes
possibly. But it is the right way to go. Once
Anders,
I think I understand what you mean, but it doesn't seem to be very different
from the current approach.
On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar and...@hammar.net wrote:
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing
+1 for using external 'properties'
Usually you like to produce only one WAR file and use exactly this single WAR
file on your test box, move it further to the integration test server and then
move it to the production server. The SHA-1 of the WAR _must_not_ change! If
you need to rebuild a
Ok, I see where we misunderstand each other.
What you want to do is to build just one war. This war should not include
any environment configuration at all! Environment dependent configuration
should be handled outside of the war.
One way to do this is to always load config file from the
According to the documentation:
http://maven.apache.org/plugins/maven-release-plugin/examples/lock-files
.html
Am I right in assuming that I'd be able to lock files during a release
with:
release:prepare -DuseEditMode=true
so that nobody could commit files/directories during the
Hi
I'm working on corporate pom and I would keep common corporate pom
version for Maven 2 and Maven 3. But I can't configure site deployment
with scp wagon provider for Maven 2 and 3.
To avoid interaction during scp deployment I configured server with
NullKnownHostProvider in settings.xml.
Hello
Sounds an issue.
Please load an entry in jira (with the details).
We will have a look.
Thanks!
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
2011/1/25 Marcin Kuthan marcin.kut...@gmail.com:
Hi
I'm working on corporate pom and I would keep common corporate
For the NPE in m3, this has just been filed:
http://jira.codehaus.org/browse/MSITE-546
For m2, I'm not sure I understand you correctly, first you say it works,
then you say it doesn't with the ssh extension (which you shouldn't need
for scp). Maybe it's a version incompatibility, the
On 24/01/2011 6:28 PM, Guo Du wrote:
On Mon, Jan 24, 2011 at 5:41 AM, Anders Hammarand...@hammar.net wrote:
You could be somewhat aided by the procurement feature of Nexus Pro (the
commercial edition of the Nexus repo manager):
http://www.sonatype.com/books/nexus-book/reference/procure.html
MSITE-546 defines exactly what I observed, NPE when configuration is
provided. At this moment this issue blocks me to use Maven 3. Site
deployment is done by Bamboo installed as windows service and there is
no good place for know_hosts file. NullKnownHostProvider is the only
way which I've found
1) get your Database coords and other deployment properties out of the
project and onto your servers. Use JNDI.
Two advantages - your builds are simpler and less prone to nasty
run-time surprises and you can actually run the WAR file that you tested
not some other WAR file that you made after
On Tue, Jan 25, 2011 at 12:50 PM, Anders Hammar and...@hammar.net wrote:
Ok, I see where we misunderstand each other.
What you want to do is to build just one war. This war should not include
any environment configuration at all! Environment dependent configuration
should be handled outside
On 25/01/2011 7:03 AM, Miguel Almeida wrote:
Anders,
I think I understand what you mean, but it doesn't seem to be very different
from the current approach.
Get rid of the profiles. You don't need them and they are leading you
astray.
Get your deployment stuff out of your WAR. Sooner or later
On 25/01/2011 6:35 AM, Anders Hammar wrote:
Antonio is right.
This has been discussed several times. Search the archive for many examples
of doing this, including using JNDI or putting a properties file on the
classpath.
I understand this would require changes to your code base. Major changes
Can anyone please suggest a good workaround other than specifying a hard
coded path or passing -DlocalRepository flag, if one exists.
The solution is then to get a repository manager and upload the missing
artifact to it (making it available to all your developers). Then you just
declare
On Tue, Jan 25, 2011 at 8:09 AM, Miguel Almeida
migueldealme...@gmail.com wrote:
I agree with you. I'm still quite new to advanced Maven topics so it still
seems counter-intuitive to store the config file outside the .war - it adds
one extra step of deploy the .xml/config file in the
Hello,
Dear all,
in our company we have a policy that every released artifact should
have a release tag in Subversion assuming tagging is a cheap operation
in subversion.
So given a standard multimodule project:
foo/trunk/pom.xml (groupId=foo,artifactId=parent,version=1.0-SNAPSHOT)
On 25 January 2011 19:23, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
On Tue, Jan 25, 2011 at 8:09 AM, Miguel Almeida
migueldealme...@gmail.com wrote:
I agree with you. I'm still quite new to advanced Maven topics so it still
seems counter-intuitive to store the config file outside the
Hi Mirko!
If you release the whole project at once, then you obviously only get exactly
one tag!
You'd need to run releases on each module on it's own to get the single tags.
But I'm not sure if this is really a good thing...
What is the goal you like to achieve? What's wrong for you with
On Tue, Jan 25, 2011 at 10:21 PM, Mark Struberg strub...@yahoo.de wrote:
Hi Mirko!
If you release the whole project at once, then you obviously only get exactly
one tag!
You'd need to run releases on each module on it's own to get the single tags.
But I'm not sure if this is really a good
Well, I implemented a solution, which anyone interested can retrieve
from github, see: https://github.com/mfriedenhagen/multi-module-svn.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
33 matches
Mail list logo
