You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@maven.apache.org by John Casey <jd...@apache.org> on 2009/03/22 03:13:21 UTC

[ANN] Maven 2.1.0 Released

The Maven team is pleased to announce the release of Maven 2.1.0.

Maven is a software project management and comprehension tool. Based on 
the concept of a project object model (POM), Maven can manage a 
project's build, reporting and documentation from a central piece of 
information.

You can download the new version at:

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

You can find release notes for this version below, or at:

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

Enjoy,

-The Maven team

---

Release Notes - Maven 2.1.0

** Sub-task
     * [MNG-4025] - Prominently document opt-out setting for parallel 
artifact resolution for users
     * [MNG-4042] - Use plexus-sec-dispatcher 1.0 in Maven core when it 
is released

** Bug
     * [MNG-1349] - openssl checksums are not accepted by maven
     * [MNG-1585] - debug logging from wagon not shown in debug mode
     * [MNG-1992] - CLI -D should override properties in settings.xml
     * [MNG-1999] - Reporting inheritance does not work properly
     * [MNG-2432] - Apache and Mojo plugins take precendence over 
plugins in the pom.
     * [MNG-2433] - Maven looks for snapshots in offline mode
     * [MNG-2605] - Profiles in profiles.xml are active by default
     * [MNG-2668] - Plugin dependencies should be considered when the 
reactor creates the build order list
     * [MNG-2690] - DefaultPluginManager.getConfiguredMojo() doesn't 
handle NoClassDefFoundError correctly
     * [MNG-2695] - -o makes build fail for snapshot plugins
     * [MNG-2720] - Multiproject dependencies not accurate for 
project.compileClasspathElements when run from root project
     * [MNG-3023] - Reactor projects should be included in dependency 
resolution
     * [MNG-3057] - properties not expanded in generated POMs when 
building A/B/C nested projects
     * [MNG-3139] - The skin does not exist: Unable to determine the 
release version
     * [MNG-3217] - a plugin's dependencies can influence other plugins 
in a build
     * [MNG-3228] - Maven profile activation does not work when profile 
is defined in inherited 'parent' pom
     * [MNG-3271] - <excludeDefaults> does not seem to work
     * [MNG-3284] - Cached plugins are used, even when the specifically 
declared
     * [MNG-3314] - offline build not running, when having SNAPSHOT 
dependencies
     * [MNG-3621] - site url inheritance broken for UNC paths
     * [MNG-3628] - When running offline, snapshot artifcats cannot be 
resolved even if they have previously be dowloaded from a repository
     * [MNG-3641] - Lack of error checks on profiles
     * [MNG-3645] - Maven doesn't do strict model validation for POMs in 
the current reactor
     * [MNG-3719] - [regression] plugin execution ordering no longer POM 
ordered in 2.0.9
     * [MNG-3757] - Setting M2_HOME to nothing and running ant delets 
contents of the current folder
     * [MNG-3769] - [regression] Excluding relocated transitive 
dependencies does not work
     * [MNG-3776] - Namespace misspelled in settings.xml
     * [MNG-3808] - Execution order of report plugins is arbitrary if 
inheritance is involved
     * [MNG-3810] - [regression] Null Pointer Exception when Activation 
Profile Property is Empty
     * [MNG-3811] - Report plugins don't inherit configuration
     * [MNG-3899] - Inheritance does not merge extensions with same gid 
and aid
     * [MNG-3906] - Project-level plugin dependencies are in random 
order after merging
     * [MNG-3920] - Problem using velocity component
     * [MNG-3930] - mvn.bat doesn't handle ampersand in Windows user 
name properly
     * [MNG-3933] - Profiles.xml does not pickup OS family
     * [MNG-3940] - Interpolation of environment variables is not 
case-insensitive on Windows
     * [MNG-3948] - Remote repos defined by profiles outside of 
settings.xml are not used to resolve parent POMs
     * [MNG-3974] - New mirror syntax is not stopping on first match
     * [MNG-4016] - Properties with the prefix project/pom are not 
interpolated from the properties section
     * [MNG-4023] - Profiles from parent POM are injected multiple times 
if parent is part of reactor build
     * [MNG-4026] - [regression] Order of project class path does not 
match POM order during reactor build
     * [MNG-4032] - Test jar dependency not available for for main 
classes in multi module builds
     * [MNG-4043] - Resolve or rollback WebDAV wagon deployment issue 
where hostname is improperly extracted from URL
     * [MNG-4074] - cyclic reference with 2.1.0-RC1 that doesn't occur 
with 2.0.10
     * [MNG-4079] - Duplicate error messages
     * [MNG-4084] - Unnecessary Warning for an activate profile in child 
