[ANN] Maven Release Plugin 2.0-beta-7 Released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven WAR
Plugin, version 2.0 beta-7.

http://maven.apache.org/plugins/maven-release-plugin


Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-7


** Bug
* [MRELEASE-124] - Impossible to depend on a deployed snapshot
* [MRELEASE-240] - release-pom.xml does not contain 
and 
* [MRELEASE-243] - Release pom is deployed and embedded in artifacts
* [MRELEASE-244] - Correct licences in mojo test cases
* [MRELEASE-245] - CheckDependencySnapshotsPhase ignores ranges
* [MRELEASE-296] - release fails when trying to update properties
used in multiple siblings


** New Feature
* [MRELEASE-279] - Create Branch from Tag

Enjoy!

- The Maven team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven 2.0.8 Release

[Brian Fox]

The Apache Maven team would like to announce the availability of Maven
2.0.8. We closed out 32 issues and no major issues upgrading are
expected.

There is one slight change to be aware of, the test-classes folder is
now before the classes in the classpath to allow test resources to
override runtime for testing purposes
(http://jira.codehaus.org/browse/MNG-3118)


You can find the binaries here:

http://maven.apache.org/download.html

You can find the release notes here:

http://maven.apache.org/release-notes.html

You can find the roadmap here:

http://jira.codehaus.org/browse/MNG?report=com.atlassian.jira.plugin.system.project:roadmap-panel

Thanks,

The Apache Maven Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[announce] Release Ounce-Maven-Plugin 1.0

[Brian Fox]

The mojo team is pleased to announce the release of the
Ounce-Maven-Plugin 1.0. Ounce is a code security scanning tool
produced by OunceLabs. The ounce plugin enables integration with Maven
and automatic creation of Ounce application and project files as well
as on demand scanning and site report integration.

You can read more about this plugin at:
http://mojo.codehaus.org/ounce-maven-plugin

--The Mojo Team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Dependency Plugin 2.0 Released

[Brian Fox]

The Maven team is pleased to announce the 2.0 release of the Maven
Dependency Plugin:

http://maven.apache.org/plugins/maven-dependency-plugin

This release fixes many issues and introduces several new goals for
dependency analysis and output.

Release Notes - Maven 2.x Dependency Plugin - Version 2.0


** Bug
* [MDEP-59] - dependency:unpack can't extract rar archives
* [MDEP-74] - dependencies in test scope are not handled properly by analyze
* [MDEP-75] - non-portable classpath separator in build-classpath output
* [MDEP-80] - Usage page of the docs use an overWrite property,
but none exists in the (auto-generated) goal reference docs
* [MDEP-81] - analyzer can't handle non-pom projects that don't
produce a /target folder
* [MDEP-83] - Typo in "How to prepare your dependencies before
updating to Maven 2.0.6"
* [MDEP-91] - org.codehaus.mojo:dependency-maven-plugin takes
precedence over org.apache.maven.plugins:maven-dependency-plugin
* [MDEP-93] - Tests can fail with OOME
* [MDEP-95] - can't build unit tests with jdk1.4 rev 545703
* [MDEP-97] - dependency:tree not consistent with maven core's
dependency tree
* [MDEP-113] - Unable to find the mojo
'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT
* [MDEP-120] - build-classpath is unable to build a classpath with
runtime or test dependencies

** Improvement
* [MDEP-89] - change separators in build-classpath
* [MDEP-96] - Allow includes and excludes to be used
simultaneously in the same filter
* [MDEP-99] - Unpack SWC files
* [MDEP-100] - Merge dependency:tree branch for new features
* [MDEP-101] - Add dependency:list alias for dependency:resolve
* [MDEP-104] - Add Analyze HTML Report
* [MDEP-111] - Provide output on file as in other goals
* [MDEP-119] - build-classpath should create destination directory
for the classpath file
* [MDEP-125] - Build-classpath should store the classpath in a Filter
* [MDEP-129] - allow substitution of the absolute local repo path
with a property
* [MDEP-130] - allow the classpath file to be attached
* [MDEP-131] - Complete i18n support for new analyze-report
* [MDEP-132] - Add german translation for analyze-report mojo
* [MDEP-133] - Add dedicated resource bundle for locale "en"

** New Feature
* [MDEP-47] - Ability to have an includes/excludes feature on the
dependency:unpack goal.
* [MDEP-70] - add new mojo to perform analysis of dependencies and
fail the build if certain conditions aren't met
* [MDEP-71] - add report to display contents of dependency-analyzer
* [MDEP-94] - Add dependency:tree goal
* [MDEP-116] - [dependency :copy-dependencies ] Add parameter to
allow extracting POMs

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven Archetype Plugin 2.0-alpha-2

[Brian Fox]

The Maven team would like to announce the release of Maven Archetype
2.0-alpha-2. This release corrected backwards compatibility with the
1.0 version and a few windows issues. The site has also been updated
and deployed: http://maven.apache.org/plugins/maven-archetype-plugin

Release Notes - Maven Archetype - Version 2.0-alpha-2

** Bug

* [ARCHETYPE-128] - Unable to create a Cocoon app with Maven
archetype: [WARNING] No archetype repository found.

* [ARCHETYPE-133] - POMs generated as part of create-from-project
are not correct and prevent using this feature completely



** Improvement

* [ARCHETYPE-116] - -DarchetypeArtifactId parameter is no longer respected

* [ARCHETYPE-117] - return previous defaults

Use the -U flag to get the updated plugin.

Enjoy.

-- The Maven Team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Javadoc Plugin version 2.4

[Brian Fox]

The Maven team is pleased to announce the release of the Maven Javadoc
Plugin, version 2.4.

NOTE: This release has many fixes, but most notably is MJAVADOC-137, which
reverses the aggregation introduced in 2.3. This can and has caused many
issues during releases because the javadoc is included automatically by the
release profile. *We recommend that everyone update to the 2.4 version asap.
*

This plugin provides the capability to generate Javadocs.

For instructions on how to use the plugin, refer to its web site at:
http://maven.apache.org/plugins/maven-javadoc-plugin/



Release Notes - Maven 2.x Javadoc Plugin - Version 2.4


** Bug
   * [MJAVADOC-108] - proxy support for plugin not complete enough
   * [MJAVADOC-135] - Error parsing javadoc version when used with IBM jdk
1.4.2
   * [MJAVADOC-136] - UmlGraph 4.8 - could not find map file
   * [MJAVADOC-137] - javadoc:javadoc always runs as "aggregator"
   * [MJAVADOC-139] - NPE out of AbstractJavadocMojo::getSourcePaths() on
multimodule project using aggregate
   * [MJAVADOC-141] - regression: Adding "jar" execution to the parent of a
multi-module javadoc plugin causes "recursive invocations" error
   * [MJAVADOC-143] - java.util.NoSuchElementException when using maven
2.0.6 and 2.0.7, but works in 2.0.4
   * [MJAVADOC-145] - If Javadoc is set to aggregate, the build fails inside
a Maven plugin module
   * [MJAVADOC-147] - -quiet argument is a standard doclet in j2sdk 1.4, not
a javadoc option
   * [MJAVADOC-149] - Newline in ${project.organization.name} makes javadoc
fail
   * [MJAVADOC-151] - No support for 'noProxyHosts' specified in
settings.xml
   * [MJAVADOC-152] - Javadoc plugin fails when -J-fullversion returns
localized version string
   * [MJAVADOC-155] - maxmemory and minmemory support only m unit
   * [MJAVADOC-156] - UnsupportedOperationException in multi module project
   * [MJAVADOC-161] - performRelease=true breaks install/deploy with
multimodule projects
   * [MJAVADOC-164] - Javadoc 1.4 fails due to missing directory in
linkoffline option
   * [MJAVADOC-172] - classpath is wrong using aggregate mode
   * [MJAVADOC-173] - JavadocUtil#copyJavadocResources( File
outputDirectory, File javadocDir ) should exclude default pattern
   * [MJAVADOC-176] - javadoc uses the undcoumented and platform unspecific
-J-fullversion to determine version instead of the more standardized
-J-version

** Improvement
   * [MJAVADOC-153] - Generate the OfflineLink class with Modello
   * [MJAVADOC-158] - Command line dump reveals proxy user/password in case
of errors
   * [MJAVADOC-159] - nooverview not implemented
   * [MJAVADOC-160] - Validate javadoc options and standard doclet options
   * [MJAVADOC-165] - Provide specific default value for "encoding"
parameter
   * [MJAVADOC-169] - Add support for i18n

** New Feature
   * [MJAVADOC-148] - Support of -top option in standard doclet JDK 6.0

** Task
   * [MJAVADOC-154] - Bump to plexus-utils:1.4.6
   * [MJAVADOC-174] - Fix hyperlink to reference doc for mojo parameter
"use"

Enjoy,

-The Maven team

[ANN] Maven Enforcer Plugin 1.0-alpha-1

[Brian Fox]

We are pleased to announce the first release of the maven-enforcer-plugin.

The Enforcer plugin provides goals to detect and enforce certain
environmental constraints such as Maven Version, JDK version, and OS
family/version/architecture. Additionally, the Enforcer can execute
custom rules defined by the user.

See the plugin site for more information:
http://maven.apache.org/plugins/maven-enforcer-plugin

Jira Project:
http://jira.codehaus.org/browse/MENFORCER


This release also consists of a shared component,
maven-enforcer-rule-api that allows the creation and execution of the
custom rules.

--The Maven Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Enforcer Plugin 1.0-alpha-2

[Brian Fox]

This is a minor release with just one fix:

Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2

** Bug
   * [MENFORCER-1] - plugin fails on jdk < 1.5


--The Maven Team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Enforcer Plugin 1.0-alpha-3

[Brian Fox]

We are pleased to announce the third release of the maven-enforcer-plugin.

The Enforcer plugin provides goals to detect and enforce certain
environmental constraints such as Maven Version, JDK version, and OS
family/version/architecture. Additionally, the Enforcer can execute
custom rules defined by the user.

See the plugin site for more information:
http://maven.apache.org/plugins/maven-enforcer-plugin

Jira Project:
http://jira.codehaus.org/browse/MENFORCER


This release also consists of a shared component,
maven-enforcer-rule-api that allows the creation and execution of the
custom rules.

Changes in this release include 3 new rules:
*  bannedDependencies - enforces that excluded dependencies aren't included.

*  evaluateBeanshell  - evaluates a beanshell script.

*  noSnapshots - enforces that no snapshots are included.

Release Notes:

** Bug
   * [MENFORCER-4] - Typos in Version Range Specification document
   * [MENFORCER-9] - Exception in java rule when using Apple JDK 6
Developer Preview

** Improvement
   * [MENFORCER-6] - add optional message to rules

** New Feature
   * [MENFORCER-5] - Add property verification to the enforcer plugin
   * [MENFORCER-7] - new beanshell expression rule
   * [MENFORCER-8] - Ability to disallow groups of deps

If you create a custom rule for the enforcer that you think might be
of general use and wish to share, please write a jira and attach the
source.

--The Maven Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Eclipse Plugin 2.4 Released

[Brian Fox]

The Maven Team is pleased to announce the release of maven-eclipse-plugin 2.4:

Release Notes - Maven 2.x Eclipse Plugin - Version 2.4:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13001&styleName
=Html&projectId=11133&Create=Create

** Bug
   * [MECLIPSE-108] - .wtpmodules with version 2.4 for
javax.servlet:servlet-api:2.3
   * [MECLIPSE-109] - .component wb-resource source path incorrect
for ear packaging
   * [MECLIPSE-151] - Incorrect name for test sources jars
   * [MECLIPSE-198] - EJB version is not resloved
   * [MECLIPSE-215] - WTP 1.5 Documentation
   * [MECLIPSE-220] - Incorrect eclipse facet information when doing
mvn eclipse:eclipse for war and ejb projects.
   * [MECLIPSE-225] - Invalid .classpath Entries.
   * [MECLIPSE-231] - Clean mojo assumes that POM projects never have
.project files - this is incorrect
   * [MECLIPSE-233] - Manifest attributes incorrectly treated as case-sensitive
   * [MECLIPSE-234] - [PATCH] EclipsePlugin.extractResourceDirs()
reuses String method argument causing maven-eclipse.xml copy-resources problems
   * [MECLIPSE-236] - eclipse:make-artifacts should preserve the
resolution:=optional directive
   * [MECLIPSE-237] - unsafe EclipseSourceDir.equals() method
   * [MECLIPSE-239] - eclipse:eclipse fails to find dependency
org.apache.maven.plugins:maven-eclipse-plugin:pom:test
   * [MECLIPSE-241] - Compiler settings in pluginManagement aren't
used in wtp facet
   * [MECLIPSE-243] - The last 2.4 SNAPSHOT forbid Apache Directory
Server to be built
   * [MECLIPSE-248] - Tests fail due to incorrectly attempting to use
released plugin version, not locally sandboxed one under test",
   * [MECLIPSE-255] - WTP Settings does not use servlet-api version
defined in pom.xml
   * [MECLIPSE-263] - Project Facet 'Java' set to 1.4 instead of 5.0
in a Java 5.0 project
   * [MECLIPSE-278] - duplicated classpathentries
   * [MECLIPSE-279] - PDE projects should be considered java projects
in all cases
   * [MECLIPSE-287] - Regression - fails to correctly construct
classpath containing dependencies with classifiers
   * [MECLIPSE-295] - Eclipse plugin fails due to missing
org.apache.maven.plugins:maven-eclipse-plugin:pom:test

** Improvement
   * [MECLIPSE-40] - Multi project dependencies should not require
eclipse project names to be the artifactId
   * [MECLIPSE-207] - Add supprt for arbitrary facets, like JSF
   * [MECLIPSE-267] - Resolve version ranges in make-artifacts
   * [MECLIPSE-268] - [eclipse:rad goal] Make customization of
servlet version, jsp version, ... possible through pom configuration
   * [MECLIPSE-286] - Ability to skip generated-resources/rad6 folder
creation while executing eclipse:rad
   * [MECLIPSE-292] - Behaviour for sources and Javadoc attachement
for dependencies should be consistent

** New Feature
   * [MECLIPSE-65] - Add contextName parameter to eclipse mojo so a
webtool context name doesn't have to match artifactId/project name.
   * [MECLIPSE-119] - Allow custom project name for eclipse projects
   * [MECLIPSE-189] - addVersionToProjectName property
   * [MECLIPSE-251] - Allows prefixing of eclipse project name
   * [MECLIPSE-271] - Ability to skip

Enjoy!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Dependency Plugin 2.0-alpha-3 Released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.0-alpha-3

http://maven.apache.org/plugins/maven-dependency-plugin/

The dependency plugin provides the capability to manipulate artifacts.
It can copy and/or unpack artifacts from local or remote repositories
to a specified location.

This release adds 2 new goals only:

dependency:analyze : this executes the maven-dependency-analyzer
shared component to look for problems with dependencies. This is an
initial release of the analyzer and there are 2 known issues: MDEP-72
and MDEP-73 (trouble with pom projects and projects with non jar
dependencies like zip files).


dependency:analyze-dep-mgt : this compares the resolved dependencies
with the dependencyManagement section to identify mismatches. This is
intended to help users identify where transitive dependencies are
conflicting with dependencyManagement ahead of the 2.0.6 release. (See
http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
for more information). It will also be useful to find out where
projects are explicitly overriding dependencyManagement.

- The Maven Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Dependency Plugin 2.0-alpha-4 Released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.0-alpha-4

http://maven.apache.org/plugins/maven-dependency-plugin/

The dependency plugin provides the capability to manipulate artifacts.
It can copy and/or unpack artifacts from local or remote repositories
to a specified location.


Changes:
Fixed several issues related to the new analyze and analyze-dep-mgt
goals:

Release Notes - Maven 2.x Dependency Plugin - Version 2.0-alpha-4

** Bug
   * [MDEP-72] - "IllegalArgumentException: Cannot accept visitor on
URL" when project contains a non-jar (e.g. zip) dependency
   * [MDEP-73] - dependency:analyze in a packaging=pom project should
skip, not die or produce a redundant report
   * [MDEP-74] - dependencies in test scope are not handled properly by analyze
   * [MDEP-77] - dependency:analyze is reporting impossible results
   * [MDEP-78] - analyze-dep-mgt has the labels reversed
   * [MDEP-79] - index out of bounds exception on analyze against
maven-war-plugin

** Improvement
   * [MDEP-76] - It would be nice to analyze dependencyManagement
exclusions as well as versions


- The Maven Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Plugin Tools 2.4.1 Released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven Plugin Tools,
version 2.4.1

This release fixes 3 critical issues discovered in the 2.4 release. We
recommend everyone upgrade from 2.4 to 2.4.1.


The Maven Plugin Tools contains the necessary tools to be able to produce
Maven Plugins in a variety of languages.

Maven Plugin:

http://maven.apache.org/plugins/maven-plugin-plugin/

Maven Plugin Tools:

http://maven.apache.org/plugin-tools/maven-plugin-tools-ant/

http://maven.apache.org/plugin-tools/maven-plugin-tools-api/

http://maven.apache.org/plugin-tools/maven-plugin-tools-beanshell/

http://maven.apache.org/plugin-tools/maven-plugin-tools-java/

http://maven.apache.org/plugin-tools/maven-plugin-tools-javadoc/

