Hi cvr,
I think hostility can exist with any change in general. Sometimes it is
really just an attitude thing so you can't use logic to reason with him.
What you need is a mandate (whether it is concencus from team members or
from someone else).
If you don't have a mandate to use Maven then yo
Hi Luis,
As you'd already know, Maven is good with the following,
a) maven is structured and more declarative (less procedural) than Ant.
b) maven manage your dependencies properly (or at least in its ideal)
c) maven can generate IDE project files easily
d) life cycle management ensure that test
Is there a philosophical reason why release plugin shouldn't do that on
behalf of the users?
Maven makes alot of things simpler and pleasant for you (i.e., transitive
dependencies, lifecycles management etc..) and then there are occasional
things like this that makes you wonder why would I have
I've worked out what happened. Surefire 2.3.1 is not in the central
repository yet but apparantly it has been tagged
(http://jira.codehaus.org/browse/MNG-3118).
Last Friday, I've downloaded maven source and build it on my local machine
(and added apache snapshot into Artifactory). As a result,
Ok, but our problem is not a simple backward compatibility.
I was working on project A on my machine. I upgraded to 2.0.8. Nothing
breaks here but it it break then fair enough.
A colleauge was working on project B and still using 2.0.6.
Some how my action of upgrading to 2.0.8 in my machine ha
Right, thanks for the explanation.
Explicitly specifying the plugin version would help in this particular
case but would we then need explictly declare every single plugin in the
project to guard against future problem? i.e., clean, compiler, deployer,
install, jar, war etc... would you then re
We were using maven 2.0.6 in a team with Artifactory as a proxy.
I then upgrade my environment to 2.0.8. A whole bunch of new plugins get
fetched.
Other people were using 2.0.6 but it appears that they also get a whole
heap of new plugins.
As a result, test cases in another project which had
Hi,
If you don't use any maven proxy, you could simply copy all of the
libraries across to your repository and write a script to generate basic
pom.xmls and the checksums. You just need to understand how he repoitory
is structured.
Alternatively, you could also write a script to run deploy-fil
That's interesting.
Would this version range work [1.2,-!) i.e., to match 1.2 or anything
later ?
> don't put [X.X] ranges in things that will resolve transitively.. that
gives
> NPE have not figure out why yet... i suspect broken metadata
Not sure what you mean, but when we use version ra
Hi All,
I'd like to get an idea if there are many people using the version range
feature in the community. For those users using/relying version range, do
you find any problems with it?
In our organisation, some people advocate the usage of version range but
personally, I don't think it is rob
It sounds odd to have that many release version per day. Version range
notation would be perfect for what you need..
i.e.,
[2.1, )
Having said that I found a number of problems with using version range and
I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve
conflict betw
Sorry Arron, I have missed that section of your mail. Yes you do need
commit access across all project. I think it is reasonable that if you
don't have commit access to all the projects then you need to manually
coordinate the change with everyone. It is a pain so commit access can
solve the pr
Yes the helper classes (in src/test/java) needs to be packaged and
installed to the repository so that another maven project can reference.
By default, maven-jar-plugin doesn't jar up class in src/test/java. By
default, all of the classes in src/test/java as well as src/test/resources
will be i
You need to create a test-jar artifact out of your helper classes
Put this in the pom of your helper classes
org.apache.maven.plugins
maven-jar-plugin
test-jar
Hi Aaron,
Do you use release plugin?
The release plugin should increment the version of the parent pom and the
pom itself for you.
If you have dependencies to sibling pom in your dependencies declaration,
I'd use ${project.version} to get around the problem
that the release tag won't increme
Thanks Scott,
I just wanted to confirm that the behaviour that Anton asked for is not
supported. Your response to him didn't really answer that question.
I think the *default* behaviour that would be nice to have is when you
perform "mvn weblogic:deploy" at root pom and any child poms that has
Scott,
I have the same problem here, I have the plugin defined in parent pom
(under pluginManagement).
When I run "mvn weblogic:deploy" from the parent, it assumes that the
parent pom is a war project and then tries to deploy the war artifact of
the parent at the parent level. This immediatel
Vaidya,
I can't work out the directory structure of your EAR from your emails but
the lib directory you mention should be in
creditelseEAR.ear/APP-INF/lib/
and not
creditelseEAR.ear/lib/
Weblogic should be able to find libraries within APP-INF/lib/
rOnn c.
"Vaidya, Supriya A (US - C
You could set MAVEN_OPTS environment variable in your shell.
e.g.,
set MAVEN_OPTS=-Xmx512M
Cheers,
rOnn c.
Baz <[EMAIL PROTECTED]>
08/07/2007 09:19 AM
Please respond to
"Maven Users List"
To
"Maven Users List"
cc
Subject
How to increase the memory usage for mvn?
Hi,
How can i in
Hi there,
Pom.xml allows you to override final name of the artifact that gets
generated. However, this final name doesn't get carried through when you
deploy to the repository.
I.e., if you have
/myproject/common/library/pom.xml
and say you override final name as myproject-common-library,
my
Hi Chris,
What about a cron job that rsync content from repo in dev regularly?
Surely by the time your code gets to production, it would have had at
least half an hour to sync the repository ;-)
Also, I think putting repo artifacts in SCM will makes things very slow
and painful - esp if you
21 matches
Mail list logo