project
     * [MNG-4086] - [regression] Explicitly using plugin metaversions 
crashes plugin manager
     * [MNG-4087] - Percent encoded characters in file URLs are not 
decoded upon deployment

** Improvement
     * [MNG-1830] - add  a 'compiled on <timestamp>' label when maven 2 
is invoked with --version option
     * [MNG-1957] - <jdk></jdk> clause in the activation section has to 
provide more complex expressions.
     * [MNG-3424] - Respect ordering of elements as given in POM
     * [MNG-3451] - Add german translation
     * [MNG-3503] - Shade MX* classes from plexus-utils
     * [MNG-3544] - Beautify debug output for mojo parameters of type array
     * [MNG-3600] - remove default settings of 664 / 775 for permissions
     * [MNG-3787] - Add plugin version to default reports
     * [MNG-3794] - Improve error logging when downloading depedencies
     * [MNG-3795] - Add example <pluginGroups> snippet to 
conf/settings.xml in distribution
     * [MNG-3867] - Support MAVEN_OPTS in mvnDebug script
     * [MNG-3951] - Hide drive-relative paths from plugins
     * [MNG-3971] - Provide parity in features between native ant-mojo 
support and antrun plugin
     * [MNG-3975] - getArtifact(Artifact artifact, List 
remoteRepositories) should include Exception in debug log messages.
     * [MNG-4024] - Open up CLIManager
     * [MNG-4037] - Include Java home in version information
     * [MNG-4057] - Propose checking of plugin artifact when plugin 
descriptor cannot be found
     * [MNG-4075] - Tone down warnings about reactor dependencies that 
don't have an associated file
     * [MNG-4091] - Validate the plugin descriptors and improve error 
reporting when mismatched with artifact
     * [MNG-4092] - remove plugin listeners for minor memory improvement 
and to avoid scanning descriptors from dependencies of plugins

** New Feature
     * [MNG-553] - Secure Storage of Server Passwords
     * [MNG-2097] - adding a phase called prepare-package
     * [MNG-3379] - Parallel resolution of artifacts
     * [MNG-3760] - Support property ${baseurl} to get RFC-compliant URL 
of project base directory
     * [MNG-3914] - Add CLI option to control location of global 
settings from command line

** Task
     * [MNG-2387] - <active> on <proxy> in settings is misleading
     * [MNG-2883] - Make sure that the network isn't used for snapshots 
in offline mode when legacy repositories are used
     * [MNG-3602] - Schedule and release Doxia-1.1
     * [MNG-3842] - Revert temporary changes to scp wagon handling
     * [MNG-3936] - Remove m2.bat from distribution
     * [MNG-4030] - Release maven-plugin-tools 2.4.4/2.5 to enable 
enhanced ant-mojo support
     * [MNG-4031] -  Release plexus-ant-factory 1.0-alpha-2.1 to enable 
enhanced ant-mojo support
     * [MNG-4046] - Update to Doxia 1.0
     * [MNG-4077] - Review log level for 
VersionExpressionTransformation.transformVersions()


** Wish
     * [MNG-4056] - Relax resolution of active project artifacts from 
the reactor with regard to artifact type


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

RE: [ANN] Maven 2.1.0 Released

Posted by "Brian E. Fox" <br...@reply.infinity.nu>.

The @phase will automatically cause a plugin to run at that phase, but
the plugin must still be mentioned in the pom. 

-----Original Message-----
From: Pankaj Tandon [mailto:pankajtandon@gmail.com] 
Sent: Thursday, April 02, 2009 10:40 AM
To: users@maven.apache.org
Subject: Re: [ANN] Maven 2.1.0 Released

Hello Rob,
I wanted to ask you about your comment below where you state that even
if you have an annotation in a mojo for the execution phase, you still
have to declare an executions element for the very same phase in the
project that invkes this plugin.

That, kind of defeats the purpose of having a default phase specified in
the Mojo, does it not? And it certainly doesn't work that way for other
plugins (the war plugin for instance that is bound to the package
phase).

So am I missing something here or is this a bug introduced with 2.0.10?

Thanks
Pankaj

Okay, my mistake - although it was indeed the 2.1.0 mvn which was in my
path, I had forgotten to change the value of my M2_HOME environment
variable.

Therefore, it was actually 2.0.10 which was being executed, which was
why my
goal was being ignored.

And anyway, I had wrongly assumed that adding the '@phase
prepare-package'
annotation to the mojo was enough to trigger the goal's execution - you
still have to add a <plugin><executions>...<goal> to the pom, and I can
confirm that this works fine.