http://maven.apache.org/plugin-tools/maven-plugin-tools-model/

You can run mvn -up to get the latest version of the plugin, or specify the
version in your project's plugin configuration:

http://maven.apache.org/plugins/maven-plugin-plugin/plugin-info.html


Release Notes - Maven 2.x Plugin Tools - Version 2.4.1

** Bug

* [MPLUGIN-102] - The 2.4 Release Breaks Previously-Working Builds

* [MPLUGIN-104] - plugin report broken in 2.4

* [MPLUGIN-105] - incorrect order of dependencies on
maven-reporting-impl and doxia-site-renderer leads to wrong doxia-core

--The Maven Team

[ANN] Maven Reporting Impl 2.0.4.1 Released

[Brian Fox]

The reporting implementation is used to render site reports. This release
fixes an incompatibility with newer doxia implementations.

This has just one change from 2.0.4:

http://jira.codehaus.org/browse/MNG-3476

--The Maven Team

RE: Sonatype's Nexus 1.0-beta-1 Released

[Brian Fox]

> What do you mean by not relying on a CMS?  Does that mean an application
server?

Nexus doesn't use a database is what Jason was suggesting. 


>I was looking through the documentation and it does not look like Nexus is
made to be hosted within an application >server like Tomcat and Websphere.
Is that right?

Nexus is not intended to run in a separate app server. We provide an
embedded Jetty instance to host the app. This allows us to focus on building
the application and not messing around with app server limitations and
compatibility. It will also allow us to do some interesting things down the
road like hot updates of the base app server and application. Jetty is also
able to scale to a much larger load because of the way it handles
connections. 

While it hasn't been a focus for the alphas or beta-1, we will work to
ensure that Nexus can be hooked in via mod_proxy or ajp etc for
infrastructures that require it, but this will reduce performance over raw
jetty.

We have an IRC channel on irc.codehaus.org #nexus and user list
([EMAIL PROTECTED]) where we can discuss this in detail if
you wish.

--Brian
http://blogs.sonatype.com/brian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Apache Maven 2.0.9 Released

[Brian Fox]

The Apache Maven team would like to announce the availability of Maven
2.0.9.

This release went through a new process that saw 8 release candidates tested
by the user community before the final release and we expect it to be more
robust than previous versions. There are several important fixes and
changes, most notably locking down core plugins in the super pom. You can
read details in the release notes linked below.


You can find the binaries here:

http://maven.apache.org/download.html

You can find the release notes here:

http://maven.apache.org/release-notes.html

You can find the roadmap for future issues here:

http://jira.codehaus.org/browse/MNG?report=com.atlassian.jira.plugin.system.project:roadmap-panel

Thanks,

The Apache Maven Team

Re: which repository contains the 2 artifacts?

[Brian Fox]

For nexus we recommend making a group and using a mirror of *

Both of those artifacts should be in central


--Brian

On May 10, 2008, at 1:52 AM, "oliver.maven" <[EMAIL PROTECTED]>  
wrote:



hi,
i am using nexus indexer,i found i cant download the

1) org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9- 
stable-1


2) org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2

what is the address of repostiroy which contains the artifact?i  
think i should set proxy in nexus.


thanks a lot!



oliver.maven
2008-05-10


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bug in maven 2 -

[Brian Fox]

How are you using these properties? A copy of your PIM would help.  
Maven shouldn't hang, especially on an undefined property... It just  
goes through un-interpolated



--Brian

On May 14, 2008, at 1:44 PM, "EJ Ciramella" <[EMAIL PROTECTED]>  
wrote:



A colleague and I have found some strange behavior with the way
properties are expanded and how m2 works.

We've seen it such that if a property is undefined and you've  
activated

a profile that has build segments and this undefined property, maven
hangs just scanning for projects.

I couldn't find a similar bug in jira for this, has anyone else seen
this?

Re: Getting to the failed tests quickly

[Brian Fox]

You can also use -Dsurefile.useFile=false to output the error to  
stdout. I do this in Hudson also so that the emails contain the error.



--Brian

On May 14, 2008, at 12:39 PM, "Adam Hardy" <[EMAIL PROTECTED] 
> wrote:



Wayne Fay on 14/05/08 16:03, wrote:
>> I am using surefire to run our unit tests.  All goes well until a  
test fails
>> then I have to do some major seaching to find the problem.  The  
problem is
>> that there are loads of files created for the set of tests (one  
per class)

>> and no indication of which file I should look in.
>
> If you simply sort the output files by size (in a file manager
> interface or simply CLI), you will notice the successful tests will
> all be a particular file size (within a range, but the files are
> small) and then the failing tests are double that size or larger.

I just run site in continuum and look at the report -

or if you are cmd line-oriented, just cat the appropriate
target/surefire-reports/TEXT-com.mycompany.package.Test.xml



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Upgrading Maven 2.0.5 -> 2.0.9

[Brian Fox]

There appear to be no mismatches in the depmgt section, which is the  
part of the tool focused on the 2.0.5 upgrade.


There are some other dependency issues you can deal with  
separately..there is an explaination in chapter 8: http://www.sonatype.com/book


Sent from my iPhone

On May 28, 2008, at 10:47 AM, "Michael Delaney"  
<[EMAIL PROTECTED]> wrote:



Brian,

Sure ... please see the text below.

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO]
--- 
-


[INFO] Building Content Administrator APP
[INFO]task-segment: [dependency:analyze]
[INFO]
--- 
-


[INFO] Preparing dependency:analyze
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking
for updates from 
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin: checking
for updates from maven-repo1
[INFO] Ignoring available plugin update: 2.2 as it requires Maven
version 2.0.6
[INFO] Ignoring available plugin update: 2.4 as it requires Maven
version 2.0.8
[INFO] Ignoring available plugin update: 2.3 as it requires Maven
version 2.0.6
[WARNING]
Artifact findbugs:annotations:jar:1.1.0-rc5:provided retains
local scope 'provided' overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or  
remove

the local scope.

[INFO] [dependency:unpack-dependencies {execution: unpack}]
[INFO] Expanding: 
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [dependency:analyze]
[INFO] Used declared dependencies:
[INFO]atg:dss-classes:jar:2006.3:provided
[INFO]lty:lty-utils:jar:3.0.1.2:compile
[INFO]atg.publishing:base:jar:2006.3.P2:compile
[INFO]taglibs:standard:jar:1.1.2:provided
[INFO]atg:webui-classes:jar:2006.3.P2:compile
[INFO]junit:junit:jar:4.0:compile
[INFO]jboss:system:jar:3.2:compile
[INFO]jboss:common:jar:1.0:compile
[INFO]atg:das-servlet:jar:2006.3:provided
[INFO]atg:pubportlet-classes:jar:2006.3.P2:compile
[INFO]apache:axis:jar:1.4:compile
[INFO]jboss:jboss-j2ee:jar:4.0.4.GA:provided
[INFO]atg:dps-classes:jar:2006.3.P2:provided
[INFO]atg:das-classes:jar:2006.3.P2:provided
[INFO]atg:bizui-classes:jar:2006.3.P2:compile
[INFO]jboss:jmx:jar:1.0:compile
[INFO] Used undeclared dependencies:
[WARNING]commons-fileupload:commons-fileupload:jar:1.0:provided
[INFO] Unused declared dependencies:
[INFO]jakarta-poi:jakarta-poi:jar:1.5.1:compile
[INFO]commons-discovery:commons-discovery:jar:0.2:compile
[INFO]oracle:aq:jar:1.0:compile
[INFO]gnu:regexp:jar:x:compile
[INFO]oracle:jdbc:jar:10.0:compile
[INFO]lty:lty-utils-resources:jar:1.0.0.16:compile
[INFO]jcaptcha:jcaptcha-all:jar:RC2.0.1:compile
[INFO]velocity:velocity:jar:1.2:compile
[INFO]castor:castor_xml:jar:0.9.4.3:compile
[INFO]jboss:deploy:jar:1.0:compile
[INFO]org.apache:axis:jar:1.4:compile
[INFO]castor:castor:jar:0.9.4.3:compile
[INFO]geophile:jdbcwrapper:jar:1.0:compile
[INFO]aspectwerkz:aspectwerkz:jar:1.1:compile
[INFO]cactus-support:aspectjrt:jar:1.2.1:compile
[INFO]lty:capi:jar:1.2.0.27:compile
[INFO]xalan:xalan:jar:2.7.0:compile
[INFO]commons-net:commons-net:jar:1.3.0:compile
[INFO]com:oroinc:jar:1.0:compile
[INFO]commons-validator:commons-validator:jar:1.1.4:compile
[INFO]cactus-support:cactus:jar:1.7.2:compile
[INFO]xerces:xercesImpl:jar:2.8.0:compile
[WARNING] Potential problems discovered.
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO]Nothing in DepMgt.
[INFO]
--- 
-

[INFO] BUILD SUCCESSFUL
[INFO]
--- 
-

[INFO] Total time: 5 minutes 2 seconds
[INFO] Finished at: Wed May 28 10:38:46 EDT 2008
[INFO] Final Memory: 17M/127M
[INFO]
--- 
-


C:\work\up-svcs\lty\rel\LTY-R63.0\frontoffice\caApp>
-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 27, 2008 5:57 PM
To: Maven Users List
Subject: RE: Upgrading Maven 2.0.5 -> 2.0.9

Can you show the full output of running the command from the CLI?

-Original Message-
From: Michael Delaney [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 27, 2008 4:41 PM
To: Maven Users List
Subject: Upgrading Maven 2.0.5 -> 2.0.9

All,



I am testing out upgrading from Maven 2.0.5 to 2.0.9, I was reading
documentation that said that there were some dependency sanity checks
one s

Re: Upgrading Maven 2.0.5 -> 2.0.9

[Brian Fox]

Yes, the other part is clean

Sent from my iPhone

On May 28, 2008, at 11:22 AM, "Michael Delaney"  
<[EMAIL PROTECTED]> wrote:



I was basing my findings on the output where Maven stated "Potential
problems discovered". Is Maven just referring to the "Used undeclared
dependencies" and "Unused declared dependencies" sections?


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2008 11:03 AM
To: Maven Users List
Subject: Re: Upgrading Maven 2.0.5 -> 2.0.9

I don't see any "errors" here. What "errors" do you mean?

There are a few libs you have a dependency on but don't appear to be
using. So you could reduce the size of your app by getting rid of  
these

(as long as you aren't using Class.forName or META-INF/services or
similar to load them by reflection, which this tool obviously can't
detect). So you are warned to look into this.

And there is the findbugs:annotations issue, where some dependency  
wants

that jar bundled with the app, but you (or some other dependency) has
said that the jar will be "provided" at runtime. If the system into
which you deploy this code *really* has that already in the classpath,
then fine. Otherwise you need to fix the declaration that is forcing  
its

scope to provided. So you are warned to look into this.

Neither is *definitely* a problem, and neither seems to be a *change*
that upgrading maven will introduce. Instead they appear to be issues
that your code has always had.

Regards,
Simon

Michael Delaney schrieb:
> Brian,
>
>   Sure ... please see the text below.
>
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'dependency'.
> [INFO]
>
--- 
-

> 
> [INFO] Building Content Administrator APP
> [INFO]task-segment: [dependency:analyze]
> [INFO]
>
--- 
-

> 
> [INFO] Preparing dependency:analyze
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin:  
checking

> for updates from 
> [INFO] artifact org.apache.maven.plugins:maven-clean-plugin:  
checking

> for updates from maven-repo1
> [INFO] Ignoring available plugin update: 2.2 as it requires Maven
> version 2.0.6
> [INFO] Ignoring available plugin update: 2.4 as it requires Maven
> version 2.0.8
> [INFO] Ignoring available plugin update: 2.3 as it requires Maven
> version 2.0.6
> [WARNING]
> Artifact findbugs:annotations:jar:1.1.0-rc5:provided retains
> local scope 'provided' overriding broader scope 'compile'
> given by a dependency. If this is not intended, modify or
remove
> the local scope.
>
> [INFO] [dependency:unpack-dependencies {execution: unpack}]
> [INFO] Expanding: 
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [dependency:analyze]
> [INFO] Used declared dependencies:
> [INFO]atg:dss-classes:jar:2006.3:provided
> [INFO]lty:lty-utils:jar:3.0.1.2:compile
> [INFO]atg.publishing:base:jar:2006.3.P2:compile
> [INFO]taglibs:standard:jar:1.1.2:provided
> [INFO]atg:webui-classes:jar:2006.3.P2:compile
> [INFO]junit:junit:jar:4.0:compile
> [INFO]jboss:system:jar:3.2:compile
> [INFO]jboss:common:jar:1.0:compile
> [INFO]atg:das-servlet:jar:2006.3:provided
> [INFO]atg:pubportlet-classes:jar:2006.3.P2:compile
> [INFO]apache:axis:jar:1.4:compile
> [INFO]jboss:jboss-j2ee:jar:4.0.4.GA:provided
> [INFO]atg:dps-classes:jar:2006.3.P2:provided
> [INFO]atg:das-classes:jar:2006.3.P2:provided
> [INFO]atg:bizui-classes:jar:2006.3.P2:compile
> [INFO]jboss:jmx:jar:1.0:compile
> [INFO] Used undeclared dependencies:
> [WARNING]commons-fileupload:commons-fileupload:jar:1.0:provided
> [INFO] Unused declared dependencies:
> [INFO]jakarta-poi:jakarta-poi:jar:1.5.1:compile
> [INFO]commons-discovery:commons-discovery:jar:0.2:compile
> [INFO]oracle:aq:jar:1.0:compile
> [INFO]gnu:regexp:jar:x:compile
> [INFO]oracle:jdbc:jar:10.0:compile
> [INFO]lty:lty-utils-resources:jar:1.0.0.16:compile
> [INFO]jcaptcha:jcaptcha-all:jar:RC2.0.1:compile
> [INFO]velocity:velocity:jar:1.2:compile
> [INFO]castor:castor_xml:jar:0.9.4.3:compile
> [INFO]jboss:deploy:jar:1.0:compile
> [INFO]org.apache:axis:jar:1.4:compile
> [INFO]castor:castor:jar:0.9.4.3:compile
> [INFO]geophile:jdbcwrapper:jar:1.0:compile
> [INFO]aspectwerkz:aspectwerkz:jar:1.1:compile
> [INFO]cactus-support:aspectjrt:jar:1.2.1:compile
> [INFO]lty:capi:jar:1.2.0.27:compile
> [INFO]xalan:xalan:jar:2.7.0:compile
> [INFO]commons-net:commons-net:jar:1.3.0:compile
> [INFO]com:oro

Re: Tarball project

[Brian Fox]

Hi Chris,
You want the maven-assembly and maven-dependency to do this. I wrote about
it with examples[1]:
You can probably unpack directly to your target folder rather than filtering
as is shown in the example.
--Brian

[1] http://blogs.sonatype.com/brian/2008/04/17/120848550.html

On Thu, Jun 12, 2008 at 1:48 PM, Chris Berry <[EMAIL PROTECTED]> wrote:

> Greetings,
> I have a bunch of scripts (start, stop, perf, cleanup, install, etc
> scripts) that are the same for every project we have.
> Individual projects extend these scripts using simple local callbacks (i.e.
> local extension scripts).
>
> What I want to do is create a simple "tarball project" out of them, such
> that
> 1) The scripts are brought in as a regular Maven artifact (e.g
> ctrl-scripts.1.2.3.tar.gz)
> 2) The tarball is expanded into /target and then included into the
> project's assembly.
>
> I was wondering how best to accomplish this w/ Maven.
> 1) How does one create a "tarball project", where all artifacts are
> composed into a tar.gz as the artifact type
> 2) What is the best way to wire this tarball artifact into another project
> so that it gets expanded into target
>
> Thanks,
> -- Chris
> S'all good  ---   chriswberry at gmail dot com
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: generate bat/cmd with classpath?

[Brian Fox]

There is also the exec-maven-plugin

--Brian


On Jul 7, 2008, at 7:13 PM, "Kathryn Huxtable" <[EMAIL PROTECTED] 
> wrote:



On Jul 7, 2008, at 5:34 PM, Ken Liu wrote:

> Is there any easy way to have maven generate a cmd or bat file with
> the java
> command line populated with the classpath from the maven  
dependencies?


You could check out the codehaus mojo appassembler at

http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/

It's listed as "pre-release", but that applies to a lot of stuff we're
using in Maven-land.

You could also use the assembly plugin to build a lib directory
containing all the project dependencies, even including the project
jar. Then you could write a script that loops over the contents of
that directory, adding the jars to CLASSPATH. There are many examples
for both UN*X and Windows out there.

Or, having created the directory with dependencies, you could use
Dawid Weiss's invoker jar at


http://www.cs.put.poznan.pl/dweiss/xml/projects/invoker/index.xml?lang=en

-K

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: what happened to the plugin snapshots....

[Brian Fox]

As I said before, this was done by infra with no notice to us. The new  
policy of purging is theirs, not ours. See the infra archives if you  
would like to read about it.



On Aug 5, 2008, at 10:45 PM, "Patrick Moore" <[EMAIL PROTECTED]>  
wrote:


Of course this means that the maven team is imposing their idea of  
good
process on the other apache projects like tapestry which was also  
impacted

by this ...

I could understand this if the release occurs. (i.e. if 2.2 is  
released then

the 2.2-SNAPSHOT could be reasonably expected to be discarded)

