to Other sites
How can I get this plugin? It says it hasnt' been release yet.
THanks.
Brian E Fox wrote:
If you aren't actually changing the g:a:v info, then you could use the
stage plugin to move it.
-Original Message-
From: nadias [mailto:[EMAIL PROTECTED]
Sent: Friday, February
It's only the new tree goal that requires 2.0.8. Everything else should
work fine on older versions. Since the tree goal is most often used via
the command line for debugging purposes, I chose not to require 2.0.8
for the entire plugin and leave out the majority of the users. If you
use the tree
This seems to be an issue in the newer maven-archiver in the way it
handles the tars, nothing changed in the dependency plugin related to
how it unpacks, but we needed a newer version of the archiver to support
the filtering.
-Original Message-
From: Erez Nahir [mailto:[EMAIL PROTECTED]
The dependency plugin also has build-classpath which will put this on a
file for you, or the tree mojo in addition to the resolve one.
-Original Message-
From: Tom Huybrechts [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 27, 2008 11:32 AM
To: Maven Users List
Subject: Re: How to trace
Couldn't this already be checked with checkstyle and/or pmd?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 9:38 AM
To: Maven Users List
Subject: RE: End-of-line style plugin
The original svn_auto_props works only on your working
that's ok, isn't it?
On Jan 22, 2008 3:11 AM, Brian E. Fox [EMAIL PROTECTED] wrote:
This was added to 2.1, it won't happen in 2.0.x. A flag to force it
needs to be added to the interface and to the deploy plugin, and it
should be backported to 2.0. Can you write a jira?
-Original Message
I think this only gets set into the metadata when you deploy the
artifact.
-Original Message-
From: Guillaume Lederrey [mailto:[EMAIL PROTECTED]
Sent: Monday, January 21, 2008 8:22 AM
To: Maven Users List
Subject: Re: Avoid Dependency version
On 20/01/2008, Brian E. Fox [EMAIL PROTECTED
This was added to 2.1, it won't happen in 2.0.x. A flag to force it
needs to be added to the interface and to the deploy plugin, and it
should be backported to 2.0. Can you write a jira?
-Original Message-
From: Thomas Tardy [mailto:[EMAIL PROTECTED]
Sent: Monday, January 21, 2008 9:01
You can use dependencyManagment in a parent pom to avoid specifying the
version in all your child poms. If you really want the latest you have
two choices:
LATEST - latest snapshot
RELEASE - latest release
Or you could specify a range like [0,)
-Original Message-
From: amit kumar
Give each execution a unique id and it should be fine.
-Original Message-
From: Thomas Tardy [mailto:[EMAIL PROTECTED]
Sent: Friday, January 18, 2008 1:45 PM
To: Maven Users List
Subject: Configure a Plugin for two different Phases
Hello,
I have to say sorry for the previous emails. I
13, 2008 1:31 am, Brian E. Fox wrote:
I think John is wrapping up a few issues before an alpha goes out.
Are there any showstoppers outstanding that prevent a release?
Regards,
Graham
--
-
To unsubscribe, e-mail: [EMAIL
Actually the beanshell rule (return false) would be better.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 11:09 AM
To: Maven Users List
Subject: RE: Block phase
You could bind the enforcer to the next phase with a condition
You could bind the enforcer to the next phase with a condition that will
always fail (os=dos for example...).
-Original Message-
From: John Coleman [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 10:12 AM
To: Maven Users List
Subject: Block phase
I there a way to create
The plugin itself is asking maven to rerun this phase because it's needed when
invoked from the command line. Some plugins provide an alternative goal that
doesn't do this when bound to the pom. Check the docs to see if one exists, if
not create a jira for it. (it's a simple fix)
-Original
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
+Resolution#DependencyMediationandConflictResolution-DependencyVersionRa
nges
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Sahoo
Sent: Sunday, January 13, 2008 2:45 AM
To: Maven
I think John is wrapping up a few issues before an alpha goes out.
-Original Message-
From: Graham Leggett [mailto:[EMAIL PROTECTED]
Sent: Friday, January 11, 2008 11:11 AM
To: Maven Users List
Subject: Maven 2.1 release
Hi all,
Is there any expected timeframe for the first stab (an
Probably because some dependency you are using has added a repository
(maven.openqa.org). This is why we suggest that putting repos into poms
is not a good idea.
-Original Message-
From: Brewster, Richard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 09, 2008 5:58 PM
To:
Any plugin that declares @execute [phase] will cause the build to fork.
The dependency plugin does not, but one of your other plugins must. I
know that javadoc did, assembly does (depending on which goal),
enforcer:enforce-once does. Take a look at the various plugins you have
bound and see which
Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Steinar Bang
Sent: Wednesday, January 09, 2008 12:55 PM
To: users@maven.apache.org
Subject: Re: Why do maven lifecycles fork?
Brian E. Fox [EMAIL PROTECTED]:
Any plugin that declares @execute [phase] will cause the build to
fork
You can also filter the files being included by unpack-dependencies, you
can use scope,transitive,groupId,artifactId,type,classifier etc. You
should be able to narrow it down to just the ones you want.
Here's the intended distinction between copy/unpack and
copy-dependencies/unpack-dependencies:
/profile
Brian E Fox wrote:
Are you sure this works? I am 99% sure I tried this recently and had
no
luck.
-Original Message-
From: jallen [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 05, 2008 11:41 AM
To: users@maven.apache.org
Subject: Re: buildManagement
Normally you will want it as a dependency inside your plugin block (it is valid
there) but there is a bug that doesn't allow this config in the reporting
plugins block. In this case you need to use the extensions to make it work. You
only need the xml file inside the jar, nothing inside the
Are you sure this works? I am 99% sure I tried this recently and had no
luck.
-Original Message-
From: jallen [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 05, 2008 11:41 AM
To: users@maven.apache.org
Subject: Re: buildManagement for reports
Due to the way plugins are instantiated
The fix version in the jira is 2.1-alpha-1. Mystery solved
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 7:36 AM
To: Maven Users List
Subject: Re: Existance of ZIP Archetype? | How to distribute DB code to
different mvn modules?
On Jan
Users List
Subject: Re: How to easily determine all the versions of plugins that are being
used.
Hi!
On Wednesday 05 December 2007 wrote Brian E. Fox:
The enforcer will tell you the current version of plugins not locked
down. I've been working towards a release very soon...
Any news on this one? m
Maven will always do this when it finds poms in the execution folder.
Why do you care if it scans the tree?
-Original Message-
From: Bohtvaroh [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 03, 2008 12:07 PM
To: users@maven.apache.org
Subject: How to disable scan for projects
Hello.
be replaced
with
my plug-in, so pom tree is still invalid.
Brian E Fox wrote:
Maven will always do this when it finds poms in the execution folder.
Why do you care if it scans the tree?
-Original Message-
From: Bohtvaroh [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 03, 2008 12:07
I've been following these threads and I think you're going way outside of what
should be needed. You originally wanted to define a group and version as a
property, presumably because you want to centrally control it rather than it
would actually change it.
The proper way to control the version
.
Packaging of pp-server (war or jar) has no influence on result.
The process is triggered by executing mvn -U clean package on parent.
I hope the issue is clear now.
KR
PatrickV
Brian E Fox wrote:
-Original Mes http://www.nabble.com/file/p14567676/pp.zip pp.zip
sage-
From
You don't have the same artifactId:
artifactIdbooking-ejb/artifactId.artifactIdbooking-web/artifa
ctId
-Original Message-
From: Rice Yeh [mailto:[EMAIL PROTECTED]
Sent: Monday, December 31, 2007 12:52 AM
To: Maven Users List
Subject: version in dependency is needed
Hi,
I have a
for each one.
On Dec 29, 2007 4:23 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:
Which part is it that you need to use in the dependency plugin? The
actual copying and unpacking is mostly delegated to the
maven-archiver
component.
-Original Message-
From: Kallin Nagelberg [mailto
... hangs
Brian,
2007/12/30, Brian E. Fox [EMAIL PROTECTED]:
Immanuel,
After printing the Scanning for Projects... message, maven is
walking
down the source tree in the current folder. It is looking for a
pom.xml
and then processing the modules to find those poms.
In your case, there should
you won't get what you want (module != dependency).
Brian E Fox wrote:
I think the problem is the war packaging. Maven doesn't normally pull
in
war dependencies transitively because the dependencies are included
inside it.
The dependency plugin xxx-dependencies goals are asking Maven to do
I think the problem is the war packaging. Maven doesn't normally pull in
war dependencies transitively because the dependencies are included
inside it.
The dependency plugin xxx-dependencies goals are asking Maven to do the
resolution and then filters the results, so in this case the transitive
Immanuel,
After printing the Scanning for Projects... message, maven is walking
down the source tree in the current folder. It is looking for a pom.xml
and then processing the modules to find those poms.
In your case, there should be no poms since you are doing a create, so
it's a little odd
Which part is it that you need to use in the dependency plugin? The
actual copying and unpacking is mostly delegated to the maven-archiver
component.
-Original Message-
From: Kallin Nagelberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 29, 2007 4:03 PM
To: Maven Users List
There is an unpack goal that you can use to specify the ones you want,
or the unpack-dependencies to unpack all transitive of the current
project. Is it something else you're trying to do?
-Original Message-
From: Kallin Nagelberg [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 22,
This is an interesting idea, but what if you change the rev on the trunk
but someone has a developer branch? Now their branch will start failing
the rule cause it's not the latest top level parent.
-Original Message-
From: Nick Stolwijk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December
Stolwijk
Brian E. Fox wrote:
This is an interesting idea, but what if you change the rev on the
trunk
but someone has a developer branch? Now their branch will start
failing
the rule cause it's not the latest top level parent.
-Original Message-
From: Nick Stolwijk [mailto:[EMAIL
not not included with cobertura
2.2
No, that is cobertura-maven-plugin 2.1. The 2.2 version of the
cobertura-maven-plugin works fine on its own. But as David wrote, it
does not yet play well inside the dashboard.
Brian E. Fox wrote:
Yes, it is known that Cobertura 2.2 is essentially completely broken
Yes, it is known that Cobertura 2.2 is essentially completely broken.
-Original Message-
From: Erez Nahir [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 15, 2007 3:06 PM
To: Maven Users List
Subject: dashboard - code coverage not not included with cobertura 2.2
Hi,
After moving to
You can use any of the phases listed here:
http://www.sonatype.com/book/lifecycle.html
If androMDA uses generate-sources, then you need to use validate.
-Original Message-
From: jeeads [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 4:41 AM
To: users@maven.apache.org
Subject:
these in the main pom.xml
Thanks Jerry
Brian E Fox wrote:
You can use any of the phases listed here:
http://www.sonatype.com/book/lifecycle.html
If androMDA uses generate-sources, then you need to use validate.
-Original Message-
From: jeeads [mailto:[EMAIL PROTECTED]
Sent
You should use the assembly plugin to zip these templates up and deploy
them and then use the dependency:unpack to take them from the repo and
drop them in your local build as needed. You can also use the
remote-resources plugin in a similar way.
-Original Message-
From: jeeads
You need to create a minimal pom for these jars for maven to be able to
use them. If you use install:install-file or better deploy:deploy-file,
it can create the minimal pom for you.
-Original Message-
From: Claudio Di Vita [mailto:[EMAIL PROTECTED]
Sent: Friday, December 07, 2007 4:13
When you want to run a plugin directly from the command line as you
specified below, the configuration element must be outside the
executions block. Executions are used to bind the goal to a lifecycle
phase for execution during a build.
-Original Message-
From: Arthur Rodrigues Stilben
The recommended best practice is _not_ to define repos in your poms.
This issue you ran into is only one of many reasons why. You can search
the dev list for more discussions. The best way is to define your repos
in your settings file.
-Original Message-
From: Siegmann Daniel, NY
The enforcer will tell you the current version of plugins not locked
down. I've been working towards a release very soon... I just need to
wrap up documenting a few new rules I've added and then it's coming out.
Ultimately I want to roll this code into a help:current-plugins goal to
simply display
to a specific version of the
surefire plugin and see what happens.
Thanks a lot for the hint btw!
cheers
Francesco
Brian E Fox wrote:
Did you also update any plugins at the same time? Are your plugins
locked down in your poms? I'm wondering if a new version of a plugin
is
forking the build
Did you also update any plugins at the same time? Are your plugins
locked down in your poms? I'm wondering if a new version of a plugin is
forking the build causing your tests to run twice. Javadoc comes to
mind, but there may be others.
-Original Message-
From: Francesco Vivoli
The dependency:copy mojo already does what you want. So you can either
use that, or examine the code to make yours work.
-Original Message-
From: /U [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 01, 2007 2:37 PM
To: users@maven.apache.org
Subject: Forcing the download of a
You could define the values as properties like
source${jdk.version}/source and then define jdk.version to be 1.4 in
your parent pom. Then in your settings, you could choose to override and
use 1.5 only. Or better, you just define jdk.version in your projects
that need 1.5. (this saves you from
of reproducible builds
the settings file should _not_ affect the result of an artifact build
On Tue, 04 Dec 2007 12:57:48 Brian E. Fox wrote:
You could define the values as properties like
source${jdk.version}/source and then define jdk.version to be 1.4
in
your parent pom. Then in your settings, you could
Use a repository manager to only grab the dependencies you need in an on
demand fashion and cache them. This is much easier on the servers that
provide free access to the data.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Friday, November 30, 2007 1:52 AM
To:
Can you provide a test case for this? It's not immediately apparent why
the test-classes/classes problem would affect your build. (particularly
the spring one, I have no data on the war issue reported)
If you follow these instructions, it will provide us with a test we can
integrate into the core
The excludes is used for unpacking and it's available in
2.0-alpha-5-SNAPSHOT
-Original Message-
From: Erez Nahir [mailto:[EMAIL PROTECTED]
Sent: Monday, November 26, 2007 2:53 AM
To: users@maven.apache.org
Subject: latest version of maven-dependency-plugin - missing excludes on
The site does say that the goal is available since 2.0-alpha-5.
dependency:tree
Displays the dependency tree for this project.
Mojo Attributes:
* Requires a Maven 2.0 project to execute.
* Requires dependency resolution of artifacts in scope: test
* Since version: 2.0-alpha-5
You want org.apache.maven.plugins:maven-dependency-plugin. Latest
release is 2.0-alpha-4.
http://maven.apache.org/plugins/maven-dependency-plugin
That ibiblio mirror is seriously slow. I think you should stop using it.
Use repo1.maven.org/maven2 instead.
-Original Message-
From:
that is the problem.
Thanks
Daniel
Brian E Fox wrote:
I seem to recall now that you mention it (but can't check...on a
plane)
that the reporting section doesn't have an element for plugins. In
this
case, adding your jar as an extension to the build should do it.
Just
keep in mind that this is being
The dependency plugin doesn't support versions in the copy/unpack goals.
You could try the unpack-dependencies goal instead since that allows
maven core to resolve it. You would then use the filters to get only the
file you want.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
You can use the dependency:copy or unpack to get your file out of the
repo and drop it or unpack it...much simpler than using ant.
-Original Message-
From: Simon Taylor [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 6:32 PM
To: Maven Users List
Subject: RE: Maven2 - deploy
the module jar again but it still
doesn't.
Any help is appreciated
Thanks alot
Daniel
Brian E Fox wrote:
Add the jar containing your module in a dependencies section inside
your
plugin configuration block.
http://maven.apache.org/ref/current/maven-model/maven.html#class_plugin
-Original
Hi Kohsuke (thanks for Hudson!),
We maintain the repo1.maven.org repository and have no control over the
other mirrors. The unreliability of ibiblio was the reason we moved
central to a more stable platform.
--Brian
-Original Message-
From: Kohsuke Kawaguchi [mailto:[EMAIL PROTECTED]
Add the jar containing your module in a dependencies section inside your
plugin configuration block.
http://maven.apache.org/ref/current/maven-model/maven.html#class_plugin
-Original Message-
From: DanBarker85 [mailto:[EMAIL PROTECTED]
Sent: Friday, November 16, 2007 4:54 PM
To:
Set one profile to have the activeByDefaulttrue/... and when you activate
the other, the default one gets deactivated automatically.
-Original Message-
From: Roland Asmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 15, 2007 12:03 PM
To: Maven Users List
Subject: Re: how to use
Except for the antrun part ;-)
-Original Message-
From: Paul Merlin [mailto:[EMAIL PROTECTED]
Sent: Friday, November 16, 2007 5:51 PM
To: users@maven.apache.org
Subject: Re: Reuse of attached assemblies
Le Friday 16 November 2007 17:49:01 Wendy Smoak, vous avez écrit :
On Nov 16, 2007
The multi module is the correct way to go. You might be able to combine
them using the assembly plugin and the jar with dependencies stuff.
-Original Message-
From: Hirn, Joseph [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 13, 2007 11:48 PM
To: Maven Users List; [EMAIL PROTECTED]
looking at
Yeah, hence my confusion - the docs have a slightly different overWrite
attribute.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 2:39 AM
To: Maven Users List
Subject: RE: what version of the documentation am I looking
All the functionality discussed below has been released, several
versions ago I believe.
To avoid declaring the version multiple times, you have a few options:
1. Use dependencyManagement and don't specify a version in the
dependency block or the artifactItem
2. Use a property
3. If it is really
bet - I'm going to give
this a spin if it exists in the 2.0-alpha-4 version of this plugin.
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 9:32 AM
To: Maven Users List
Subject: RE: what version of the documentation am I looking at
All
The docs are for the lastest snapshot, however, the overwrite flag has
been there since 1.0.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Friday, November 09, 2007 12:21 AM
To: Maven Users List
Subject: what version of the documentation am I looking at
Is it
The next release of enforcer has a rule to make sure plugins are locked
down. Dependencies must already be specified, but there is also a rule
to make sure snapshots aren't included (similar to release plugin).
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent:
Don't use enforce-once, just use enforce.
-Original Message-
From: maarten roosendaal [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 8:20 AM
To: Maven Users List
Subject: Re: maven-release-plugin best practice question
Hi,
I found the problem, i was also using the
Enforcer plugin was designed exactly for these kinds of things. It
shouldn't be hard to create that rule.
-Original Message-
From: Dan Kigelman [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 28, 2007 3:39 PM
To: Maven Users List
Subject: Best Way to Enforce a File Exists
Hello,
I am
It's possible that some other dependency has the 3.1 set. Use mvn -X to
see the actual resolution, the tree mojo is still in progress.
I don't understand your question about the war files. Are you expecting
to see the dependencies inside the war or OF the war?
-Original Message-
From:
There is work occurring on the deploy plugin to not overwrite existing
release artifacts by default.
-Original Message-
From: Nicole Lacoste [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 24, 2007 8:21 AM
To: Maven Users List
Subject: Re: Protection of Already Deploy Artifacts
You
You would need the jars to have the associated classifier too...
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 23, 2007 3:11 PM
To: Maven Users List
Subject: Re: declare dependencies depending on jdk version
Most people solve these kinds of problems
Put the common part in a parent that you inherit from and add the rest
in the child.
-Original Message-
From: Mick Knutson [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 20, 2007 7:45 PM
To: maven
Subject: [m2+]any way to split up sections of the pom.xml?
I have many different
You could use the exec-maven-plugin on codehaus, or even the
app-assembler.
-Original Message-
From: Cole, Richard [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 4:06 PM
To: users@maven.apache.org
Subject: Maven Development Process
I see how to use the assembly plugin to
I think there's a plugin for that, but it escapes me. It isn't a very
portable solution what you are proposing. A more portable solution is to
make a new module for these files. Use assembly:single to zip them up
and deploy them to your repos. Then you can use the dependency plugin to
unpack this
a full
path to something outside the standard build directory) seems to be
working
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 3:08 PM
To: Maven Users List
Subject: RE: Copying resources
I think there's a plugin
Is there anyone out there who can review the patch for Japanese
resources?
http://jira.codehaus.org/browse/MNG-428
Thanks,
Brian
I'm also using proximity but a snapshot of RC9 because Tamas added a new
feature that I requested. This was maybe 3 months ago. It is quite stable and
we are very pleased with it after trying several alternatives. I know he had
some infrastructure issues at one point, which may explain the
You can package them up with assembly:single in a pom project, and then
use dependency:unpack to put the contents where you need them.
-Original Message-
From: Ian Rowlands [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 09, 2007 6:25 PM
To: Maven Users List
Subject: Suggested best
Set inheritedfalse/inherited in the execution IIRC (I forget the
exact location, but that should get you started)
-Original Message-
From: Matthew Flower [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 4:37 PM
To: users@maven.apache.org
Subject: Enforce environment variable
Try mvn dependency:analyze
It will tell you when you are not using dependencies and also when you
haven't declared things you are directly using.
-Original Message-
From: Giovanni Azua [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 30, 2007 8:27 AM
To: 'Maven Users List'
Subject:
The dependency plugin has a few unpack goals:
http://maven.apache.org/plugins/maven-dependency-plugin
-Original Message-
From: Mark Russell [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 30, 2007 11:12 PM
To: users@maven.apache.org
Subject: How does a plugin unpack a needed resoure
The mojo project has mailing lists
(http://mojo.codehaus.org/mail-lists.html) for those projects.
-Original Message-
From: Tristan Cebulla [mailto:[EMAIL PROTECTED]
Sent: Monday, October 01, 2007 9:55 AM
To: users@maven.apache.org
Subject: Re: Improving the documentation of plugins (was
There is something called the exec plugin I believe and I think
something also called the app-builder. Try searching using the google
search on the maven.apache.org page. The dependency plugin can output
the classpath to a file for later execution.
-Original Message-
From: siegfried
Note that this doesn't yet work for plugins not explicitly listed in your poms
(like the ones bound to the standard lifecycles) but I recently wrote some code
in enforcer to do this, so I can finally fix it here.
-Original Message-
From: zhongliang zhang [mailto:[EMAIL PROTECTED]
Sent:
There is a new search box provided by google to search the maven related
sites for information. Ultimately I'd like to move the box to the banner
so it's available from all pages, but various issues are holding me up.
This is at least a step in the right direction.
--Brian
harsh sometimes it's only
because of my insufficient command of the English language and not
because I don't want to be polite - at the contrary.
-Gisbert
Brian E. Fox wrote:
A common theme in the maven is hard thread is bad documentation and
I'd like to explore this a little. For the sake
Most of the site is generated and is in svn. You can check out the site
from here: http://svn.apache.org/repos/asf/maven/site/trunk and run mvn
site to generate it in target/site. Then you can create patches and put
them in jira. You may need to add the snapshot repo to your settings if
the site
This thread is getting way off topic. I started a new thread to focus on
meaningful positive suggestions for how to improve the site. I'm not at all
suggesting that the site will solve the world's problems, but this is where I
personally decided to get feedback. Like many of the other Maven
What's wrong with mvn -? As a way to get help? If I am confused about
other cli tools, I usually try foo -? Or foo /? Before anything else.
Obviously the -? Needs to be improved, but this is much easier to do
than a bunch of magic in the help plugin. Also it WILL work even if the
repos are
Everyone is bashing the plugin docs. Can you be more specific about
which ones and what's not good? Are we talking about plugins on Apache
or ones at Codehaus or somewhere else?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 9:37 AM
There is a newer book available at http://sonatype.com/book (no
registration required and it's html so you can just hop in and out as
needed)
-Original Message-
From: Richard Chamberlain [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 1:36 PM
To: Maven Users List
Subject:
A common theme in the maven is hard thread is bad documentation and
I'd like to explore this a little. For the sake of discussion, lets
separate the plugin docs from the maven site. (Why? Because each plugin
site is like it's own little world and some are good and some are bad.
We can have that
Does this also happen if you use the dependency:copy goal to retrieve
it? (don't list the artifact as a normal dependency but put it in the
plugin config)
-Original Message-
From: Anders Blehr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 3:51 PM
To: 'Maven Users List'
Torsten,
You got it. Because compile picks up transitive dependencies, you are
actually relying on someone else's dependency to get compiled. That
means you lose control over which version is used and the actual
dependency tree isn't accurately reflecting your project.
--Brian
-Original
601 - 700 of 1094 matches
Mail list logo