Many thanks to Brett for asistance.

Rob

2009/3/25 Rob Dickens <ar...@googlemail.com>

> As in a <plugins><plugin><executions><execution> block in the pom.xml
of
> the jar-packaged project?
>
> There isn't one, since the plugin's mojo has a '@phase
prepare-package'.
>
> 2009/3/25 Brett Porter <br...@apache.org>
>
>
>>
>> On 25/03/2009, at 10:07 PM, Rob Dickens wrote:
>>
>>  Do jar-packaged projects now execute the new prepare-package phase?
>>>
>>> Have just tried the new version out, hoping that my project with jar
>>> packaging would execute the new phase, to which one of my plug-in
goals
>>> declares itself as being bound, but it appears not to.
>>>
>>
>> All packaging types will if you properly bind to the phase, but there
is
>> no default binding in any of the mojos yet.
>>
>> How have you constructed your execution block?
>>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

-- 
View this message in context:
http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575576.html
Sent from the maven users mailing list archive at Nabble.com.

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

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

RE: [ANN] Maven 2.1.0 Released

Posted by "Brian E. Fox" <br...@reply.infinity.nu>.

The war plugin is introduced by the lifecycle. The mappings are
dependent on the packaging type. More info is available here:
http://www.sonatype.com/books/maven-book/reference/simple-project-sect-l
ifecycle.html

-----Original Message-----
From: Pankaj Tandon [mailto:pankajtandon@gmail.com] 
Sent: Thursday, April 02, 2009 11:17 AM
To: users@maven.apache.org
Subject: Re: [ANN] Maven 2.1.0 Released


Rob and Brian,
Thanks for the response. However, how then does the maven-war-plugin
run. I do NOT specify an execution section for that plugin, and it runs
in the package phase.
So I am not sure why is it necessary to mention the execution element at
all (with or without a phase). Just the plugin with a generic
configuration node should do.

Still confused,
Pankaj


> you still have to declare an executions element for the very same
phase in
the project that invkes this plugin.

That's right, except you don't have to specify the phase - the one
declared
by the mojo will be assumed.

2009/4/2 Pankaj Tandon <pa...@gmail.com>

>
> Hello Rob,
> I wanted to ask you about your comment below where you state that even
if
> you have an annotation in a mojo for the execution phase, you still
have to
> declare an executions element for the very same phase in the project
that
> invkes this plugin.
>
> That, kind of defeats the purpose of having a default phase specified
in
> the Mojo, does it not? And it certainly doesn't work that way for
other
> plugins (the war plugin for instance that is bound to the package
phase).
>
> So am I missing something here or is this a bug introduced with
2.0.10?
>
> Thanks
> Pankaj
>
>
> Okay, my mistake - although it was indeed the 2.1.0 mvn which was in
my
> path, I had forgotten to change the value of my M2_HOME environment
> variable.
>
> Therefore, it was actually 2.0.10 which was being executed, which was
why
> my
> goal was being ignored.
>
> And anyway, I had wrongly assumed that adding the '@phase
prepare-package'
> annotation to the mojo was enough to trigger the goal's execution -
you
> still have to add a <plugin><executions>...<goal> to the pom, and I
can
> confirm that this works fine.
>
> Many thanks to Brett for asistance.
>
> Rob
>
> 2009/3/25 Rob Dickens <ar...@googlemail.com>
>
> > As in a <plugins><plugin><executions><execution> block in the
pom.xml of
> > the jar-packaged project?
> >
> > There isn't one, since the plugin's mojo has a '@phase
prepare-package'.
> >
> > 2009/3/25 Brett Porter <br...@apache.org>
> >
> >
> >>
> >> On 25/03/2009, at 10:07 PM, Rob Dickens wrote:
> >>
> >>  Do jar-packaged projects now execute the new prepare-package
phase?
> >>>
> >>> Have just tried the new version out, hoping that my project with
jar
> >>> packaging would execute the new phase, to which one of my plug-in
goals
> >>> declares itself as being bound, but it appears not to.
> >>>
> >>
> >> All packaging types will if you properly bind to the phase, but
there is
> >> no default binding in any of the mojos yet.
> >>
> >> How have you constructed your execution block?
> >>
> >> Cheers,
> >> Brett
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://blogs.exist.com/bporter/
> >>
> >>
> >>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575576.html
> Sent from the maven users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Rob, Lafros.com



-- 
View this message in context:
http://n2.nabble.com/-ANN--Maven-2.1.0-Released-tp2515975p2575805.html
Sent from the maven users mailing list archive at Nabble.com.


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


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