part of the process of tracking down a bug involves going back to  
known
states of the code. Using the snapshots to diagnose when a bug  
appeared is

useful as people move toward a release.something to think about.

Just my 2c

clearly I will need to isolate my project in the future from the  
official
maven repos ... probably should do it anyhow but would have  
preferred to do

it later

-Pat

On Tue, Aug 5, 2008 at 3:53 PM, Brian E. Fox  
<[EMAIL PROTECTED]>wrote:


> The official answer is this:
> http://www.apache.org/dev/release.html#what
>
> Technically only the development team should be using snapshots  
and it

> seems like we should expect snapshots to be cleaned out on a more
> regular basis. Therefore if you use them, you better have a repo  
manager
> or some other way to isolate yourself. This is just plain best  
practice

> anyway.
>
> -Original Message-
> From: David Conde [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 05, 2008 8:20 AM
> To: [EMAIL PROTECTED]; users@maven.apache.org
> Subject: Re: what happened to the plugin snapshots
>
> Moving this onto the dev list.
>
> Are there plans to re-publish snapshots of these soon? I currently  
have
> a dependency on maven-embedder which brings in wagon etc which  
cannot be

>
> resolved now.
>
> Thanks,
> David Conde
>
>
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: How do I override a plugin dependency?

[Brian Fox]

Hi, I blogged about this with examples. I can't copy and paste on the  
iPhone but you can find it at http://blogs.Sonatype.com/brian


Sent from my iPhone

On Aug 23, 2008, at 8:08 AM, "Graham Leggett" <[EMAIL PROTECTED]> wrote:


Hi all,

I have a need to override a specific dependency used by the maven- 
torque-plugin, and I am struggling to convince maven v2.0.9 to do  
this.


The symptoms are that the original jar is being used, instead of the  
overridden jar, which is effectively ignored.


To test this, I have deleted the original jar completely from my  
local maven repository, and what I expect to happen is that maven  
should not try to download this dependency again, because it has  
been overridden.


In practise, maven downloads the original jar, and ignores the  
overridden jar.


Is there anything obvious that I have missed in this process?

My plugin definition looks like this:


 org.apache.torque
 torque-maven-plugin
 3.3
 
   
 org.apache.derby
 derby
 10.4.1.3
   
   
 org.apache.torque
 torque-templates
 3.3.1
   
 
   

Regards,
Graham
--


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: dependency plugin

[Brian Fox]

It is this goal in the dependency plugin, but in general when working  
with multimodule builds, you should just do install. Other plugins can  
have the same problems.


Sent from my iPhone

On Sep 12, 2008, at 10:10 PM, "Build Guy" <[EMAIL PROTECTED]> wrote:

well, the whole point is that... If module A's jar is a dependency  
thats

needed for compilation of Module B.
I don't need to use the install goal. Module B finds the Module A jar
when building from the parent.

How ever. If I further want to do something with Module A's jar in
Module B. Like extract it using dependency unpack.
I can't, unless I 1st run install goal from Module A. But this means  
the
release plugin won't properly work from the parent pom unless I  
release

Module A and B individually.

Here's what my project looks like:
-parent pom
  | - Module A (produces Jar)
  | - Module B (includes jar)

I'm wondering if this is just a limitation of the dependency  
plugin.. :-/


I've been struggling with this for quite some time.
Thought? thanks!

Taras

Dan Tran wrote:
> did you use install goal ?
>
> -D
>
> On Fri, Sep 12, 2008 at 6:54 PM, Build Guy <[EMAIL PROTECTED]> wrote:
>
>> Can some one please shine some light on the following scenario..
>>
>> I have parent pom and 2 modules.
>> Module A produces a jar file
>> Module B has Module A's jar as dependency, but it uses the  
dependency plugin

>> to unpack it.
>>
>> If I run mvn package from the parent. Module B's dependency  
plugin is always
>> trying to take the jar from the repository, not from Module A's  
target

>> So my build fails with [INFO] Unable to find artifact.
>>
>> I always have to run mvn install on Module A before using Module  
B. Quite

>> tedious..
>> And I do have the jar listed in Module B as a dependency and then  
again in

>> he plugin like so:
>>
>> 
>>  foo.bar
>>  myjar
>>  1.0.0-SNAPSHOT
>>  jar
>>  compile
>> 
>>
>> 
>>  org.apache.maven.plugins
>>  maven-dependency-plugin
>>  2.0
>>  
>>  
>>  getjar
>>  generate-sources
>>  
>>  unpack
>>  
>>  
>>  
>>  
>>  foo.bar
>>  myjar
>>  jar
>>  true
>>  
>>  target/tmp
>>  
>>  
>>  
>>  true
>>  true
>>  
>>  
>>  
>> 
>>
>> Any thoughts?
>> Thanks!
>>
>>  
-

>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] Maven Enforcer Plugin 1.0-alpha-4 Released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0-alpha-4

The Enforcer plugin provides goals to control certain environmental
constraints such as Maven version, JDK version and OS family along
with many more standard rules and user created rules.

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:





 org.apache.maven.plugins

 maven-enforcer-plugin

 1.0-alpha-4




Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-4


** Bug
* [MENFORCER-10] - EnforcerRuleHelper#getComponent() throws exception
* [MENFORCER-12] - enforce-once still runs in each child pom
* [MENFORCER-27] - Multi model project with enforcer plugin bug
* [MENFORCER-37] - 'noSnapshots' rule do not check version of parent
* [MENFORCER-45] - does not detect version for plugin configured in profiles

** Improvement
* [MENFORCER-11] - enforce-once causes MNG-2277 to be expressed in
reactor builds. Find a way to work around it.
* [MENFORCER-18] - Bean shell enforcer swallows message
* [MENFORCER-21] - allow includes to fine tune excludes in
bannedDependencies
* [MENFORCER-38] - Enforcer rules for AlwaysPass and AlwaysFail
* [MENFORCER-43] - RequireReleaseDeps - allow to execute "onlyWhenRelease"
* [MENFORCER-44] - the banSnapshot option in requirePluginVersions
should distinguish "SNAPSHOT" and timestamps

** New Feature
* [MENFORCER-15] - add a rule to enforce that all plugins have a
declared version
* [MENFORCER-22] - create a rule to check the current project is
not a snapshot

** Task
* [MENFORCER-32] - Add svn:eol-style=native to source files
* [MENFORCER-33] - Tidy up EvaluateBeanshell rule
* [MENFORCER-34] - Make code Java 1.4 compatible



Enjoy,



-The Maven team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[2.0.10 RC] Please test

[Brian Fox]

Hello,
We're moving forward with the 2.0.10 RC process. We have have not
turned up any new issues within the Dev team, so as usual we're
widening our net.

Here's the list of issues fixed in 2.0.10:

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName
=Html&projectId=10500&Create=Create

And I've staged RC-2 here:

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC2/



Please try it out and see if we have any remaining regressions over 2.0.9.

Thanks,

Brian

--

Brian Fox

Apache Maven PMC

http://blogs.sonatype.com/brian/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven includes old jar versions

[Brian Fox]

Do a clean install after changing the pom since the target folder  
would already have a copy of the previous version.


--Brian (mobile)


On Nov 12, 2008, at 9:52 AM, "Troy Bull" <[EMAIL PROTECTED]> wrote:


Greetings

I am brand new to maven and I have just noticed an issue.

I have a jar file that I maintain in my local maven repository (on my
workstation).  It has had several versions, 2.0.2, 2.0.3 2.0.5 etc.

I have a different project that is built with maven that uses this jar
file.  If I change the jar file I update the version of the jar file.

I then update my pom.xml file to fetch the new version of the jar.  I
opened up my war file and noticed quite by accident that mvn is
including all the versions of the jar file in the WEB-INF/lib
directory.  Is there something I need to do special to tell mvn to
only include the most recent version of the jar file?

Here is the section of the pom.xml that includes the jar file in  
question:




org.ifmc
ifmccommon
2.0.5.r5943
compile




Thanks in advance

Troy


--
A computer without a Microsoft operating system is like a dog without
bricks tied to its head.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[2.0.10 RC] Please test

[Brian Fox]

Hello,
This RC fixes the SCP wagon problem identified in RC2 (MNG-3717). No
other issues where identified in RC2 so hopefully this will become the
last RC.


Here's the list of issues fixed in 2.0.10:

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112&styleName
=Html&projectId=10500&Create=Create

And I've staged RC-3 here:

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC3/



Please try it out and see if we have any remaining regressions over 2.0.9.

Thanks,

Brian

------
Brian Fox
Apache Maven PMC
http://blogs.sonatype.com/people/brian/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to place the project classpath into a ressource file?

[Brian Fox]

You can use the maven-dependency-plugin:build-classpath goal

--Brian (mobile)


On Nov 29, 2008, at 11:28 AM, "Stephan Niedermeier" <[EMAIL PROTECTED] 
> wrote:



Hi,

I'm using Maven2 to build and assemble my project under Win XP.

The project contains a Java launcher. This launcher needs to know all
jars in the project. This will be done using a configuration file
(launcher.properties) and the property "app.classpath". The hard coded
entry for the property could look like this for example:

app.classpath=lib/commons-logging.jar;lib/commons-httpclient.jar

This works perfectly. But instead of hard coding and maintaining the
classpath in the configuration file as seen above, I would prefer  
using

some sort of Maven 2 Filter which calculates the classpath string
automatically and then places this string into my configuration file  
on

the predefined position. For example similar to this:

app.classpath=${someVarHoldingTheGeneratedClasspathString}

Im wondering whether there is a solution for this in Maven? I couldn't
find any hint in the Maven2 Filter docs, because there is no such
variable I could use. Maybe I have overseen something?

Any ideas how I can retrieve the classpath string and place it into my
configuration file?

PS: Putting the classpath into the META-INF using the   
tag is

not an option for me, because its not supported by the Launcher.

Thanks in advance.

Best regards
Stephan



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Third party jars

[Brian Fox]

You could save youself a lot of hassle with a repo manager. You  
shouldn't use local repos as remote repos because the metadata is  
different. Also with unmanaged repos, snapshot accumulation will  
become a problem.


--Brian (mobile)


On Nov 29, 2008, at 5:33 AM, "Alex Athanasopoulos" <[EMAIL PROTECTED] 
> wrote:



Why not put the jars in a repository?  A repository is perfect for
containing 3rd party jars, and one of maven's major benefits.  Once  
you do
that, you don't need to refer to the jars through a hardcoded path,  
but
simply by a portable artifact identifier.  You don't need any  
special tools
or repository managers, but you do need to setup your own remote  
repository

somehow.

I simply use mvn install:install-file, and then copy the generated  
files
from my local repository to a remote repository that I have created  
just for

3rd party libs.

I'm fairly new to maven, and this is one of the first things I had  
to do.

 The rest is just defining and managing repositories, which can be a
discussion of its own.  I'm not using any repository managers yet  
(learning

to live with maven is enough work for me right now).  My A-B-Cs of
repository management have been the following:

A)  At first I used only my local repository, which I shared with  
other
developers by putting it under version control in svn, just like I  
had my
3rd party libs before maven.   I used mvn -o most of the time, to  
avoid
accessing Maven's central repository.  I was a bit annoyed that I  
had to use

-o.  I tried to use the  configuration in settings.xml, but I
couldn't get it to work (one of my first frustrations with maven).   
mvn -o
worked reliably, but I had to remember to use it.  Whenever I needed  
a piece

of Maven that I didn't have, I used mvn without the -o flag, and once
everything worked, I added the new artifacts from my local  
repository to

svn.  I did not add my snapshots.

B)  I then figured out how to avoid the -o flag, by defining a  
mirror of the

central repository in my settings.xml.  The mirror was simply an
http-accessible location of the single svn-managed repository that I  
had.
 Whenever I needed to use a new piece of maven, I commented out the  
mirror
specifiction in my settings.xml, ran mvn so it could get new pieces  
from
repo1.maven.org, and then took the comment out of settings.xml.  The  
rest

was as in A.

C)  I now use two repositories:
1)  A repository of non-maven released artifacts.  Essentially this  
contains
3rd party libraries.  These are libraries that I've gotten directly  
from

their source, and which I've entered in the repository through
install:install-file.  I plan to also put my own released artifacts  
there.


2)  A central-mirror repository that has just the things that maven  
needs
(plugins and their dependencies).  This is the most difficult  
repository to
manage, and a source of problems, as I find maven's dependencies  
chaotic and

unstable.  This is why I've isolated them from my other artifacts.

D)  I plan to also use a snapshots repository that is automatically  
updated
with my daily build artifacts.  In fact, I may simply provide http  
access to

the daily build's local repository.
For now, I rebuild all of my artifacts locally.

Alex

On Fri, Nov 28, 2008 at 10:38 PM, <[EMAIL PROTECTED]>  
wrote:


> Hi,
>
> Is there any way to get the maven build process to include a set  
of jars
> when compiling/packaging that are not in the repository?  I have  
some
> vendor jars and I don't fancy packing them all up and placing them  
into

> the repository - I just want to point maven at a lib directory?
>
> Thanks,
>
>
> john
> ___
>
> This e-mail may contain information that is confidential,  
privileged or
> otherwise protected from disclosure. If you are not an intended  
recipient of
> this e-mail, do not duplicate or redistribute it by any means.  
Please delete
> it and any attachments and notify the sender that you have  
received it in
> error. Unless specifically indicated, this e-mail is not an offer  
to buy or
> sell or a solicitation to buy or sell any securities, investment  
products or

> other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays. Any views or  
opinions
> presented are solely those of the author and do not necessarily  
represent

> those of Barclays. This e-mail is subject to terms available at the
> following link: www.barcap.com/emaildisclaimer. By messaging with  
Barclays
> you consent to the foregoing.  Barclays Capital is the investment  
banking
> division of Barclays Bank PLC, a company registered in England  
(number
> 1026167) with its registered office at 1 Churchill Place, London,  
E14 5HP.
>  This email may relate to or be sent from other members of the  
Barclays

> Group.
> ___
>
>  
--

Re: How to place the project classpath into a ressource file?

[Brian Fox]

I don't think so but it should be easy to patch

--Brian (mobile)


On Nov 29, 2008, at 1:39 PM, Stephan Niedermeier <[EMAIL PROTECTED] 
> wrote:



Hi Brian,

thanks for the hint, but it seems that the build-classpath goal  
calculates the full path to the jars (e.g. C:/project/lib/ 
myJar.jar). Is there a way to make this path relatively to, let's  
say "lib/" of the assembled folder?


Thanks a lot.

Regards
Stephan

Brian Fox schrieb:

You can use the maven-dependency-plugin:build-classpath goal

--Brian (mobile)


On Nov 29, 2008, at 11:28 AM, "Stephan Niedermeier" <[EMAIL PROTECTED] 
> wrote:



Hi,

I'm using Maven2 to build and assemble my project under Win XP.

The project contains a Java launcher. This launcher needs to know  
all

jars in the project. This will be done using a configuration file
(launcher.properties) and the property "app.classpath". The hard  
coded

entry for the property could look like this for example:

app.classpath=lib/commons-logging.jar;lib/commons-httpclient.jar

This works perfectly. But instead of hard coding and maintaining the
classpath in the configuration file as seen above, I would prefer  
using

some sort of Maven 2 Filter which calculates the classpath string
automatically and then places this string into my configuration  
file on

the predefined position. For example similar to this:

app.classpath=${someVarHoldingTheGeneratedClasspathString}

Im wondering whether there is a solution for this in Maven? I  
couldn't

find any hint in the Maven2 Filter docs, because there is no such
variable I could use. Maybe I have overseen something?

Any ideas how I can retrieve the classpath string and place it  
into my

configuration file?

PS: Putting the classpath into the META-INF using the   
tag is

not an option for me, because its not supported by the Launcher.

Thanks in advance.

Best regards
Stephan



--- 
--

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to place the project classpath into a ressource file?

[Brian Fox]

Heh... I Forgot about that

--Brian (mobile)


On Nov 29, 2008, at 2:06 PM, Stephan Niedermeier <[EMAIL PROTECTED] 
> wrote:



Hi,

got it. Thanks. For those interested in:

Use the "prefix" together with the "outputFilterFile" parameter of  
the build-classpath goal. Example:


  
  org.apache.maven.plugins
  maven-dependency-plugin
  
  true
  lib
  
  

Regards
Stephan

Stephan Niedermeier schrieb:

Hi Brian,

thanks for the hint, but it seems that the build-classpath goal  
calculates the full path to the jars (e.g. C:/project/lib/ 
myJar.jar). Is there a way to make this path relatively to, let's  
say "lib/" of the assembled folder?


Thanks a lot.

Regards
Stephan

Brian Fox schrieb:

You can use the maven-dependency-plugin:build-classpath goal

--Brian (mobile)


On Nov 29, 2008, at 11:28 AM, "Stephan Niedermeier" <[EMAIL PROTECTED] 
> wrote:



Hi,

I'm using Maven2 to build and assemble my project under Win XP.

The project contains a Java launcher. This launcher needs to know  
all

jars in the project. This will be done using a configuration file
(launcher.properties) and the property "app.classpath". The hard  
coded

entry for the property could look like this for example:

app.classpath=lib/commons-logging.jar;lib/commons-httpclient.jar

