Hi,
I thought that I would ask here whether anyone knows why the goal mvn
eclipse:m2eclipse has been removed from
org.apache.maven.plugins:maven-eclipse-plugin:2.8
It was available in org.apache.maven.plugins:maven-eclipse-plugin:2.7
I found the following references to this goal:
Hi!
see
http://maven-users.828.n2.nabble.com/searching-for-eclipse-m2eclipse-td4743556.html
hth,
- martin
On Monday 03 May 2010 Crow, Neil NW wrote:
Hi,
I thought that I would ask here whether anyone knows why the goal mvn
eclipse:m2eclipse has been removed from
Thanks Martin,
I guess that the m2eclipse-mojo page would have to be removed manually.
http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo
Cheers,
Neil Crow
-Original Message-
From: Martin Höller [mailto:mar...@xss.co.at]
Sent: 03 May 2010 13:57 PM
To: Maven Users List
Hi all,
I have a webapp (sub)module that uses Spring's dependency injection; how
can/should I load the application context so I may run the unit tests for this
module?
Once all the modules are complete, I will add them to the webapp as
dependencies and load the application context via the
Hi,
that sound not like a Unit Test more like an integration test...which can be
done by using cargo plugin...there you can startup e.g. Tomcat and run
Integration test on the deployed system...
On the other hand if you have only DI's than you only need an
applicationContext.xml setup for the
Hi everyone
For internationalized logging I have parallel to my *.java files in each
package a message.properties file. Using
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-5/version
There are two ways I usually solve this problem. The choice between
the two (for me) is usually a matter of how deep I want the testing to
go.
In many cases, I use spring injection from my unit tests by combining
JUnit's @RunWith annotation and some Spring Annotations. Here is an
example -
Hi Brian,
Thanks for looking into this. A specific example is the
org.apache.sling:org.apache.sling.commons.auth:0.9.0-SNAPSHOT
artifact. The artifact is there, and can be downloaded directly by using
Browse Storage on the Snapshots repository.
But the Browse Index only shows the pom and
I am a confused about where repositories need to be defined.
I have my repositories defined in my settings.xml file under my default
profile.
profile
iddefault_profile/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
I believe its because deploying a release isn't something you do more than once.
However, you may need to rebuild a release from a tag more than once. You may
actually need to rebuild many years after a tag was released and your
environment may have changed since then and thus need to download
Consider the repositories in your POM to be those for your local
development. That's your choice.
You put things in the POM if you want to distribute your repository to
other people. Having it in the POM means that it gets added to the
build and things can be pulled there automatically. I believe
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
On May 3, 2010, at 4:35 PM, Timothy Mcginnis wrote:
I am a confused about where repositories need to be defined.
I have my repositories defined in my settings.xml file under my default
profile.
I see repositories and not deploymentManagement, so unless I'm
confused there's nothing here to make the 'write' side work.
On Mon, May 3, 2010 at 11:27 AM, Jason van Zyl ja...@sonatype.com wrote:
http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
On
I don't think the original poster was questioning whether or not artifacts
should be downloaded from repos defined in settings.xml. But rather artifacts
that get deployed do not go in settings.xml. They have to go in the pom. Why do
these repos not also go in settings.xml?
I agree with the OP
The reason you can define them in two places is that Maven separates the
configuration of the repository from which you read artifacts from those
which you write (or _distribute_) artifacts (and further separates the
repository to which you distribute snapshots from that to which you
distribute
I think the best way to think about this is that the read
side is (or should
be) an aspect of your environment whereas the write side is
an aspect of your project.
Very true. But we should make it clear why reading is an aspect of your
environment whereas writing is an aspect of your
On Mon, May 3, 2010 at 12:37 PM, Frank Maritato
fmarit...@attinteractive.com wrote:
Hi,
I have a multi module project and in my top level pom I am using a property
to define the version number like this:
version${myproject.version}/version
properties
We thought (my coworkers and I) that -D would win any conflict of
properties. But we seem to be experiencing something more complex when
we've got the same property in three places: -D, parent properties,
and profile properties. The command line isn't always winning.
What are we missing?
What I've surmised from the various sources of maven thinking, is that
1) The parent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent the groupId
3) The child project should also define its version explicitly
The
Does this imply a rule 4) The parent should define properties for all of
the dependency versions for the shared libraries that the children need?
Does this go in dependency management or simply as a set of properties
that are passed on to the children?
Ron
On 03/05/2010 2:44 PM, Marshall
I'm not aware of one, but I'd love to have one if it were available - it's
somewhere on my to do list to see if
I can do it, but I don't see doing it any time soon.
On Thu, Apr 29, 2010 at 9:08 AM, Benson Margulies bimargul...@gmail.comwrote:
Is there any plugin which will check the consistency
Thanks. This forced me to retrace my steps and find the real problem.
On Mon, May 3, 2010 at 3:43 PM, Kalpak Gadre kalpa...@gmail.com wrote:
Try this,
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
All,
I have a simple maven project that generates a jar file; with the
classifier 'config'. When I call the 'deploy' phase, the pom file is
uploaded with unique identifier (as expected) but the jar file is not
(see examples below); the maven metadata is updated with the timestamp
as well.
On 5/3/2010 4:05 PM, Ron Wheeler wrote:
Does this imply a rule 4) The parent should define properties for all
of the dependency versions for the shared libraries that the children
need?
Things go in parents when you can see you are repeating yourself in the
children; moving those items to
it looks like your jar file has no classifier. A plain jar file is
being uploaded. Can you post the part of the POM where you are defining
the classifier artifact, and attaching it?
-Marshall
On 5/3/2010 7:09 PM, Michael Delaney wrote:
All,
I have a simple maven project that generates a jar
i usually deploy specify packaging=pom
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
then deploy by specifying packaging=jar
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
Martin Gainty
__
Verzicht
This seems like a very specific use case. I think it's more to the point
to say that many people (including, I suspect, 100% of Maven developers)
use the same workstation to work on projects which are deployed to
different repositories, e.g. apache, codehaus, shudder java.net, a
corporate
On Mon, May 3, 2010 at 9:56 PM, Crow, Neil NW
neil.c...@standardbank.co.za wrote:
Thanks Martin,
I guess that the m2eclipse-mojo page would have to be removed manually.
http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo
The 2.8 version doesn't include that as a goal:
I can't say if the jetty plugin config is correct, but for it to apply when
you run jetty:run you need to move it to the pluginManagement section.
http://maven.apache.org/pom.html#Plugin_Management
/Anders
On Mon, May 3, 2010 at 20:45, Bill Smith ne...@weseewhathappens.com wrote:
I am trying
You should be executing
mvn deploy
which will deploy your project.
/Anders
On Tue, May 4, 2010 at 02:17, Martin Gainty mgai...@hotmail.com wrote:
i usually deploy specify packaging=pom
http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html
then deploy by specifying
Yes, I've seen mails on the mvn-dev list before regarding old (and invalid)
pages not being removed during release. The big problem here is that they
still show up on google searches.
I would suggest filing a jira on the project, asking them to remove the
page.
/Anders
On Tue, May 4, 2010 at
Hi,
what do i need to write in the distributionManagement tag, in order to
deploy a maven plugin i wrote?
(to a pluginRepository, so that other developers can use the plugin)
i don't mind donating it to the community if someone is interested.
it's a plugin for maven-rpm-plugin: it scans current
32 matches
Mail list logo