This works perfectly. But instead of hard coding and maintaining  
the
classpath in the configuration file as seen above, I would prefer  
using

some sort of Maven 2 Filter which calculates the classpath string
automatically and then places this string into my configuration  
file on

the predefined position. For example similar to this:

app.classpath=${someVarHoldingTheGeneratedClasspathString}

Im wondering whether there is a solution for this in Maven? I  
couldn't

find any hint in the Maven2 Filter docs, because there is no such
variable I could use. Maybe I have overseen something?

Any ideas how I can retrieve the classpath string and place it  
into my

configuration file?

PS: Putting the classpath into the META-INF using the   
tag is

not an option for me, because its not supported by the Launcher.

Thanks in advance.

Best regards
Stephan



--- 
--

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Attaching artifacts

[Brian Fox]

Use the build-helper plugin

--Brian (mobile)


On Dec 4, 2008, at 8:25 AM, "Sommers, Elizabeth" <[EMAIL PROTECTED] 
> wrote:



Is there anyway to attach an artifact without writing a mojo to do it?
I would like to just do it with the pom if possible.

Liz Sommers
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Plugin that bundles Jetty + Webapp for release

[Brian Fox]

We use the assembly plugin to put the nexus bundle together. I have a
Plugin mostly written that can do it also but it's focused on using  
plexus and jsw in the bundle.


--Brian (mobile)


On Dec 4, 2008, at 5:20 PM, "Siegfried Goeschl" <[EMAIL PROTECTED] 
> wrote:



Hi Stephan,

I doubt there is a plugin doing this directly since it is a rather
specialized task. But you can achieve the same using an Ant script
invoked by Maven (maven-antrun-plugin) and/or the
maven-assembly-plugin.  Furthermore it should be possible to add this
distribution as "attached artifact" to the Maven build

Having said that you can have a look at
http://people.apache.org/~sgoeschl/download/wikionastick/ for some
inspiration ... :-)

+) it packages JSPWiki in ready-to-use distribution ("Wiki On A  
Stick")

+) it creates Windows and Mac OS X native application starter as well

Hope this helps

Siegfried Goeschl

Stephan Niedermeier wrote:
> Hi,
>
> I'm searching for a Maven plugin that is able to package my webapp
> together with Jetty, for example into a Zip file. Doing it this  
way, I

> could use this Zip file and distribute it "all in one".
>
> As far as I know, with the ordinary maven-jetty-plugin its only
> possible to run the "embedded" Jetty within Maven, but not to bundle
> Jetty with my webapp for a "release".
>
> Any hints for me about such a plugin? My search was not successful  
so

> far.
>
> Thanks in advance.
>
> Regards
> Stephan
>
>  
-

> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Repository

[Brian Fox]

Trying to download all 70gb from central will likely get you banned.  
Instead use a repository manager and let it cache the things you  
actually need.


--Brian (mobile)


On Dec 5, 2008, at 4:24 AM, "prasanna.goupal" <[EMAIL PROTECTED] 
> wrote:



Hi All,



Is there any way to download complete repository on my local machine  
instead

of checking & downloading required plaugins?



Thanks in advance.





Regards,

Prasanna A. Goupal



--
This electronic mail, together with the attached files, if any,  
(collectively "electronic mail" / "mail") is intended solely for the  
addressee(es) above, and may contain information which is  
confidential and/or legally privileged.If  you  have  received   
this  mail  in  error, we request you to advise us immediately  by  
sending a message by clicking "reply to" button. You should delete   
the  mail  from  your  hard drive/system, and if you have made any  
hard/physical copies of the mail, you should destroy the  
same.Unauthorised  use,  distribution,  disclosure or copying of  
this electronic mail is strictly prohibited, and may be unlawful.

Re: Using a SNAPSHOT version for a parent

[Brian Fox]

Yes it's right but make sure you have enabled snapshots for the repo  
in question. By default only releases are enabled for repos

--Brian (mobile)


On Dec 10, 2008, at 4:19 PM, "Todd Thiessen" <[EMAIL PROTECTED]>  
wrote:



If I deploy a SNAPSHOT version of a parent POM, POMs that reference it
do not automatically download (even when running a bootstrap profile).

ie: Is this supported?

  
theid
thegroup
0.0.1-SNAPSHOT
  

If the artifact already exists in my local repo, everything is fine.

However, if I deploy a released version of the artifact and change the
parent reference accordingly

  
theid
thegroup
0.0.1
  

POMs that reference it, automatically download it.

Is it supposed to work this way?

---
Todd Thiessen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Third party jars

[Brian Fox]

Yes we do have a tool for this

--Brian (mobile)


On Dec 24, 2008, at 3:55 PM, "John Stoneham"   
wrote:



On Wed, Dec 24, 2008 at 9:20 AM, Alex Athanasopoulos
 wrote:
Is there a way to convert a local repository into a remote  
repository, or

should I upload each artifact to Nexus again? (I have a few dozen).


I understand that Nexus 1.2 features some command-line scripts to do
exactly this sort of thing, and an option to regenerate
maven-metadata.xml. But Nexus stores as flat files on disk, so you
ought to be able to instantiate your Nexus repository and copy
directly in.

I'd venture to say any further discussion ought to move to the
nexus-users list however.

- John

-
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

[ANN] Maven Dependency Plugin 2.1 and Maven Dependency Analyzer 1.1 released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Dependency Plugin, version 2.1

This plugin is used to copy and unpack artifacts and dependencies. It
also provides visualization and optimization tools for your project
dependencies.

http://maven.apache.org/plugins/maven-dependency-plugin/

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-dependency-plugin
 2.1



Release Notes - Maven 2.x Dependency Plugin - Version 2.1


** Bug
* [MDEP-150] - Indeterministic artifact ordering can cause bogus warnings
* [MDEP-180] - Copy-dependencies useRepositoryLayout doesn't match
with maven layout
* [MDEP-181] - useRepositoryLayout does not create proper repository layout
* [MDEP-183] - Unpack goal cannot unpack sar files.

** Improvement
* [MDEP-148] - Use Set.contains() rather than manual iteration to
check for containment of class in artifact
* [MDEP-151] - Use File(URI) for converting from URI to File
* [MDEP-157] - "Unpack xxxto yyy" space

** New Feature
* [MDEP-178] - Create a goal to download single artifact transitively


Enjoy,

-The Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Clean Plugin 2.3 and Shared File Management 1.2.1 released

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Clean Plugin, version 2.3

This plugin is used to delete artifacts to provide a clean build.

http://maven.apache.org/plugins/maven-clean-plugin/

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-clean-plugin
 2.3



Release Notes - Maven 2.x Clean Plugin - Version 2.3
** Sub-task
* [MCLEAN-35] - Upgrade plexus-utils to a new version

** Bug
* [MCLEAN-28] - maven-clean-plugin doesn't delete directories with
symlinks in them
* [MCLEAN-29] - Maven clean plugin doesn't filter resources from
exclude list
* [MCLEAN-31] - Always resolve relative path against the project's
base directory
* [MCLEAN-34] - NPE when forcing delete of directory
* [MCLEAN-36] - filesets with an absolute path directory are
ignored when !project.isExecutionRoot()

** Improvement
* [MCLEAN-37] - Make verbose mode default to Maven's global debug mode

** New Feature
* [MCLEAN-33] - Cannot Supress Default clean while still cleaning



Enjoy,

-The Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unable to ping Maven Central repository's index location

[Brian Fox]

You should always fetch from repo1.maven.org/maven2/.index

On Tue, Jun 21, 2011 at 5:50 AM, amaresh mourya
 wrote:
> Hi,
>
> I am unable to ping [ http://repo2.maven.org.s3.amazonaws.com/.index/ ]
> location. Whereas ping to [ http://repo1.maven.org/maven2/.index ] is
> successful.
> Is the location of index data of maven central been changed?
>
> Thanks,
> Amaresh
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Mirrors and repositories

[Brian Fox]

> One reason you might do it is to enable a repository to be searched
> for snapshots.  By default, Maven's built-in definition of 'central'
> only has releases enabled.  Unless you define another repository
> somewhere that has snapshots enabled, Maven will never retrieve any
> snapshots.


This is exactly why ^^

You need to do the same for pluginRepositories if you ever want to get
snapshots of plugins.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Dependency Plugin behavior changed to copy timestamped snapshot jars

[Brian Fox]

If the snapshot was resolved from a repo then it will be timestamped,
if it came from the reactor or local repo, then it will be -SNAPSHOT.
The plugin calls into the maven resolution logic so this is core maven
behavior.

In 2.2, resolution from the reactor was introduced for these goals,
previously they would always go to the repository, this could be why
you see a change in the new version.


On Fri, Jul 15, 2011 at 5:28 AM, Reinhard Nägele
 wrote:
> Hi all,
>
> We use the dependency plugin's goal "copy-dependencies" in several projects.
> For snapshot dependencies, it would copy unique snapshot jars until version
> 2.1. Since version 2.2, the behavior has changed in that now timestamped
> snapshots are copied.
>
> I could not find this change anywhere in the release notes. In fact, it is
> not documented at all, what the correct behavior is supposed to be. Is
> anyone aware of this change? Has it happened on purpose or by accident?
> Anyway, I'd really like to get the old behavior back. I think this should be
> configurable.
>
> Any opinions or insights?
>
> Thanks,
> Reinhard
>
>
>
>
> -
> 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: Why would "unpack-dependencies" sometimes not do its job?

[Brian Fox]

you can set a flag to tell it to always unpack. I forget the exact
param, but it's in the docs.

On Tue, Jul 26, 2011 at 5:01 PM, KARR, DAVID (ATTSI)  wrote:
>> -Original Message-
>> From: GALLAGHER, RON (ATTSI)
>> Sent: Tuesday, July 26, 2011 12:03 PM
>> To: Maven Users List
>> Subject: RE: Why would "unpack-dependencies" sometimes not do its job?
>>
>> David,
>>
>> When the dependency plugin unpacks an artifact, it puts a marker file
>> in
>> the 'markersDirectory' [1] so that it doesn't unpack that same artifact
>> a second time.
>>
>> When you run "mvn clean", that 'markersDirectory' is cleared out, along
>> with all other build output.
>>
>> Is it possible that the absence of classes from your dependent jar
>> files
>> is due to the presence of one or more marker files in the
>> 'markersDirectory' that were placed there during the previous build?
>
> Ok, it happened again.  All the marker files are present, but 
> "target/classes" doesn't have the dependent classes.  I'll watch to see if 
> something else after this removes things from that tree.
>
>> [1]
>> http://maven.apache.org/plugins/maven-dependency-plugin/unpack-
>> dependenc
>> ies-mojo.html#markersDirectory
>>
>> Ron Gallagher
>>
>>
>> -Original Message-
>> From: KARR, DAVID (ATTSI)
>> Sent: Tuesday, July 26, 2011 1:02 PM
>> To: users@maven.apache.org
>> Subject: Why would "unpack-dependencies" sometimes not do its job?
>>
>> I'm using both "maven-dependency-plugin" and "maven-jar-plugin" so all
>> of my application classes and dependent classes go into a single jar
>> file.  Every once in a while I discover that the resulting jar file
>> doesn't have my dependent classes.  If I then do "mvn clean" and then
>> "mvn" (default goal of install), it works fine.  At the time it's
>> happened, I didn't have the presence of mind to check my
>> "target/classes" directory to verify it was "maven-dependency-plugin"
>> that failed to do its work.  As the job of "maven-jar-plugin" is much
>> simpler, I don't think it's likely this is the problem.
>>
>> My plugin configs follow this.
>>
>> Any ideas why this might be happening?
>>
>> --
>> 
>>       org.apache.maven.plugins
>>       maven-dependency-plugin
>>       2.3
>>       
>>               
>>                       copy
>>                       prepare-package
>>                       
>>                               unpack-dependencies
>>                       
>>                       
>>                               compile
>>                               test
>>
>> target/classes
>>                       
>>               
>>       
>> 
>> 
>>       org.apache.maven.plugins
>>       maven-jar-plugin
>>       2.3.1
>>       
>>               target/classes
>>               
>>                       
>>                               mypackage.MyClass
>>
>> true
>>                       
>>               
>>       
>> 
>> --
>>
>> -
>> 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: Why would "unpack-dependencies" sometimes not do its job?

[Brian Fox]

default is:

overWriteIfNewer=true
overWriteReleases = false
overWriteSnapshots=false

Setting the releases or snapshots to true will cause it to ignore the
if newer check.

On Wed, Jul 27, 2011 at 11:13 AM, KARR, DAVID (ATTSI)  wrote:
>> -Original Message-
>> From: Brian Fox [mailto:bri...@infinity.nu]
>> Sent: Tuesday, July 26, 2011 5:01 PM
>> To: Maven Users List
>> Subject: Re: Why would "unpack-dependencies" sometimes not do its job?
>>
>> you can set a flag to tell it to always unpack. I forget the exact
>> param, but it's in the docs.
>
> I just checked the doc page for "dependency:unpack-dependencies" and there's 
> no flag I can see that does this.
>
>> On Tue, Jul 26, 2011 at 5:01 PM, KARR, DAVID (ATTSI) 
>> wrote:
>> >> -Original Message-
>> >> From: GALLAGHER, RON (ATTSI)
>> >> Sent: Tuesday, July 26, 2011 12:03 PM
>> >> To: Maven Users List
>> >> Subject: RE: Why would "unpack-dependencies" sometimes not do its
>> job?
>> >>
>> >> David,
>> >>
>> >> When the dependency plugin unpacks an artifact, it puts a marker
>> file
>> >> in
>> >> the 'markersDirectory' [1] so that it doesn't unpack that same
>> artifact
>> >> a second time.
>> >>
>> >> When you run "mvn clean", that 'markersDirectory' is cleared out,
>> along
>> >> with all other build output.
>> >>
>> >> Is it possible that the absence of classes from your dependent jar
>> >> files
>> >> is due to the presence of one or more marker files in the
>> >> 'markersDirectory' that were placed there during the previous build?
>> >
>> > Ok, it happened again.  All the marker files are present, but
>> "target/classes" doesn't have the dependent classes.  I'll watch to see
>> if something else after this removes things from that tree.
>> >
>> >> [1]
>> >> http://maven.apache.org/plugins/maven-dependency-plugin/unpack-
>> >> dependenc
>> >> ies-mojo.html#markersDirectory
>> >>
>> >> Ron Gallagher
>> >>
>> >>
>> >> -Original Message-
>> >> From: KARR, DAVID (ATTSI)
>> >> Sent: Tuesday, July 26, 2011 1:02 PM
>> >> To: users@maven.apache.org
>> >> Subject: Why would "unpack-dependencies" sometimes not do its job?
>> >>
>> >> I'm using both "maven-dependency-plugin" and "maven-jar-plugin" so
>> all
>> >> of my application classes and dependent classes go into a single jar
>> >> file.  Every once in a while I discover that the resulting jar file
>> >> doesn't have my dependent classes.  If I then do "mvn clean" and
>> then
>> >> "mvn" (default goal of install), it works fine.  At the time it's
>> >> happened, I didn't have the presence of mind to check my
>> >> "target/classes" directory to verify it was "maven-dependency-
>> plugin"
>> >> that failed to do its work.  As the job of "maven-jar-plugin" is
>> much
>> >> simpler, I don't think it's likely this is the problem.
>> >>
>> >> My plugin configs follow this.
>> >>
>> >> Any ideas why this might be happening?
>> >>
>> >> --
>> >> 
>> >>       org.apache.maven.plugins
>> >>       maven-dependency-plugin
>> >>       2.3
>> >>       
>> >>               
>> >>                       copy
>> >>                       prepare-package
>> >>                       
>> >>                               unpack-dependencies
>> >>                       
>> >>                       
>> >>                               compile
>> >>                               test
>> >>
>> >> target/classes
>> >>                       
>> >>               
>> >>       
>> >> 
>> >> 
>> >>       org.apache.maven.plugins
>> >>       maven-jar-plugin
>> >>       2.3.1
>> >>       
>> >>               target/classes
>> >>               
>> >>                       
>> >>
>> mypackage.MyClass
>&

Re: dependency:copy and transitive dependencies of artifactItems

[Brian Fox]

You can't, copy-dependencies is intended to work on the current
project, and copy is intended to simply fetch another artifact only.

On Wed, Jul 27, 2011 at 4:15 PM, cowwoc  wrote:
> Brian,
>
> How do specify a project argument for "copy-dependencies"? That is, I need
> to copy the dependencies of another project (not the current one).
>
> Thanks,
> Gili
>
>
> Brian Fox-2 wrote:
>>
>> It does not support transitivity yet. You can use copy-dependencies and
>> combinations of the filters to get the artifacts you need
>>
>> Chris Burroughs wrote:
>>> I assumed from the frequent references to transitive dependencies at
>>> <http://maven.apache.org/plugins/maven-dependency-plugin/index.html>;
>>> that dependency:copy supported transitive dependencies of artifactItems.
>>>
>>> However, this appears to not be the case (at least as of a few years
>>> ago):
>>> http://www.mail-archive.com/users@maven.apache.org/msg55576.html
>>> http://jira.codehaus.org/browse/MDEP-182
>>>
>>> Can someone confirm that artifactItem still does not support transitive
>>> dependencies?  If not, is there a standard workaround or alternative?
>>>
>>> -
>>> 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
>>
>
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/dependency-copy-and-transitive-dependencies-of-artifactItems-tp116131p4640153.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

Central IP number changes

[Brian Fox]

We're moving around some switching gear to have faster internet access
for Central. Because of this, the ip numbers for the US Central
servers will change. This should not affect most users unless your
corporate IT has firewall rules locked to the old ips. You can see
more details about the change here:
http://www.sonatype.com/people/2011/07/the-central-repository-is-getting-faster-are-you-ready-for-the-new-ips/

Thanks,
Brian

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Central IP number changes

[Brian Fox]

As of this morning we enabled the global load balancing and users
closest to the EU Nameservers will start hitting the UK server
automatically.

On Fri, Jul 29, 2011 at 12:24 PM, Brian Fox  wrote:
> We're moving around some switching gear to have faster internet access
> for Central. Because of this, the ip numbers for the US Central
> servers will change. This should not affect most users unless your
> corporate IT has firewall rules locked to the old ips. You can see
> more details about the change here:
> http://www.sonatype.com/people/2011/07/the-central-repository-is-getting-faster-are-you-ready-for-the-new-ips/
>
> Thanks,
> Brian
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: If its' not one thing it's another

[Brian Fox]

It appears like you aren't using groups in Nexus. Your maven shouldn't
be telling you it's looking in the jboss repo, it should be looking in
your nexus group and nexus deals with the other repos. You would
normally do this in your settings with a mirrorOf * ->
nexus/content/groups/public for example

On Thu, Aug 4, 2011 at 11:32 AM, Eric Kolotyluk
 wrote:
> When I set up Nexus I set it up to mirror the JBoss repository. It synced up
> with JBoss last week and everything was working fine.
>
> Isn't the idea of having a central repository manager like Nexus that you
> are isolated against problems with the real repositories?
>
> Cheers, Eric
>
> On Wed, Aug 3, 2011 at 11:07 PM, d...@xanthippe.ping.de <
> d...@xanthippe.ping.de> wrote:
>
>> This is the JBoss repository, it is very unreliable. If you don't need to
>> resolve dependencies, try building offline.
>>
>> -dirk
>>
>> -
>> 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: com.sun.jersey:jersey-project:1.1.4:pom artifact differs on Maven Central and java.net

[Brian Fox]

What is the failure that you're seeing here? The changes look
appropriate since the contents of maven/1 and maven/2 are now in
Central, so removing those repo declarations should have no effect.

On Fri, Aug 19, 2011 at 10:18 AM, Blaney, Kyle (Kyle)  wrote:
> We recently encountered a strange Maven build error and the root cause turned 
> out to be that the com.sun.jersey:jersey-project:1.1.4:pom artifact differs 
> on Maven Central and java.net.  In particular, on java.net 
> (http://download.java.net/maven/2/com/sun/jersey/jersey-project/1.1.4/jersey-project-1.1.4.pom)
>  the pom.xml defines two repositories (http://download.java.net/maven/1 and 
> http://download.java.net/maven/2) and the same two plugin repositories, while 
> on Maven Central 
> (http://search.maven.org/remotecontent?filepath=com/sun/jersey/jersey-project/1.1.4/jersey-project-1.1.4.pom)
>  the pom.xml only defines the second plugin repository; there are no 
> repositories defined.
>
> Is there a recommended way to reconcile the differences in a non-SNAPSHOT 
> numbered artifact between Maven Central and java.net so that others don't 
> experience my pain?
>
> Kyle Blaney
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: com.sun.jersey:jersey-project:1.1.4:pom artifact differs on Maven Central and java.net

[Brian Fox]

This is even stranger. That jar is/has been in central:
http://search.maven.org/#artifactdetails|org.springframework|spring|2.5.6|jar

The changes to the jersey pom shouldn't have affected this at all.

On Fri, Aug 19, 2011 at 1:26 PM, Blaney, Kyle (Kyle)  wrote:
> Brian,
>
> The following build failure occurs when a project specifies a direct 
> dependency on com.sun.jersey.contribs:jersey-spring:1.1.4:jar:
>
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to resolve artifact.
>
> Missing:
> --
> 1) org.springframework:spring:jar:2.5.6
>
>  Try downloading the file manually from the project website.
>
>  Then, install it using the command:
>      mvn install:install-file -DgroupId=org.springframework 
> -DartifactId=spring
>  -Dversion=2.5.6 -Dpackaging=jar -Dfile=/path/to/file
>
>  Alternatively, if you host your own repository you can deploy the file there:
>
>      mvn deploy:deploy-file -DgroupId=org.springframework -DartifactId=spring 
> -
> Dversion=2.5.6 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] 
> -DrepositoryId=[
> id]
>
>  Path to dependency:
>        1) com.avaya.kblaney:test-aie:jar:3.0.0-SNAPSHOT
>        2) com.sun.jersey.contribs:jersey-spring:jar:1.1.4
>        3) org.springframework:spring:jar:2.5.6
>
> --
> 1 required artifact is missing.
>
> for artifact:
>  com.avaya.kblaney:test-aie:jar:3.0.0-SNAPSHOT
>
> from the specified remote repositories:
>  central (http://nexus.forge.avaya.com/content/groups/public),
>  ace_special (http://nexus.forge.avaya.com/content/repositories/ace_special)
> ---
>
> Note that the com.springframework:spring artifact does in fact exist in our 
> "central" repository.  I called the build error strange because the failure 
> only occurs with certain combinations of repositories defined in pom.xml and 
> mirrors defined in settings.xml.  I will provide the pom.xml and settings.xml 
> if necessary.
>
> So far, we have discovered the following workarounds:
>
> 1.  In pom.xml, specify a direct dependency on 
> org.springframework:spring:2.5.6 (even though it's not really a direct 
> dependency; rather, it's a transitive dependency of 
> com.sun.jersey.contribs:jersey-spring:1.1.4).  I don't understand why 
> changing the dependency to a direct one gets Maven to download it from our 
> central repo, but it does.
>
> 2.  In pom.xml, specify our Nexus java.net copy as the first repository and 
> in settings.xml, specify our Nexus java.net copy as the first mirror.
>
> Kyle
>
>
> -Original Message-
> From: Brian Fox [mailto:bri...@infinity.nu]
> Sent: Friday, August 19, 2011 12:33 PM
> To: Maven Users List
> Subject: Re: com.sun.jersey:jersey-project:1.1.4:pom artifact differs on 
> Maven Central and java.net
>
> What is the failure that you're seeing here? The changes look
> appropriate since the contents of maven/1 and maven/2 are now in
> Central, so removing those repo declarations should have no effect.
>
> On Fri, Aug 19, 2011 at 10:18 AM, Blaney, Kyle (Kyle)  
> wrote:
>> We recently encountered a strange Maven build error and the root cause 
>> turned out to be that the com.sun.jersey:jersey-project:1.1.4:pom artifact 
>> differs on Maven Central and java.net.  In particular, on java.net 
>> (http://download.java.net/maven/2/com/sun/jersey/jersey-project/1.1.4/jersey-project-1.1.4.pom)
>>  the pom.xml defines two repositories (http://download.java.net/maven/1 and 
>> http://download.java.net/maven/2) and the same two plugin repositories, 
>> while on Maven Central 
>> (http://search.maven.org/remotecontent?filepath=com/sun/jersey/jersey-project/1.1.4/jersey-project-1.1.4.pom)
>>  the pom.xml only defines the second plugin repository; there are no 
>> repositories defined.
>>
>> Is there a recommended way to reconcile the differences in a non-SNAPSHOT 
>> numbered artifact between Maven Central and java.net so that others don't 
>> experience my pain?
>>
>> Kyle Blaney
>>
>
> -
> 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: com.sun.jersey:jersey-project:1.1.4:pom artifact differs on Maven Central and java.net

[Brian Fox]

On Fri, Aug 19, 2011 at 4:35 PM, Thiessen, Todd (Todd)
 wrote:
> Thanks for clarifying. Hopefully we can get some advice here wrt the policies 
> regarding different artifacts with the same GAV.

This is a very rare circumstance. What happened was we merged java.net
with Central. Anything that was already in Central stayed that way, so
it's possible that java.net had slightly altered versions of artifacts
or poms...exactly what bringing some controls to Java.net was intended
to resolve.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Nexus help

[Brian Fox]

It's because Github returns a 404 on your repo:
https://raw.github.com/davidhoyt/mvn-repo/master/maven2/snapshots/ and
this makes Nexus think the repo isn't available. Disable the Auto
blocking and it should work.

On Tue, Aug 23, 2011 at 2:28 AM, Hoyt, David  wrote:
> I'm trying to setup a micro repository (yes, I know they're frowned upon) 
> that I can proxy with sonatype nexus v1.9.2.2. I can proxy other repos. just 
> fine, but for some reason with mine, I get the following error:
>
> jvm 1    | 2011-08-22 23:05:20 WARN  [oxy-2-thread-75] - 
> org.sonatype.nexus.proxy.maven.maven2.M2Repository - Remote peer of proxy 
> repository "Micro" (id=
> micro-repo) threw a org.sonatype.nexus.proxy.ItemNotFoundException exception. 
> - Cause(s): Item not found on path "/"!
>
> You can view the repo at: 
> https://github.com/davidhoyt/mvn-repo/tree/master/maven2/snapshots
>
> I've configured the proxy through nexus using the following values:
>
> - Remote Storage Location: 
> https://raw.github.com/davidhoyt/mvn-repo/master/maven2/snapshots/
> - Download Remote Indexes: True
> - Auto blocking active: True
> - Repository Policy: Snapshots
>
> The odd thing is that if I tell my projects to not use the local mirror and 
> go straight to the repos., they can find and download the libs just fine. But 
> the nexus server can't. Am I missing anything? I've tried to find some 
> documentation on what files are needed, but I couldn't find much.
>
> I hope this is the appropriate place to post this -- I couldn't find any 
> forums or mailing lists dedicated to the free nexus version.
>
> I appreciate any help that can be provided. Thanks!
>
> Cheers,
> - David Hoyt
>
> -
> 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: how to get the list of artifacts id and group id from maven repository?

[Brian Fox]

If this is an external repo: If the repository publishes an index, use
that. Otherwise, what you're doing would likely be perceived as
scraping and get you banned from remote repositories.

If this is an internal repo, then use the maven-indexer to produce an
index for you.

On Mon, Aug 29, 2011 at 6:33 AM, mumbaimuru
 wrote:
> how to get the list of artifacts id and group id from maven repository? Not
> using any maven explore. As we are get the latest version for any dependency
> using LATEST in POM.xml.
>
> I need same kind of process to get the list of artifacts id and group id
> from maven repository. In single short/process i want to get the all
> articfats and group ids.
>
> Thanks in advance.
>
> Regards,
> Murugesan.
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/how-to-get-the-list-of-artifacts-id-and-group-id-from-maven-repository-tp4745740p4745740.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

Re: Authorization failed for jboss maven repository

[Brian Fox]

> I google'd for "jboss maven repo moved" and found the following blog
> post which explains this repo was deprecated over a year ago and was
> finally shut down in early June 2011.
> http://community.jboss.org/en/build/blog/2011/06/01/blocking-repositoryjbossorgmaven2

My money is on ^^^

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: -gs does not apply to the forked maven execution in release:prepare

[Brian Fox]

Release forks the build and therefore not all the parameters are
passed through. There is a parameter for the plugin though to specify
which agurments to pass, I forget what it is, but I'm sure you know
how to find it ;-)

On Sun, Sep 4, 2011 at 1:48 PM, Benson Margulies  wrote:
> I was a bit taken aback when a run of the maven release plugin failed
> because I ran
>
>   mvn -gs my_settings.xml release:prepare
>
> and then the build couldn't find the repositories from the global settings?
>
> Is there really on purpose, or should I write up a JIRA?
>
> -
> 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: Forbiden? http://repo1.maven.apache.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar

[Brian Fox]

Maybe you're behind a firewall that hasn't adjusted to the new ips?

http://www.sonatype.com/people/2011/07/the-central-repository-is-getting-faster-are-you-ready-for-the-new-ips/

On Wed, Aug 31, 2011 at 5:49 PM, Jason Pyeron  wrote:
> Not sure if this is the right place to ask, but I am getting a 403 error on
> http://repo1.maven.apache.org/maven2/junit/junit/3.8.2/junit-3.8.2.jar
>
> http://repo1.maven.apache.org/maven2/junit/junit/3.8.2/
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -                                                               -
> - Jason Pyeron                      PD Inc. http://www.pdinc.us -
> - Principal Consultant              10 West 24th Street #100    -
> - +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
> -                                                               -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
>
> -
> 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 central repository

[Brian Fox]

A new version of the indexer was released and requested to be rerun
over central. That means a new full index was generated, when
typically it is just an incremental index. The size of the file and
speed of ibiblio seems to be giving some people trouble. But it should
sort itself out, besides resetting the incrmental chain, there were no
changes.

On Fri, Oct 14, 2011 at 3:18 AM, Olivier Lamy  wrote:
> http://repo1.maven.org/maven2/.index/ redirect to
> http://mirrors.ibiblio.org/pub/mirrors/maven2/dot-index/ which doesn't
> work nice
>
>
>
> 2011/10/14 stefano.cazzola :
>> Hi everybody,
>> I've been using Maven for a while, but now I'm facing a problem I can't
>> understand.
>> In the last days I've not been able to update index for maven central
>> repository at http://repo1.maven.org/maven2 both from m2eclipse and from a
>> proxy on my Nexus.
>> Nothing changed in my network configuration, so I was wodering if there's a
>> problem on the repo.
>>
>> Thanks,
>> Stefano
>>
>> --
>> View this message in context: 
>> http://maven.40175.n5.nabble.com/Maven-central-repository-tp4901567p4901567.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
>>
>>
>
>
>
> --
> Olivier Lamy
> Talend : http://talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> 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: Unable to download plugin from Nexus

[Brian Fox]

It looks to me like your settings.xml isn't defining a pluginRepository.

On Thu, Nov 10, 2011 at 7:09 AM, brian2011  wrote:
> Hi,
>
> I'm using Maven 2.2.1 and  Nexus 1.7.2. Nexus is configured as an internal
> repository manager with a single nexus group to external repository such as
> maven central.
>
> Running mvn site, I'm getting the following error:
>
> -
> [DEBUG] Wagons to register: [https, scp, https-httpclient, scpexe, sftp,
> http-lightweight, dav+https, http-httpclient, https-lightweight, dav+http,
> http, file,davs, dav]
> [INFO]
> 
> [INFO] Building Pricing Project
> [INFO]    task-segment: [site:site]
> [INFO]
> 
> [DEBUG] maven-javadoc-plugin: resolved to version 2.8.1-SNAPSHOT from
> repository central
> [DEBUG] Skipping disabled repository central
> [DEBUG] maven-javadoc-plugin: using locally installed snapshot
> [DEBUG] Skipping disabled repository central
> [DEBUG] Using mirror:
> http://hkgpsm02420:8081/nexus/content/groups/public (id: pub-repo)
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.apache.maven.plugins:maven-javadoc-plugin
>
> Reason: Error getting POM for
> 'org.apache.maven.plugins:maven-javadoc-plugin' from the repository: Failed
> to resolve artifact, possibly due to a repository list
>  that is not appropriately equipped for this artifact's metadata.
>  org.apache.maven.plugins:maven-javadoc-plugin:pom:2.8.1-SNAPSHOT
>
> from the specified remote repositories:
>  pub-repo (http://hkgpsm02420:8081/nexus/content/groups/public)
>
>  for project org.apache.maven.plugins:maven-javadoc-plugin
>
> The download of the required dependencies is working as expected. Only the
> plugins are not retrieved from the internal repository. Any ideas?
>
> Thanks.
>
>
>
> --
> View this message in context: 
> http://maven.40175.n5.nabble.com/Unable-to-download-plugin-from-Nexus-tp4980858p4980858.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

Re: How to get access to ALL the data in maven central?

[Brian Fox]

Make a request here and I can attach the poms for you:
https://issues.sonatype.org/browse/MVNCENTRAL

On Tue, Apr 10, 2012 at 1:17 PM, Wayne Fay  wrote:

> > If you wanted to scrape Maven Central for just the poms then I'd
> > contact Sonatype who manage the central repository.
>
> As Barrie said, you could talk to Sonatype (Brian specifically) since
> they operate the Maven Central repo and they might be able to make a
> zip file available that would be the result of tar'ing all the pom
> files (no artifacts) in Central. I know you have a solution with rsync
> but this might save some time.
>
> Alternatively you could run your own local Repo Manager (Archiva,
> Artifactory, Nexus) which would cache all the artifacts and poms. The
> Aether API might be a useful thing to look at as well. You may be able
> to specify "just pull down the pom file and not the jar" in the API at
> least for the first pass, then decide if you want the jars as well for
> a second pass later.
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: How to replicate company internal repository?

[Brian Fox]

Everything is stored in the sonatype-work/nexus folder. Copy that folder to
another machine and you have duplicated your entire instance.

On Thu, Apr 26, 2012 at 10:01 PM, hujirong  wrote:

> The one I am using in my test environment is not professional, but a free
> one. I don't see anywhere a "copy" function. Is there a way to
> export/import
> or something like that to replicate data from production to my test
> environment.
>
> Thanks
> Jirong
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/How-to-replicate-company-internal-repository-tp5663623p5669083.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
>
>

[ANN] Maven 2.0.10 Release

[Brian Fox]

The Maven team is pleased to announce the release of the Maven 2.0.10

This is a stable bug fix release and you can see the full list of
issues fixed at
http://maven.apache.org/release-notes.html

Enjoy,

-The Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Enforcer Plugin 1.0-beta-1

[Brian Fox]

The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0-beta-1

The Enforcer plugin is used to fail a build if certain constraints are
not met. There are too many standard rules to describe here, but check
out the site for more details:

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-enforcer-plugin
 1.0-beta-1



Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-beta-1

** Bug
* [MENFORCER-30] - RequirePluginVersions breaks when using
project.parent.groupId and project.parent.version.
* [MENFORCER-31] - Incorrect documentation for writing a custom rule
* [MENFORCER-53] - incorrect documentation: states
uncheckedPlugins parameter of Require Plugin Versions, but is
unCheckedPlugins (wrong case)
* [MENFORCER-55] - requirePluginVersions is not compatable with
Maven embedder (used in IDEs)
* [MENFORCER-56] - NPE if  contains an unset variable
* [MENFORCER-57] - Enforcer does not resolve local parent pom
* [MENFORCER-58] - typo in rule-api documentation
* [MENFORCER-60] - throw an error instead of failing the rule if
the beanshell is invalid
* [MENFORCER-62] - requirePluginVesions: avoid checking
commandline-invoked mojos

** Improvement
* [MENFORCER-48] - Support for a specific vendor of a JDK
* [MENFORCER-59] - add the ability to be more selective with
banned repositories

Enjoy,
The Maven Team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Understanding SNAPSHOTS

[Brian Fox]

Hello,

We have our CI system setup to build after every commit for verification. It 
happens to build on a grid with multiple
OS's and one of them deploys a snapshot to our Nexus repo. Our QA grabs the 
latest snapshot of the application at
various times and validates the fixes against it. (they look for jira issues 
marked as resolved - as opposed to closed).
This happens repeatedly during the normal development cycle. 

Once everything has been validated at least once (new features and bug fixes), 
then we stage a release build using the
Nexus Pro Staging[1] feature. These staged releases are not publicly viewable 
(but our snapshot repo for OSS is). They
will then grab the staged release and do more regression and final verification 
of that build. This process also repeats
but it is intended to converge to a stable release -- the development team at 
this point has moved on to the next
release and only things we deem critical are fixed at this point. We typically 
restage 1-3 times over a period of 2-3
days.

If a staged build is needed again, we just drop the staging repo and restage 
it. If everything is good, then we promote
it and it becomes publicly available. All of this is managed by the staging 
lifecycle.

So to specifically answer your questions:

>Does the Nexus dev team ever create a release of Nexus that is meant for
>internal purposes only?  For instance, do you have a verification team
>and if so, how do you distribute a build that you want the verification
>team to test?

Yes. This is our staged release, but by this point we expect everything is 
good. We usually find something at this
point, but rarely is it a huge issue since everything has already been tested. 
We use the Pro Staging feature to do
this.

>I have always thought of SNAPSHOTS as a version that is strictly meant
>to track nightly builds or builds between developers.

It is, but we operate in an agile fashion so qa is included in the team and 
they are looking at snapshots as well. This
provides us the quickest feedback on fixes during the cycle.

[1] http://www.sonatype.com/books/nexus-book/reference/staging.html
And a video: 
http://www.sonatype.com/people/2009/01/nexus-professional-what-is-staging/

-Original Message-
From: Todd Thiessen [mailto:thies...@nortel.com] 
Sent: Tuesday, April 07, 2009 9:32 AM
To: Maven Users List
Cc: Guillaume Goulet; Kevin Coupland; Kyle Blaney
Subject: Understanding SNAPSHOTS

I have been thinking alot lately about SNAPSHOTS and how to best utilize
them. I think I perhaps have misunderstood them and I wanted to see what
kind of responses I get from the community, particularly from the guys
at Sonatype.

I took a look at Nexus (which I am using as a good example of a Maven
project) to see what kind of versioning it uses.  Users of Nexus
generally only ever see released versions of it. ie: version 1.2.0.1,
1.2.0.2, 1.3.0 and so on and so forth.

Does the Nexus dev team ever create a release of Nexus that is meant for
internal purposes only?  For instance, do you have a verification team
and if so, how do you distribute a build that you want the verification
team to test?

I suspect your verificaton is done on a SNAPSHOT version, which I
believe is one of my big misconceptions of what SNAPSHOTS are meant for.
I have always thought of SNAPSHOTS as a version that is strictly meant
to track nightly builds or builds between developers.

However, now I am not so sure. Is it reasonable to work with a SNAPSHOT
in your local repostiory, do a number of unit tests and sanity on that
SNAPSHOT and then deploy a version of that SNAPSHOT to your corporate
maven repository to share with the rest of the company/community so that
they can use it and test against it? A SNAPSHOT is time stamped so a
consumer can always know exactly what version they are using.

Am I off my rocker? (well, I supose thats a seperate question ;-))

---
Todd Thiessen

-
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: Understanding SNAPSHOTS

[Brian Fox]

>1. How to distinguish snapshot build versions correctly? So that one
>snapshot build would not overwrite previous one in the repository.

You don't, that's not the purpose. If you truly care about a particular 
snapshot version, then it should have been a
release. It's meant only for looking at the latest version of unreleased code.

>2. How to set up correctly CI server to perform nightly and release
>builds not using maven SCM plug-ins (since our CI system has far richer
>functionality in this field).

This is a bit trickier but there are some plugins available in Hudson to do 
this. We don't provide nightly releases,
that's too much overhead. With the staging support, we are able to manage this 
directly from Maven on an intentional
release basis...that is we decide when a release is ready and use the release 
plugin to do this. The CI is only
producing snapshots on a constant basis.

>3. When a developer starts a build on his own machine which version
>should he use? There is always a risk that he will destroy an artifact
>in the repository.

Not if you setup the permissions correctly, and especially not with staging 
support. Each build from a developer would
go into their own staging repo created on the fly. It's impossible to 
accidentally release directly to your repo with
this setup.

>4. How to perform automatic pom project version update? I am not talking
>about updating dependency versions to the "latest version". I want to
>have a build version passed from the CI server automatically in the pom
>file in the repository. At the moment the recommended way is to update
>it manually, as I understand.

I do it manually, but there are tools like the versions-maven-plugin that can 
assist you.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Understanding SNAPSHOTS

[Brian Fox]

>So your formal releases are produced by manually running the release
>plugin? And if it fails, you manually do a rollback, depending on the
>failure?

Yes, we manually roll it back. It's not too bad with svn, but a bit annoying 
I'll admit. We haven't tackled the release
tools yet.

>Some of our teams wish to automate the creation of a release say every
>week and include all feature and bug fixes for that week in the release.
>The problem of course is that the release plugin commits changes to the
>trunk. If for whatever reason the formal build fails, and no person is
>there to immediately investigate and do a rollback, you could have your
>trunk in an bad state which is something we of course wish to avoid.

When we start to converge on a release, we cut a branch for that release 
stream. That means that when we actually start
staging releases, the devs have moved on to the next release which is another 
trunk/branch.

So for example, we had recently done 1.3.1. At the time that occurred, we 
branched it off and the mainline became 1.3.2
(there is 1.4 as trunk but irrelevant for now). We staged the 1.3.1 releases 
off of that rolling back as needed.
Eventually 1.3.1 became idle until we did a quick patch for 1.3.1.1. As we got 
closer to 1.3.2, we spun that off to a
branch and the mainline became 1.3.3 etc. Typically the devs work on the 
mainline and merge back to the release branch
once it's cut, but it could go either way.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Understanding SNAPSHOTS

[Brian Fox]

>Regarding snapshots and the way your QA works it all looks like you have
>adjusted your team workflow to the features the maven tool provides. 

Yes, this comes from years of using the tool, but is also adapted to our 
current environment.

>And
>these features are not so flexible to cover all requirements of ISO
>driven development for instance. For example, need to distinguish and be
>able to recreate everything that gets officially built. If you say, that
>in this case we need to do only releases, then we don't need snapshots
>at all and would loose an option to use different repos for different
>build types.

I don't understand this statement. We produce releases whenever it needs to be 
traceable, those releases are
deterministic and rebuildable if needed from source. In a previous company, the 
snapshots were not used by qa, all
deliveries to qa where release builds. We used a 4 digit versioning where the 
last number was just a build number. We
did this because it wasn't known ahead of time if a given build would pass qa 
and be officially released. How you use
the system is up to your individual requirements.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: settings.xml precedence

[Brian Fox]

The -D doesn't change the settings,  -s does. This most likely only 
overrides the user settings file, but the global one in the maven 
install /conf folder would still be referenced if it exists.


Jim McCaskey wrote:

Hello all,

I'm having some trouble tracking down how the precedence works for 
settings.xml.  I have a settings.xml in my ~/.m2 directory.  However, when I 
invoke a build I pass -Dorg.apache.maven.global-settings on the command line.  
Should Maven not use the setting.xml specified on the command line?  It seems 
to be using the one in the ~/.m2 directory.  Is there any way to make it ignore 
the ~/.m2 directory version?

The CLI does not appear to be referenced in the settings reference:

http://maven.apache.org/settings.html

FWIW, I'm using Maven 2.1.

-Jim


-
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: Weird problem downloading snapshots with Nexus

[Brian Fox]

Whenever you see Maven making requests for -SNAPSHOT (and you don't have 
it configured with useUnique = false) it always  means that the 
maven-metadata.xml file for that snapshot is wrong or couldn't be found. 
It's hard to say why that could have happened, but this often happens if 
you do a build offline (or while the repo is offline) and then Maven 
remembers this missing data.


Reinhard Nägele wrote:

Hello,

This morning, I updated our Nexus version from 1.3.1.1 to 1.3.2. After 
that my builds did not run because they failed to download snapshot 
dependencies from a hosted repository. As yesterday everything was 
still fine, I suspected a regression in Nexus, went back to 1.3.1.1, 
but the problem persisted.


Investigating further, I noticed that Maven tried to download unique 
snapshots versions instead of the timestamped ones. This explained why 
the snapshots would not be found. So, something must have messed up my 
local repository. Next, I tried "mvn 
dependency:purge-local-repository" but that did not work either 
because it would also try to download the unique version. So, I 
eventually purged my local repo manually, and the problem was gone.


I'd appreciate any insight into what was going on here. Did I do 
anything wrong? Did metadata get messed up somehow?


Thanks,
Reinhard


-
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: What is the best Maven book (or material) for new users?

[Brian Fox]

That alpha copy is a very, very old version and is not even close to 
what was printed (which is by now old). The latest and greatest is 
published regularly here:

http://www.sonatype.com/products/maven/documentation/book-defguide

javidjamae wrote:

There is an "alpha" copy of The Definitive Guide online:
http://propellors.net/maven/book/

I've been reading through it I've found it to be very good, and I'm planning
on picking up a print copy soon.

I won't claim it to be "the best" material available by any means, but I've
created a few introductory screencasts on Maven at
http://javidjamae.com/screencasts/

Javid


Grant Rettke wrote:
  

What is the best Maven book (or material) for new users?

I am tasked with decomposing an existing system that contains 21 POM
files, so, I have a lot of work ahead of me and I'm looking for the
best resource possible.




  

Re: Get list of provided dependencies in own Mojo

[Brian Fox]

Take a look at the dependency plugin source. There are filters to get 
the correct scope.


Gert Vanthienen wrote:

L.S.,

I'm writing a plugin and would like to get a list of artifacts for the
provided dependencies (including transitive dependencies) for the project. 
How can I get this?  I was using project.getArtifacts() to get all

dependencies, but this does not include the provided one (running the mojo
during compile phase).

Regards,

Gert

-
---
Gert Vanthienen
http://gertvanthienen.blogspot.com
  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven 2.1.0 not passing on system properties to java virtual machine

[Brian Fox]

Please file a jira for this and use 2.1.0 as the affects version so we 
can get it fixed in 2.1.1


edward eric pedersson wrote:

Hi

We use the command line to pass on system properties to the java
virtual machine when running our Hudson builds on a Linux box. It used
to work quite well in 2.0.9 by since we upgraded to 2.1.0 it has
stopped working altogether. The system properties just never make it
to the java virtual machine.

I have created a small test project and indeed it does not work at
all. I have attached it in case you want to give it a go. [it got
blocked so sending without attachment]

This should work just fine with maven 2.0.9

mvn2.0.9 -Dsystem.test.property=test test

But this will fail

mvn2.1 -Dsystem.test.property=test test

The java code simply does this

assertTrue( System.getProperty("system.test.property") != null);


Any thoughts

  


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: duplicate snapshots copied by maven-dependency-plugin:copy-dependency

[Brian Fox]

This could only happen in two passes of the plugin without a clean in 
between. The two files are indeed the same version, but it isn't 
checking the target folder exhaustively to see if there's a file there 
with another timestamped version...the overwrite only gets triggered if 
the exact same file already exists.


Reto Bachmann-Gmür wrote:

Hello

I'm copying dependencies with the following directive:


org.apache.maven.plugins
maven-dependency-plugin
2.1



copy-dependencies

copy-security-as-framework-bundles

true 
${basedir}/target/framework-bundles  
org.trialox.platform.security




In the created directory
target/framework-bundles/org/trialox/org.trialox.platform.security/0.2-SNAPSHOT/
 I have two files:
org.trialox.platform.security-0.2-20090416.175419-944.jar as well as
org.trialox.platform.security-0.2-SNAPSHOT.jar

I'd like to have only one version of the snapshot dependency and haven't
found out how to do this, using overwriteSnapshots and stripVersion had
no effect.

Cheers,
reto

-
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:copy and transitive dependencies of artifactItems

[Brian Fox]

It does not support transitivity yet. You can use copy-dependencies and 
combinations of the filters to get the artifacts you need


Chris Burroughs wrote:

I assumed from the frequent references to transitive dependencies at

that dependency:copy supported transitive dependencies of artifactItems.

However, this appears to not be the case (at least as of a few years ago):
http://www.mail-archive.com/users@maven.apache.org/msg55576.html
http://jira.codehaus.org/browse/MDEP-182

Can someone confirm that artifactItem still does not support transitive
dependencies?  If not, is there a standard workaround or alternative?

-
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: Converting to Maven 1.x

[Brian Fox]

Besides starting from scratch? No. Maven 1.x is dead for all intents and 
purposes.


Michael K. Craghead wrote:

It hasn't gone that far...So should I to assume from the responses that there 
is no good or easy way to convert to Maven 1?
 Michael K. Craghead 






From: David Hoffer 
To: Maven Users List 
Sent: Wednesday, April 22, 2009 1:40:42 PM
Subject: Re: Converting to Maven 1.x

And has the manger mandated all code shall be written in C?  Strange indeed.

-Dave

On Wed, Apr 22, 2009 at 11:37 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

  

Bash the manager over the head until he changes his mind

;-)

-Stephen

2009/4/22 Michael K. Craghead 



I know this seems like a strange request, but what is the best way to
convert a Maven 2 project to Maven 1? Our development team was going to
start to move to Maven 2, but the plans have changed. Unfortunately, I've
already built all of my code using Maven 2. I need to know how to convert
  

my


various projects to Maven 1. That includes changing the directory
  

structure


to leave out the "main" directory folder between the "src" and "java"
folders, as well as any other directory differences that I might not be
thinking of at the moment. Thanks.
  Michael K. Craghead
  


  

Re: org.apache.maven.plugins:maven-eclipse-plugin:2.7-SNAPSHOT ignores maven-compiler-plugin

[Brian Fox]

That's why we suggest locking down your plugin versions in your poms. 
Then you'll have controll over which ones you get as snapshots.

See here for more info:
http://www.sonatype.com/people/2008/04/maven-209-released/

The eclipse plugin does not seem to be one that has a default in the 
super pom.


On 4/23/2009 10:11 PM, Davis Ford wrote:

Hi, I just enabled all snapshots for plugins, and a side effect of
this was to pull down
org.apache.maven.plugins:maven-eclipse-plugin:2.7-SNAPSHOT version of
eclipse plugin.

Now, my project breaks in eclipse b/c it sets the JDK to be (I think)
the system default (which is JDK 1.5), but my maven-compiler-plugin
settings in the pom specify 1.6.  So maven compiles the sources, and
when I launch the project in eclipse, it throws an error saying the
class version is wrong.

Nothing very interesting in the config below.  This problem did not
exist for me until I just opened up plugin snapshots -- which I think
I'll turn off.  This is on:
$ mvn -version
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.6" arch: "x86_64" Family: "mac"




org.apache.maven.plugins
maven-eclipse-plugin

true

true




maven-compiler-plugin

1.6
1.6



   


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to share resources across projects in Maven

[Brian Fox]

I don't see anything obvious. Can you attach some build logs? The dep 
plugin is pretty verbose about what it's doing so it should hopefully be 
obvious.


On 4/23/2009 10:54 PM, Davis Ford wrote:

Hi Brian -- I'm trying to emulate your blog:
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/

for sharing resources across a multi-module project.  It is a grand
trick, but one that doesn't seem to be working for me.

I have the config project setup just fine.  It generates a .zip
archive.  I have done mvn install on it.

So, another project depends on it:



${project.groupId}
elibrary-config
${project.version}
resources
zip
provided


And I have set this up:





${basedir}/src/main/resources



${project.build.directory}/generated-resources
true




maven-dependency-plugin


unpack-config


unpack-dependencies


generate-resources


${project.build.directory}/generated-resources

${project.groupId}

elibrary-config

zip





If I run mvn package or mvn process-resources or mvn
process-test-resources, it never creates the  and
copies the files inside that zip there.  What am I missing?

Regards,
Davis

   


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: systemPath for directories not jars

[Brian Fox]

Not really, however Maven will do this automatically for projects in the 
same reactor if at least the compile phase is executed.


On 4/26/2009 2:18 PM, Lee Mighdoll wrote:

I'd like to specify a directory of .class files instead of a jar with
systemPath.  Is there any way to do this?

1) It would be convenient during development not to have to create a jar of
a closely related project
2) It might help work around a problem with the maven aspectj plugin, which
afaik will weave compiled classes only when they're specified as a
dependencies.

Lee

   


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: failed to resolve artifact for maven-install-plugin

[Brian Fox]

Check that you don't have a proxy blocking you.

On 4/26/2009 11:15 AM, pjotr wrote:

Hi,

I am not able to get maven-install-plugin (when executing 'mvn 
install' command)- getting the following error:


[INFO]task-segment: [install]
[INFO] 

Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

Downloading: 
http://download.java.net/maven/2//org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2/maven-install-plugin-2.2.pom 

[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

GroupId: org.apache.maven.plugins
ArtifactId: maven-install-plugin
Version: 2.2

Reason: Unable to download the artifact from any repository

org.apache.maven.plugins:maven-install-plugin:pom:2.2

from the specified remote repositories:
central (http://repo1.maven.org/maven2),
maven2-repository.dev.java.net (http://download.java.net/maven/2/)

I checked 
(http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.2) 
- required jar and pom is there. Any ideas how to solve it?


Regards
pjotr

-
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: Best practices for avoiding duplicate configuration files

[Brian Fox]

See the 9th bullet point here: 
http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/


On 4/26/2009 3:17 PM, Olivier Cailloux wrote:

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C depends 
on A and B. I use the same logging framework for the three projects 
(slf4j with logback). In A and B, I have a logback.xml configuration 
file in src/main/resources to configure logging behavior (A and B do 
not necessarily have the same configuration). C has also a specific 
logging configuration file. And, naturally, when I run the project C, 
logback complains that it found three logback.xml files in the 
classpath (the ones from A and B and C) when I would like it to find 
only the one from project C.


I am thus wondering how to avoid this duplication of configuration 
files (or avoid exposure of the A and B configuration files /for 
dependent projects/). (Naturally completely "excluding" logback.xml in 
A and B wouldn't solve my problem as it would also exclude the 
configuration file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with maven? 
I would ideally like the end-user to be easily able to modify the 
logging strategy, while providing him sensible defaults. Probably the 
logback.xml file should not be embedded in the .jar, but I don't know 
how to do that (and don't know if this is the best solution!)


Thank you for any pointer.
Olivier


-
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: Best practices for avoiding duplicate configuration files

[Brian Fox]

Olivier Cailloux wrote:

Thanks to everybody who answered. I answer to everyone together:
- Projects A and B are to be runnable independently and deployable 
without C. So putting the log config in test resources would not work.

- Putting the log files in a dependent module is possible. But:
 - it would render the pom and project management more complex. 
Currently these projects are not multi-modules, they are very simple,  
and that solution would involve transforming them to multi-module 
projects with one module being a whole module for only one stupid 
configuration file! And then having the project C exclude the right 
sub-module. But I admit that it is not my main concern (I could accept 
a complex solution if it was very good in other aspects) ;


That's right but generally this config file would not be part of the 
same tree that you build everytime. That is to say it has it's own 
lifecycle and is released far less often than the projects that use it.
 - it is not very elegant as any project depending on A or B would 
have to not forget to exclude the sub-module containing the log files 
(any dependent project would have the same problem a

s the project C has) ;
Not true because you don't have to mark it as a dependency. You can use 
dependency unpack (as opposed to unpack-dependencies) and this will not 
affect the dependency tree. Or you could use scope=provided / 
optional=true which means upstream dependencies would ignore it.
 - it does not solve the question of the log configuration file not 
being integrated in the jar for easily modification by the end-user 
after deployment ;
 - the problem I face is a general problem, as I always use log 
configuration files in my projects, so I would like to find a good 
solution once and for all.



You can unpack the zip file and leave them with just the log config file.
- The use of Assembly and Dependency plugins is maybe part of a 
solution, but I don't see clearly how I can configure all this to do 
what I would like and avoiding ending up with pom files more complex 
than needed.


To re-cap, I dream of a solution allowing me the following two 
possibilities, for any project I create:
- a possibility to create and expose (for use by dependent projects) a 
.jar file NOT containing the log configuration file ;
- a possibility to create and deploy (for end-user usage) a .zip file 
containing the above .jar AND the log configuration file, which is 
then easy for the end-user to modify ; and some start-up script 
(portable) or something equivalent to correctly configure the 
classpath to include the log configuration file and allow the end-user 
to easily start the application (this is the part I don't see how to 
do with the FAQ provided at 
http://www.sonatype.com/people/2008/04/how-to-share-resources-across-projects-in-maven/). 



This is also possible, just don't put the log file in /target/classes 
and it won't get jar'd up. You can then use the assembly plugin to zip 
up the final jar along with the config file unpacked earlier.


Although the solutions proposed did not fully satisfy my needs, I have 
to thank those who responded because it gave me good hints and allowed 
me to re-think about my problem. Any more advices would be very 
appreciated because I am a beginner in Maven and I think there must be 
somehow a simple solution to my needs which I simply overlooked. I am 
wondering how the others do as this must be a very common problem 
(everybody use logging framework!).


Also, sorry for my English...
Olivier

Brian Fox a écrit :
See the 9th bullet point here: 
http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/


On 4/26/2009 3:17 PM, Olivier Cailloux wrote:

Hello list,

I am new to maven and couldn't find a simple and elegant solution to 
this (probably) common problem.


I have three projects : A and B are independent projects and C 
depends on A and B. I use the same logging framework for the three 
projects (slf4j with logback). In A and B, I have a logback.xml 
configuration file in src/main/resources to configure logging 
behavior (A and B do not necessarily have the same configuration). C 
has also a specific logging configuration file. And, naturally, when 
I run the project C, logback complains that it found three 
logback.xml files in the classpath (the ones from A and B and C) 
when I would like it to find only the one from project C.


I am thus wondering how to avoid this duplication of configuration 
files (or avoid exposure of the A and B configuration files /for 
dependent projects/). (Naturally completely "excluding" logback.xml 
in A and B wouldn't solve my problem as it would also exclude the 
configuration file when running A or B themselves.)



More generally, is there some tutorial or best-practice about 
configuring logging for easy deployment and user-tweaking with 
maven? I would ideally like the end-user to be easily able t

Re: Apache snapshot repository metadata incorrect.

[BRIAN FOX]

Thanks for finding that. It's been fixed now.

The old repo had some junk versions that were being proxied. It's been  
cleaned out.


We schedule daily cleanups of the snapshots, leaving behind 3 copies  
for a minimum of 10 days, the snapshots are removed when a release is  
published.


Otherwise, we don't have it setup to actively recreate the metadata as  
under normal conditions it should be managed by maven, but in  
situations like this it's certainly handy to repair with a few clicks.


On May 1, 2009, at 12:09 PM, Nord, James wrote:


Hi all,

The metadata served by nexus for http://repository.apache.org/snapshots/
is incorrect for the archetype plugin.

(https://repository.apache.org/content/groups/snapshots/org/apache/maven
/plugins/maven-archetype-plugin/)

metadata contains lots of snapshot versions but only
2.0-alpha-5-SNAPSHOT is available.  (and hence running mvn
archetype:generate from the command line fails as it tries to get
12-SNAPSHOT

/James

 
-
  http://maven.apache.org/METADATA/1.0.0
http://maven.apache.org/xsd/metadata-1.0.0.xsd";
xmlns="http://maven.apache.org/METADATA/1.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
 org.apache.maven.plugins
 maven-archetype-plugin
 2.0-alpha-4-SNAPSHOT
-
  
 12-SNAPSHOT
 
-
  
 2.0-alpha-4-SNAPSHOT
 2.0-alpha-5-SNAPSHOT
 0.3.0-SNAPSHOT
 1.0-SNAPSHOT
 1.0-alpha-2-SNAPSHOT
 1.0-alpha-3-SNAPSHOT
 1.0-beta-3-SNAPSHOT
 1.0.2-SNAPSHOT
 1.1-SNAPSHOT
 1.1.1-SNAPSHOT
 1.2-SNAPSHOT
 1.2.2-SNAPSHOT
 1.3-SNAPSHOT
 2.0-beta-9-SNAPSHOT
 2.0-beta-10-SNAPSHOT
 2.0.11-SNAPSHOT
 2.1.0-SNAPSHOT
 2.1-SNAPSHOT
 2.1.0-M2-SNAPSHOT
 2.2-SNAPSHOT
 2.3-SNAPSHOT
 2.4.4-SNAPSHOT
 2.5-SNAPSHOT
 3.0-alpha-2-SNAPSHOT
 11-SNAPSHOT
 12-SNAPSHOT
 
 20090417213533
 
 

**
This e-mail is confidential, the property of NDS Ltd and intended  
for the addressee only. Any dissemination, copying or distribution  
of this message or any attachments by anyone other than the intended  
recipient is strictly prohibited. If you have received this message  
in error, please immediately notify the postmas...@nds.com and  
destroy the original message. Messages sent to and from NDS may be  
monitored. NDS cannot guarantee any message delivery method is  
secure or error-free. Information could be intercepted, corrupted,  
lost, destroyed, arrive late or incomplete, or contain viruses. We  
do not accept responsibility for any errors or omissions in this  
message and/or attachment that arise as a result of transmission.  
You should carry out your own virus checks before opening any  
attachment. Any views or opinions presented are solely those of the  
author and do not necessarily represent those of NDS.


To protect the environment please do not print this e-mail unless  
necessary.


NDS Limited Registered Office: One London Road, Staines, Middlesex,  
TW18 4EX, United Kingdom. A company registered in England and Wales  
Registered no. 3080780 VAT no. GB 603 8808 40-00

**



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven password encryption and usage in a CI server

[Brian Fox]

You are correct. If someone is able to read the maven code and find the 
default password, decrypt the master password, then they could decrypt 
the user password. It's also decrypted "on the wire" if you aren't using 
https with your repos. The trick with a build server is to make a 
special account for that system, the real danger comes when you use a 
corporate password and someone gets that.


If you have real concerns about the build server, don't give people 
permissions to change the jobs and then it will be harder for them to 
get at these files.


Olivier Dehon wrote:

Hi,

I was reading about the recent enhancements to the management of server
passwords in settings.xml at
http://maven.apache.org/guides/mini/guide-encryption.html

A few questions arose around the actual security provided by these
enhancements in the context of a build/CI server.

Agreed, this is an enhancement over passwords in clear text in
settings.xml, where any developer can run the help:effective-settings
goal in a custom build definition to gain access to the passwords
configured there on the server.

But can it be considered a safe protection in the context of a build
server? For instance, what prevents a developer from running a build
definition that runs a command through the exec or antrun plugin that
outputs the content of the settings-security.xml, thereby compromising
the encryption?

Unless I miss the obvious (or the less obvious) I am under the
impression that this enhancement makes it harder to get to the
passwords, but does not make it impossible (and maybe this was never the
goal).

Thank you in advance for your insights/pointers.

-Olivier


-
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: [PLEASE TEST] Maven 2.2.0-RC2

[Brian Fox]

Check what command the release plugin is invoking during the perform goal.
It's checking out the code to target/checkout and then forks another maven
execution in that folder. This is the one that's failing for you.

On Wed, May 6, 2009 at 3:18 AM, Mark Derricutt  wrote:

> Looks good with  projects that had issues with profiles under 2.1.0  (sub
> projects not resolving profiles problem when built from the master).
> Mark
>
> --
> Discouragement is a dissatisfaction with the past, a distaste for the
> present, and a distrust of the future - Maree De Jong, Life NZ.
> http://www.talios.com
>
> Sent from Auckland, New Zealand
>
> On Tue, May 5, 2009 at 12:02 PM, John Casey 
> wrote:
>
> > Hi again,
> >
> > After finding and cleaning up some code that seems to be tainted during
> > some of our efforts at generifying the codebase, we've respun a new
> release
> > candidate.
> >
> > If you have time, please give it a whirl:
> >
> >
> >
> https://repository.apache.org/content/repositories/maven-staging-010/org/apache/maven/apache-maven/2.2.0-RC2/
> >
> > Remember, if you have any problems, report them to:
> > http://jira.codehaus.org/browse/MNG with Affects-Version: 2.2.0
> >
> > ...then, please reply to this thread to let me know about the issue! :-)
> >
> > Thanks for testing!
> >
> > -john
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Dependency version precedence

[Brian Fox]

It will resolve the conflicts, but here no conflict exists from Maven's
point of view. The groupid is part of the coordinates so they appear to be
the same. Jdom should insert a "relocation" pom to solve these issues. Your
recourse is to use an exclusion.
Assuming the group was the same, you would get 1.1. And lets further assume
you didn't directly depend on 1.1 but had some other dependency foo, that
did. Which ever brought in jdom first in your pom would be the version you
end up with. In otherwords, if the depth is the same for a dependency, the
first one seen wins.

2009/5/7 Niels van Kampenhout 

> On Thu, May 7, 2009 at 1:10 PM, Ylan Segal  wrote:
> > I have a conflict with a jdom dependency: Two versions are appearing in
> my
> > classpath.
> >
> > The problem arises because my project uses the follwing two dependencies:
> >
> >
> > 
> >jdom
> >jdom
> >1.1
> > 
> > 
> >rome
> >rome
> >0.9
> > 
> >
> >
> > Now, rome in turn uses:
> >
> > 
> >jdom
> >jdom
> >1.0
> > 
> >
> > According to my (limited) understanding of maven, since I am explicitly
> > stating that my project uses jdom 1.1, that should take precedence and
> jdom
> > 1.0 should not be included.
> >
> > Now, when I check the dependency tree I see that:
> >
> > com.mydomain:myproject-1.0-SNAPSHOT
> >+ org.jdom:jdom:jar:1.0 (compile)
> >+ rome:rome:jar:0.9 (compile
> >+ jdom:jdom:jar:1.0 (compile)
> >
> > Notice that groupID for the two jdom versions are different. It's jdom
> for
> > 1.0 but org.jdom for 1.1. I believe that this is why maven is actually
> using
> > both dependencies: It doesn't know that they are different versions of
> the
> > same artifact.
> >
> > (By the way I tried setting my dependecy's groupId to org.jdom or jdom
> and I
> > get the same result: Somehow even if I specify jdom as the groupId it
> > resolves to org.jdom).
> >
> > Does anyone have any suggestions on how to address this?
>
> You can exclude the rome's transitive jdom dependency like this (from
> the top of my head):
>
> 
>rome
>rome
>0.9
> 
>
> jdom
>jdom
> 
>
> 
>
> As far as I know Maven does not automatically resolve version
> conflicts between (transitive) dependencies, you just end up with both
> versions of the jar.
>
> HTH,
>
> Niels
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Access to the class path

[Brian Fox]

take a look at dependency:build-classpath

On Thu, May 7, 2009 at 3:11 AM, James Crawford wrote:

> Hi,
>
> I need to be able to get access to the runtime class path
> in my tests when invoked from the maven-surefire-plugin.
>
> I can set system properties for the surefire plugin but I
> can't find anyway that I can get access to the class path.
>
> For example I want to do something like the following to
> set some "runtime.classpath" system property (assuming maven
> provided a "maven.runtime.classpath" property):
>
>  
>maven-surefire-plugin
>
>  always
>  
>
>  runtime.classpath
>  ${maven.runtime.classpath}
>
>  
>
>
>  ...
>
>  
>
> I can see that when running ant tasks the antrun plugin
> provides access to this type of information but I can't
> find anywhere where it is possible to get access to this
> information in a general way within Maven without writing
> my own plugin.
>
> Can anyone tell me whether it is possible to do what I
> want?
>
> Thanks,
> James.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: hi, how to specify java_opts in maven

[Brian Fox]

set MAVEN_OPTS = -Xmx512m for example. It can't be done directly from the
cli.

On Thu, May 7, 2009 at 1:39 AM, shrimpywu  wrote:

>
> Before i run my program like this
>
> 
>org.codehaus.mojo
>exec-maven-plugin
>
>
>
>exec
>
>
>
><
>
>java
>
>-Xms32m
>-Xmx1024m
>-classpath
>
>org.myproject.Main
>
>
>
>
>
> however i have to pass arguments in run time,
> so i have to do things like this
>  mvn exec:java -Dexec.mainClass="org.myproject.Main"
> -Dexec.args="argument1"
>
> but i found out that, if i do in comand line, i can specify any argument in
> the POM any more,
> coz it will complain and throws exception.
> but i do want to increase the java heap size, otherwise i will get "Out of
> memory" exception
>
> So...can any one help me how can i do both???
> --
> View this message in context:
> http://www.nabble.com/hi%2C-how-to-specify-java_opts-in-maven-tp23420573p23420573.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: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism

[Brian Fox]

I think this will help you understand it better:
Think of inheritance as including the contents of the parents inside your
own pom. (obviously merging occurs). I used to be a C programmer so I refer
to this as #include-ing the contents.

Therefore the result of inheritance is that it updates your local pom.
Things declared in your local pom always superceede transitive, thus the
behavior seems to be correct.

So to restate the problem, you are using in one module a jar LIB that you
only need in your tests, but transitively you depend on something which
needs LIB at runtime and thus it should be packed into your war? If so, just
flip your dependency to a compile scope since this is also included in test
classpaths. This is generally an unusual scenario, I don't think it's solved
yet with Mercury.

My suggestion is to provide a sample project as an IT and write up an issue
for this.

On Wed, May 6, 2009 at 5:29 AM, Stevo Slavić  wrote:

> Hello Maven users,
>
> If a parent module (e.g. P) of a multi module project defines a test scope
> dependency to some library (e.g. library "LIB"), and if one of projects's
> child modules which inherit P (e.g. jar module A) defines compile scope
> dependency to the same (LIB) library, and if some other child module which
> also inherits P (e.g. war module B) defines compile scope dependency on
> module A, then (at least when using maven 2.1.0) library LIB does not get
> included in war of module B. It seems that scope (in this example test
> scope) of inherited dependency wins over scope (in this example compile
> scope) of transitive dependency.
>
> This looks like a bug to me (maybe just in maven-war-plugin:2.1-beta-1, or
> maven-dependency-plugin:2.1) - even though module B (through inheritance)
> defines LIB as test scope dependency but on the other hand it's dependency
> defines same LIB as compile scope dependency so LIB should be included in
> module B war. Currently a workaround is to explicitly define compile time
> dependency to LIB in module B, even though it doesn't make direct use of the
> LIB. As subject states, maybe I've misunderstood the dependency resolution
> mechanism.
>
> Attached is example project which demonstrates the issue.
>
> Regards,
> Stevo.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: deploy:deploy Hangs in Release

[Brian Fox]

I wonder if it's waiting for some password input. Make sure you have a
server setting with the proper credentials for scp.

On Tue, May 5, 2009 at 6:33 PM, Harper, Brad  wrote:

> While performing a deployment from the release plugin, I see
>
>
>
> [INFO] [INFO] [install:install]
>
> [INFO] [INFO] Installing C:\eclipse-workspaces\...\x.war to
> C:\...\.m2\repository\com\...\x.war
>
> [INFO] [INFO] Installing C:\eclipse-workspaces\...\x-sources.jar to
> C:\...\.m2\repository\com\x-sources.jar
>
> [INFO] [INFO] Installing C:\eclipse-workspaces\...\x.zip to C:\...\x.zip
>
> [INFO] [INFO] [deploy:deploy]
>
>
>
> And that's it. Re-running with -X gives
>
>
>
> . . .
>
> [INFO] [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-deploy-plugin:2.4:deploy' -->
>
> [INFO] [DEBUG]   (f) artifact = x:war:1.0.4
>
> [INFO] [DEBUG]   (f) attachedArtifacts =
> [com.y:x:java-source:sources:1.0.4, com.y:x:zip:1.0.4]
>
> [INFO] [DEBUG]   (f) deploymentRepository =
> Repository[internal|scp://dev-deploy/web-dev-repos/releases]
>
> [INFO] [DEBUG]   (s) localRepository =
> Repository[local|file://C:\...\.m2\repository]
>
> [INFO] [DEBUG]   (f) packaging = war
>
> [INFO] [DEBUG]   (f) pomFile =
> C:\eclipse-workspaces\...\x\target\checkout\pom.xml
>
> [INFO] [DEBUG]   (f) skip = false
>
> [INFO] [DEBUG]   (f) updateReleaseInfo = true
>
> [INFO] [DEBUG] -- end configuration --
>
> [INFO] [INFO] [deploy:deploy]
>
> [INFO] [DEBUG] not adding permissions to wagon connection
>
>
>
> I've recently moved from maven 2.0.8 to 2.1.0 with a completely
>
> new local [.m2] repo.
>
>
>
> Any thoughts? Is the "not adding permissions" message a clue? Thanks.
>
>
>
> Brad
>
>
>
>

Re: Managing Modified Dependencies

[Brian Fox]

I covered some strategies in this area here[1] and there are some other
how-tos here[2]

[1]
http://www.sonatype.com/people/2009/01/best-practices-for-releasing-with-3rd-party-snapshot-dependencies/
[2] http://www.sonatype.com/people/2009/04/summary-of-maven-how-tos/

On Mon, May 4, 2009 at 12:10 PM, daniel.green  wrote:

>
> The situation:
>
> * Company finds a show stopping bug in dependency Foo
> * Company can not wait for the owner of Foo to fix it
> * Company branches the source code locally and applies patch
> * Company now needs to maintained a modified third party dependency
>
> Currently some crazy system of relative paths and fake version numbers is
> being used to resolve the modified dependencies. However, this is obviously
> an eye soar sore and is cluttering up our source repository. What are some
> solutions for ensuring that changes don't get overwritten and our
> repository
> stays clean?
>
> Any suggestion will be welcomed!
>
> I appreciate your time, thank you at least for that :-),
> Daniel.
>
> --
> View this message in context:
> http://www.nabble.com/Managing-Modified-Dependencies-tp23371539p23371539.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: Access to the class path

[Brian Fox]

Yeah, someone else was looking for this too. If you supply a patch, i'll
integrate it.

On Thu, May 7, 2009 at 8:28 PM, Manos Batsis wrote:

> James Crawford wrote:
>
>> I did look at dependency:build-classpath but I could only
>> see how it outputs the class path to a file.
>>
>>
>
> Probably not the best idea as I've been up straight wy too long, but it
> should take you 15 minutes to change the source so that an env property is
> stored.
>
> Manos
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Access to the class path

[Brian Fox]

No, that would be a bug.

On Thu, May 7, 2009 at 9:01 PM, James Crawford wrote:

> On Thu, 2009-05-07 at 20:34 -0400, Brian Fox wrote:
> > Yeah, someone else was looking for this too. If you supply a patch, i'll
> > integrate it.
>
> We are currently on Maven 2.0.4 so I can't even build the latest
> source.
>
> If I get time I will produce a patch when we finally upgrade to
> a more recent version of aven.
>
> > On Thu, May 7, 2009 at 8:28 PM, Manos Batsis  >wrote:
> >
> > > James Crawford wrote:
> > >
> > >> I did look at dependency:build-classpath but I could only
> > >> see how it outputs the class path to a file.
>
> One thing I noticed is that the classpath seems to be sorted
> alphabetically when using the dependency:build-classpath goal
> and thus differs from the project.getClasspathElements() call
> which is what I would have expected the results to look like.
>
> Is there a reason for this?
>
> Cheers,
> James.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: include jars from a folder

[Brian Fox]

You're shoving a square peg into a round hole by doing this. You won't get
much, if any of the benefits of Maven without using a repository.

On Wed, May 6, 2009 at 4:00 PM, tubin gen  wrote:

> I have some of the jar files modified and kept them under folder ext-lib,
> there jars files are needed  by my application, can I tell maven to include
> jars from this folder   into the war file ?
> my pom right now uses scope system and systempath , I donot  want to
> install
> them becasue we don't have   common repository manager and every user
> working with the project must install these jar files into there local
> repository
>

Re: hi, how to specify java_opts in maven

[Brian Fox]

I said below to set MAVEN_OPTS in your environment ;-)

On Fri, May 8, 2009 at 1:46 AM, shrimpywu  wrote:

>
> so what should i do???
>
>
>
> BRIAN FOX-5 wrote:
> >
> > set MAVEN_OPTS = -Xmx512m for example. It can't be done directly from the
> > cli.
> >
> > On Thu, May 7, 2009 at 1:39 AM, shrimpywu  wrote:
> >
> >>
> >> Before i run my program like this
> >>
> >> 
> >>org.codehaus.mojo
> >>exec-maven-plugin
> >>
> >>
> >>
> >>exec
> >>
> >>
> >>
> >><
> >>
> >>java
> >>
> >>-Xms32m
> >>-Xmx1024m
> >>-classpath
> >>
> >>org.myproject.Main
> >>
> >>
> >>
> >>
> >>
> >> however i have to pass arguments in run time,
> >> so i have to do things like this
> >>  mvn exec:java -Dexec.mainClass="org.myproject.Main"
> >> -Dexec.args="argument1"
> >>
> >> but i found out that, if i do in comand line, i can specify any argument
> >> in
> >> the POM any more,
> >> coz it will complain and throws exception.
> >> but i do want to increase the java heap size, otherwise i will get "Out
> >> of
> >> memory" exception
> >>
> >> So...can any one help me how can i do both???
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/hi%2C-how-to-specify-java_opts-in-maven-tp23420573p23420573.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
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/hi%2C-how-to-specify-java_opts-in-maven-tp23420573p23440459.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: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism

[Brian Fox]

2009/5/8 Todd Thiessen 

> Your argument Jorg I think applies to provided and runtime scope, but not
> to test.
>
> The root smell here lies in the definition of "scope".  Test scope means
> needed to compile test code. Compile scope means needed to compile
> production and test code.  These are both related to when a dependency is
> needed to compile.
>
> Provided and runtime scope are related to when a dependency is needed at
> runtime.
>
> So the way I see it, a compile transitive dependency should always override
> a test dependency but not provided or runtime.
>

What do you mean by override?


>
> There is some technical debt here in terms of how scoping works. You really
> need a further scope classification like:
>
> Scope = compile
>   classifier = test
>   classifier = production
>
> Scope = runtime
>   classifier = provided
>
> Something like this. You likely get the idea.
>

Lost me

Re: General questions regarding dependencies

[Brian Fox]

You can't have a pile of files as dependencies, not the way I think you're
looking at it. You want to zip them up as a single artifact and then use
those as the dependency. You can use the dependency:unpack /
unpack-dependencies goal to extract the files from the artifact prior to
compilation.

For documentation, take a look at the links below.
http://www.sonatype.com/products/maven/documentation/book-defguide
http://www.sonatype.com/products/nexus/documentation/book

On Fri, May 8, 2009 at 10:01 AM, Doug Hughes  wrote:

> So, I'm getting the impression that the dependencys need to be a single
> file
> such as a jar, zip, or something else.  I can't have a folder of files as
> my
> dependency?  This is fine, it seems that dependency  or assembly plugin can
> be used to explode this as needed.
>
> Where can I find documentation on creating my own repository and using it
> with Maven?
>
> Thanks,
>
> Doug Hughes, President
> Alagad Inc.
> dhug...@alagad.com
> 888 Alagad4 (x300)
> Office: 919-550-0755
> Fax: 888-248-7836
>
>
> On Fri, May 8, 2009 at 9:28 AM, Graham Leggett  wrote:
>
> > Doug Hughes wrote:
> >
> > > I have some questions about how dependencies are handled within Maven.
>  I
> > > understand that when you add a dependency that Maven looks at the
> central
> > > repository, finds the correct files and downloads them.  I'm wondering
> if
> > > this can only be done for JAR/WAR files?
> >
> > No, any artifact from your build can be deployed into a maven
> > repository. The maven-rpm-plugin for example creates an RPM file as an
> > artifact, and the maven deploy step will deploy the RPM into a
> > repository, it doesn't have to be a jar or a war (or an ear, or
> whatever).
> >
> > > My question then is, is it possible to somehow define a dependency
> which
> > is
> > > a collection of files?
> >
> > Yes, group the files together into some kind of archive (zip is good, or
> > jar seeing we are in the java universe), and then deploy that.
> >
> > > Also, if I did somehow define that dependency, is
> > > there a way to make sure that the dependency is coppied to a specific
> > > directory within he webapp?
> >
> > Yes.
> >
> > The maven-dependency-plugin can be asked to unpack directories and put
> > them in certain places during your build.
> >
> > Alternatively, for more general purpose stuff, the maven-assembly-plugin
> > can be used to produce an "assembly" of multiple things combined into a
> > single tree.
> >
> > Regards,
> > Graham
> > --
> >
>

Re: Child POM inherit reporting configurtaion from parent POM?

[Brian Fox]

The merging inside the configuration doesn't add the things together because
it isn't known ahead of time if replacement or merging makes sense for a
given plugin.

On Fri, May 8, 2009 at 9:33 AM, REMIJAN, MICHAEL J [AG/1000] <
michael.j.remi...@monsanto.com> wrote:

> I have javadoc reporting configuration in a PARENT POM an it looks like
> this:
>
> 
>
>
>org.apache.maven.plugins
>maven-javadoc-plugin
>true
>
>   
>
> http://java.sun.com/j2se/1.5.0/docs/api
>
> http://jakarta.apache.org/commons/chain/apidocs
>   
>
>
>
>  
>
>
> Now for a CHILD POM I want to add a new  for a library which the
> CHILD project uses.  So I have this in the CHILD POM
>
> 
>
>
>org.apache.maven.plugins
>maven-javadoc-plugin
>
>   
>http://flickrj.sourceforge.net/api/
>   
>
>
>
>  
>
> My problem is Maven isn't combining the two.  I expected
> help:effective-pom to have 3  tags but it only shows the one from
> the CHILD POM.  So the CHILD POM configuration is overriding the PARENT
> POM.  Is there a way to get Maven to combine the two?
>
> Mike
>
>
> -
> This e-mail message may contain privileged and/or confidential information,
> and is intended to be received only by persons entitled to receive such
> information. If you have received this e-mail in error, please notify the
> sender immediately. Please delete it and all attachments from any servers,
> hard drives or any other media. Other use of this e-mail by you is strictly
> prohibited.
>
>
> All e-mails and attachments sent and received are subject to monitoring,
> reading and archival by Monsanto, including its subsidiaries. The recipient
> of this e-mail is solely responsible for checking for the presence of
> "Viruses" or other "Malware". Monsanto, along with its subsidiaries, accepts
> no liability for any damage caused by any such code transmitted by or
> accompanying this e-mail or any attachment.
>
> -
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Undocumented Feature: Usage of negation for profile activation

[Brian Fox]

They get better with patches ;-)

On Fri, May 8, 2009 at 5:57 PM, Martin Gainty  wrote:

>
> fantastic..what are the chances of opening the capability to use regular
> expresssions?
>
> thanks,
> Martin Gainty
> __
> Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note
> de déni et de confidentialité
> This message is confidential. If you should not be the intended receiver,
> then we ask politely to report. Each unauthorized forwarding or
> manufacturing of a copy is inadmissible. This message serves only for the
> exchange of information and has no legal binding effect. Due to the easy
> manipulation of emails we cannot take responsibility over the the contents.
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
>
>
> > From: wsm...@gmail.com
> > Date: Fri, 8 May 2009 14:39:33 -0700
> > Subject: Re: Undocumented Feature: Usage of negation for profile
> activation
> > To: users@maven.apache.org
> >
> > On Fri, May 8, 2009 at 6:59 AM, TM  wrote:
> > >
> > > Hello,
> > >
> > > I just found a---to my best knowledge---undocumented feature and though
> I
> > > should share it with the community in the hope that it will made its
> way
> > > into the Maven documentation.
> > >
> > > The feature is that you can use the negation symbol "!" within a
> profile
> > > activation specifification not only to test the absence of a property
> but
> > > also within the  tag, for instance, to express something like
> "activate
> > > the profile if the OS family name is _not_ xyz". The following example
> > > illustrates this:
> >
> > It could go on
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> > .
> >
> > Can you open a JIRA issue if there isn't one, and possibly suggest a
> patch?
> >
> > --
> > Wendy
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> _
> Windows Live™: Keep your life in sync.
> http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009

Re: Re: Transitive and inherited dependencies - potential bug, or my misunderstanding of the mechanism

[Brian Fox]

On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen  wrote:

> Override the dependency defined in the POM, as Steve outline in his
> earlier response. Let me quote his explanation for ease of reference:
>
> "E.g. if project P has test scoped dependency to a LIB1, and compile
> scoped dependency to LIB2, while LIB2 has compile scope dependency to
> LIB1, currently project P's war will wrongly end up without LIB1
> included. In P one expects LIB1 to be available for testing, but that
> shouldn't affect availability of LIB1 as compile scoped transitive
> dependency, it should be the other way round, in this case scope of
> declared test scoped dependency should be broadened."
>
> I used the term "override" to descibe the situation when project P
> should have LIB1 defined as a compile dependency, when the POM actually
> defines it as test. But it should should only override for test
> dependencies, not for provided or runtime.
>

The local pom always wins. Placing additional semantics on how things merge
is troublesome. I'm sure we can think of scenarios where widening is not the
right thing to do. In either case you must have the ability to resolve this
yourself if it doesn't do the right thing...and the way to do that is to put
what you want in the local pom.


>
> As for your "lost me" comment I am not sure what you would like
> explained. Scope basically has multiple meanings.  Compile/test are both
> related to requiring a dependency for compilation; runtime/provided are
> both related to requiring a dependency only at runtime. These multiple
> meanings are not suited to a single variable.
>

Are there many cases where you want something for compilation that isn't
needed at runtime? I don't see them as being separate.


>
> ---
> Todd Thiessen
>
>