[jira] (MPMD-144) An incomplete fix for the resource leak bugs in PmdReport.java

2012-02-21 Thread Guangtai Liang (JIRA)
Guangtai Liang created MPMD-144:
---

 Summary: An incomplete fix for the resource leak bugs in 
PmdReport.java
 Key: MPMD-144
 URL: https://jira.codehaus.org/browse/MPMD-144
 Project: Maven 2.x PMD Plugin
  Issue Type: Bug
  Components: PMD
Affects Versions: 2.8
Reporter: Guangtai Liang
Priority: Critical


The fix revision 935344 was aimed to remove an resource leak bug on the 
OutputStreamWriter object "writer" (created in line 323) in the method 
"execute()" of the file 
"/maven/plugins/trunk/maven-pmd-plugin/src/main/java/org/apache/maven/plugin/pmd/PmdReport.java"
 , but it is incomplete. 

There are some problems: 
1. when "writer" is not created successfully but the FileOutputStream object 
"tStream" is created successfully at line 322,"tStream" will be leaked. 

The best way to close such resource objects is putting such close operations in 
the finaly block of a try-catch-finally structure.

The problem still exists in the head revision. The buggy code is copied as 
bellows: 

   try
{
targetDirectory.mkdirs();
File targetFile = new File( targetDirectory, "pmd." + format );
357FileOutputStream tStream = new FileOutputStream( targetFile );
358writer = new OutputStreamWriter( tStream, getOutputEncoding() );

r.setWriter( writer );
r.start();
r.renderFileReport( report );
r.end();
writer.close();

File siteDir = getReportOutputDirectory();
siteDir.mkdirs();
FileUtils.copyFile( targetFile, new File( siteDir, "pmd." + format 
) );
}
catch ( IOException ioe )
{
throw new MavenReportException( ioe.getMessage(), ioe );
}
finally
{
376   IOUtil.close( writer );
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect

2012-02-21 Thread Leo Leung (JIRA)

[ 
https://jira.codehaus.org/browse/MASSEMBLY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292395#comment-292395
 ] 

Leo Leung commented on MASSEMBLY-449:
-

@Kristian Rosenvold Thanks for that. Overriding the dependency to plexus-io 
2.0.3 worked.

> Permissions on directories in a zipped archive incorrect
> 
>
> Key: MASSEMBLY-449
> URL: https://jira.codehaus.org/browse/MASSEMBLY-449
> Project: Maven 2.x Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.2-beta-4
>Reporter: James Kavanagh
>
> Using the following assembly plugin:
> {code:xml}
> 
> target-packaged
> 
> zip
> 
> false
> 
> 
> 
> *:core-env
> 
> 
> env
> false
> true
> 
> 
> 
> 
> *:data-bridge
> 
> 
> target
> false
> true
> 
> 
> 
> 
> *:web
> 
> 
> web
> false
> true
> 
> 
> 
> 
> {code}
> When unzipping the result on a Linux host all the directory permissions have 
> been set to 777.
> If I revert the plugin version to 2.2-beta-3 the issue goes away.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSITE-617) Variable substitution in the site url doesn't work

2012-02-21 Thread Firass Shehadeh (JIRA)

[ 
https://jira.codehaus.org/browse/MSITE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292384#comment-292384
 ] 

Firass Shehadeh commented on MSITE-617:
---

I ran into a similar situation. I have a multi-module project, and I usually 
set the  element using a variable (so that I can deploy the site to 
different location based on what's configured in my profile in 
~/.m2/settings.xml). This used to work perfectly with Maven 2, but when I 
upgraded to Maven 3, I noticed that some plugins are seeing something like 
"${variable}" as opposed to resolved variable value. In my case, it is the site 
plugin that is confused since it was creating the links to the children 
projects using URLs that had text like this "${variable}", which doesn't work.

> Variable substitution in the site url doesn't work
> --
>
> Key: MSITE-617
> URL: https://jira.codehaus.org/browse/MSITE-617
> Project: Maven 2.x and 3.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 2.3
> Environment: Windows 7 and RHEL6
>Reporter: Claus Nielsen
>
> site:deploy fails because variable substitution in the site url no longer 
> works (it did in version 2.2).
> The distributionManagement section in out POM looks something like this:
> 
>   
>   sites
>   Project Website
>   
> scp://server/sites/${project.artifactId}/${project.version}
>   
> 
> Copying the site to the above mentioned url fails with this message:
> [INFO] Error uploading site
> Embedded error: Error performing commands for file transfer
> Exit code: 1 - bash: 
> /sites/${project.artifactId}/${project.version}/../../id-of-the-artifact/0.2.8-SNAPSHOT:
>  bad substitution
> Ie. the substitutiuon variables have not been substituted, instead the 
> property values have been appended to the url along with a few dots and 
> dashes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report

2012-02-21 Thread Dennis Lundberg (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MCHECKSTYLE-172:


Testcase included:   (was: yes)

> Checkstyle Plugin 2.8+ generates an additional aggregate report
> ---
>
> Key: MCHECKSTYLE-172
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.8, 2.9
> Environment: {{{
> mvn --version
> Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
> }}}
>Reporter: SebbASF
>
> Using a very simple single module project, the aggregated report is created 
> by default.
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report

2012-02-21 Thread Dennis Lundberg (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MCHECKSTYLE-172:


  Description: 
Using a very simple single module project, the aggregated report is created by 
default.

Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.

  was:
Using a very simple single module project, the aggregated report is created by 
default and reports an incorrect number of violations, it just doubles the 
numbers. I checked out 
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-checkstyle-plugin-2.8 
and modified the integration test project {{checkstyle-report}} a little bit:
* I deleted the {{reportSets}} configuration from the {{pom.xml}}.
* I modified {{src/main/java/org/MyClass.java}} to actually have errors.

The build log looks like this:
{code}
[mirko@borg checkstyle-report]$ mvn clean site
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building check-pass 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ check-pass ---
[INFO] Deleting 
/Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/target
[INFO] 
[INFO] --- maven-site-plugin:3.0:site (default-site) @ check-pass ---
[INFO] configuring report plugin 
org.apache.maven.plugins:maven-checkstyle-plugin:2.8
[INFO] Relativizing decoration links with respect to project URL: 
http://maven.apache.org/
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 
skin.
[INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
[INFO] 
[INFO] There are 2 checkstyle errors.
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
[INFO] 
[INFO] There are 4 checkstyle errors.
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 4.847s
[INFO] Finished at: Tue Nov 29 21:13:40 CET 2011
[INFO] Final Memory: 12M/81M
[INFO] 
{code}

{{target/checkstyle-result.xml}} looks like this and reports the same errors 
twice:
{code}











{code}

Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated and 
{{checkstyle-aggregate}} reports the same errors twice. I attach the patched 
project which includes a check in {{verify.groovy}} to assert that only one 
{{file}} entry is present in the created {{target/checkstyle-result.xml}}.

Affects Version/s: 2.9
  Summary: Checkstyle Plugin 2.8+ generates an additional aggregate 
report  (was: Checkstyle runs aggregate report on projects without modules)

> Checkstyle Plugin 2.8+ generates an additional aggregate report
> ---
>
> Key: MCHECKSTYLE-172
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.8, 2.9
> Environment: {{{
> mvn --version
> Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
> Maven home: /usr/local/Cellar/maven/current/libexec
> Java version: 1.6.0_29, vendor: Apple Inc.
> Java home: 
> /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
> Default locale: de_DE, platform encoding: MacRoman
> OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac"
> }}}
>Reporter: SebbASF
>
> Using a very simple single module project, the aggregated report is created 
> by default.
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MNG-5250) DefaultVersionResolver.readVersions reads snapshot versions from release only repositories

2012-02-21 Thread Yoav Abrahami (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292360#comment-292360
 ] 

Yoav Abrahami commented on MNG-5250:


I did not submit a patch as I am not sure if this is the way you wanna fix this 
issue. However, I have tested my solution and it seems to work fine for large 
maven 2 projects with LATEST for both parent and dependencies

> DefaultVersionResolver.readVersions reads snapshot versions from release only 
> repositories
> --
>
> Key: MNG-5250
> URL: https://jira.codehaus.org/browse/MNG-5250
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Dependencies, Embedding
>Affects Versions: 3.0.4
> Environment: embedded maven
>Reporter: Yoav Abrahami
>
> with the below repositories configuration in settings.xml [1]
> I get an error that a parent of a project is not found if the parent version 
> is marked as LATEST. 
> The actual error is 
> "Could not find artifact XXX in snapshots (URL of SNAPSHOT repository)"
> while debugging the reason, I have found that because the 
> DefaultVersionResolver.readVersions() method returns SNAPSHOT versions when 
> reading versions from a release only repository (repository with snapshot 
> policy not enabled).
> The fix I have in place is to add to the 
> DefaultVersionResolver.readVersions() method the following fragment:
> (see the full method below [2]
> {code}
> /*
>  * fix for LATEST - repository who does not support snapshots should not 
> return shapshot versions
>  */
> if (versioning != null && repository instanceof RemoteRepository) {
>   RemoteRepository remoteRepository = (RemoteRepository)repository;
>   if (!remoteRepository.getPolicy(true).isEnabled()) {
> Versioning repaired = new Versioning();
> repaired.setLastUpdated(versioning.getLastUpdated());
> repaired.setRelease(versioning.getRelease());
> repaired.setVersions(versioning.getVersions());
> versioning = repaired;
>   }
> }
> {code}
> [1] : 
> {code}
> 
> 
>   
> false
>   
>   central
>   libs-releases
>   http://repo.dev.wix/artifactory/libs-releases
> 
> 
>   
>   snapshots
>   libs-snapshots
>   http://repo.dev.wix/artifactory/libs-snapshots
> 
>   
> {code}
> [2] : 
> {code}
> private Versioning readVersions( RepositorySystemSession session, 
> RequestTrace trace, Metadata metadata,
>  ArtifactRepository repository, 
> VersionResult result )
> {
> Versioning versioning = null;
> FileInputStream fis = null;
> try
> {
> if ( metadata != null )
> {
> SyncContext syncContext = syncContextFactory.newInstance( 
> session, true );
> try
> {
> syncContext.acquire( null, Collections.singleton( 
> metadata ) );
> if ( metadata.getFile() != null && 
> metadata.getFile().exists() )
> {
> fis = new FileInputStream( metadata.getFile() );
> 
> org.apache.maven.artifact.repository.metadata.Metadata m =
> new MetadataXpp3Reader().read( fis, false );
> versioning = m.getVersioning();
> /*
>  * NOTE: Users occasionally misuse the id "local" for 
> remote repos which screws up the metadata
>  * of the local repository. This is especially 
> troublesome during snapshot resolution so we try
>  * to handle that gracefully.
>  */
> if ( versioning != null && repository instanceof 
> LocalRepository )
> {
> if ( versioning.getSnapshot() != null && 
> versioning.getSnapshot().getBuildNumber() > 0 )
> {
> Versioning repaired = new Versioning();
> repaired.setLastUpdated( 
> versioning.getLastUpdated() );
> Snapshot snapshot = new Snapshot();
> snapshot.setLocalCopy( true );
> repaired.setSnapshot( snapshot );
> versioning = repaired;
> throw new IOException( "Snapshot information 
> corrupted with remote repository data"
> + ", please verify that no remote 
> repository uses the id '" + repository.getId()
> + "'" );
> }
>   

[jira] (MNG-5250) DefaultVersionResolver.readVersions reads snapshot versions from release only repositories

2012-02-21 Thread Yoav Abrahami (JIRA)
Yoav Abrahami created MNG-5250:
--

 Summary: DefaultVersionResolver.readVersions reads snapshot 
versions from release only repositories
 Key: MNG-5250
 URL: https://jira.codehaus.org/browse/MNG-5250
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Dependencies, Embedding
Affects Versions: 3.0.4
 Environment: embedded maven
Reporter: Yoav Abrahami


with the below repositories configuration in settings.xml [1]
I get an error that a parent of a project is not found if the parent version is 
marked as LATEST. 
The actual error is 
"Could not find artifact XXX in snapshots (URL of SNAPSHOT repository)"
while debugging the reason, I have found that because the 
DefaultVersionResolver.readVersions() method returns SNAPSHOT versions when 
reading versions from a release only repository (repository with snapshot 
policy not enabled).

The fix I have in place is to add to the DefaultVersionResolver.readVersions() 
method the following fragment:
(see the full method below [2]

{code}
/*
 * fix for LATEST - repository who does not support snapshots should not return 
shapshot versions
 */
if (versioning != null && repository instanceof RemoteRepository) {
  RemoteRepository remoteRepository = (RemoteRepository)repository;
  if (!remoteRepository.getPolicy(true).isEnabled()) {
Versioning repaired = new Versioning();
repaired.setLastUpdated(versioning.getLastUpdated());
repaired.setRelease(versioning.getRelease());
repaired.setVersions(versioning.getVersions());
versioning = repaired;
  }
}
{code}


[1] : 
{code}


  
false
  
  central
  libs-releases
  http://repo.dev.wix/artifactory/libs-releases


  
  snapshots
  libs-snapshots
  http://repo.dev.wix/artifactory/libs-snapshots

  
{code}
[2] : 
{code}
private Versioning readVersions( RepositorySystemSession session, 
RequestTrace trace, Metadata metadata,
 ArtifactRepository repository, 
VersionResult result )
{
Versioning versioning = null;

FileInputStream fis = null;
try
{
if ( metadata != null )
{
SyncContext syncContext = syncContextFactory.newInstance( 
session, true );

try
{
syncContext.acquire( null, Collections.singleton( metadata 
) );

if ( metadata.getFile() != null && 
metadata.getFile().exists() )
{
fis = new FileInputStream( metadata.getFile() );
org.apache.maven.artifact.repository.metadata.Metadata 
m =
new MetadataXpp3Reader().read( fis, false );
versioning = m.getVersioning();

/*
 * NOTE: Users occasionally misuse the id "local" for 
remote repos which screws up the metadata
 * of the local repository. This is especially 
troublesome during snapshot resolution so we try
 * to handle that gracefully.
 */
if ( versioning != null && repository instanceof 
LocalRepository )
{
if ( versioning.getSnapshot() != null && 
versioning.getSnapshot().getBuildNumber() > 0 )
{
Versioning repaired = new Versioning();
repaired.setLastUpdated( 
versioning.getLastUpdated() );
Snapshot snapshot = new Snapshot();
snapshot.setLocalCopy( true );
repaired.setSnapshot( snapshot );
versioning = repaired;

throw new IOException( "Snapshot information 
corrupted with remote repository data"
+ ", please verify that no remote 
repository uses the id '" + repository.getId()
+ "'" );
}
}

/*
 * fix for LATEST - repository who does not support 
snapshots should not return shapshot versions
 */
if (versioning != null && repository instanceof 
RemoteRepository) {
RemoteRepository remoteRepository = 
(RemoteRepository)repository;
if (!remoteRepository.getPolicy(true).isEnabled()) {
Versioning repaired = new Versioning();

repaired.setLastUpdated(versioning.getLastUpdated());
repaired.setRelease(versionin

[jira] (MCHECKSTYLE-173) Embedded error: Cannot set property 'charset' in module Checker to 'UTF-8,UTF-8': UTF-8,UTF-8

2012-02-21 Thread Dennis Lundberg (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg closed MCHECKSTYLE-173.
---

   Resolution: Fixed
Fix Version/s: 2.9.1

Fixed in [r1291005|http://svn.apache.org/viewvc?view=revision&revision=1291005] 
and [r1291009|http://svn.apache.org/viewvc?view=revision&revision=1291009].

> Embedded error: Cannot set property 'charset' in module Checker to 
> 'UTF-8,UTF-8': UTF-8,UTF-8
> -
>
> Key: MCHECKSTYLE-173
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-173
> Project: Maven 2.x Checkstyle Plugin
>  Issue Type: Bug
>Affects Versions: 2.9
> Environment: Windows and linux, same problem
>Reporter: Harald Lammers
>Assignee: Dennis Lundberg
> Fix For: 2.9.1
>
> Attachments: checkstyle.log, site.log
>
>
> Changes are checkstyle-plugin update from 2.8 to 2.9.
> Same problem with 'mvn checkstyle:check' and 'mvn site'
> Logging added in this issue report.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEPLOY-146) deploy:deploy-file pushed a POM even when generatePom is false and no pom is supplied

2012-02-21 Thread Benson Margulies (JIRA)
Benson Margulies created MDEPLOY-146:


 Summary: deploy:deploy-file pushed a POM even when generatePom is 
false and no pom is supplied
 Key: MDEPLOY-146
 URL: https://jira.codehaus.org/browse/MDEPLOY-146
 Project: Maven 2.x and 3.x Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy-file
Affects Versions: 2.7
Reporter: Benson Margulies


Consider the following set of steps:

# deploy:deploy-file to push a regular jar and a pom
# deploy:deploy-file to push a sources jar with a classifier

if you don't pass -DpomFile to the second one, it will create and push a stub 
pom even if -DgeneratePom=false. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories

2012-02-21 Thread Henri Gomez (JIRA)

[ 
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292301#comment-292301
 ] 

Henri Gomez edited comment on MSHADE-103 at 2/21/12 7:06 AM:
-

I've got the same behaviour but in another context.

A project with parent pom (in SNAPSHOT) deployed in artifactory.
Project build works fine from Maven (3.0.3) command line or via Jenkins (1.451) 
in a FreeStyle job but it fail with same error when building project in Jenkins 
as a Maven job.

If I put back artifactory repos location in pom.xml (which is weird), 
everything goes fine.

Tried with shade 1.3.2 and 1.5.0

Anyone encountered the problem ?

PS: JIRA opened in Jenkins : https://issues.jenkins-ci.org/browse/JENKINS-12843

  was (Author: hgomez):
I've got the same behaviour but in another context.

A project with parent pom (in SNAPSHOT) deployed in artifactory.
Project build works fine from Maven (3.0.3) command line or via Jenkins (1.451) 
in a FreeStyle job but it fail with same error when building project in Jenkins 
as a Maven job.

If I put back artifactory repos location in pom.xml (which is weird), 
everything goes fine.

Tried with shade 1.3.2 and 1.5.0

Anyone encountered the problem ?
  
> maven-shade-plugin does not resolve from user-defined repositories
> --
>
> Key: MSHADE-103
> URL: https://jira.codehaus.org/browse/MSHADE-103
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.3.3, 1.4
> Environment: Maven 3.0.3 (works with 2.2.1)
>Reporter: Lukas Fryc
>
> maven-shade-plugin doesn't consult repositories defined in 
> settings.xml when trying to resolve parents of given pom. It contacts 
> only central repo: 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on 
> project richfaces-components-api: Error creating shaded jar: 1 problem 
> was encountered while building the effective model for 
> org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT 
> [ERROR] [FATAL] Non-resolvable parent POM for 
> org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact 
> org.richfaces:richfaces-parent:pom:10 in central 
> (http://repo1.maven.org/maven2) and 'parent.relativePath' points at 
> wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, 
> /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 
> [ERROR] for project 
> org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at 
> /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
>  
> for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at 
> /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
>  
> [ERROR] -> [Help 1] 
> There is affected project (it references version 1.3.3, but the behavior is 
> same with 1.4) if you would like to try at own: 
> https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

2012-02-21 Thread Stephane Nicoll (JIRA)

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292310#comment-292310
 ] 

Stephane Nicoll edited comment on MEAR-141 at 2/21/12 2:58 AM:
---

It has nothing to do with linux. It's failing with maven 2.x

Instead of reverting, can't you reopen this issue and ignore the test instead. 
It's working fine with Maven 3, we just need to figure out what is going wrong 
in plexus with 2.x

  was (Author: sni):
It has nothing to do with linux. It's failing with maven 2.x
  
> No way to configure generate env-entry elements in generated application.xml
> 
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring 
> security-role-names in a generated application.xml.  It does not offer such a 
> facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

2012-02-21 Thread Stephane Nicoll (JIRA)

[ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292310#comment-292310
 ] 

Stephane Nicoll commented on MEAR-141:
--

It has nothing to do with linux. It's failing with maven 2.x

> No way to configure generate env-entry elements in generated application.xml
> 
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring 
> security-role-names in a generated application.xml.  It does not offer such a 
> facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"

2012-02-21 Thread Hu weisong (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292309#comment-292309
 ] 

Hu weisong commented on MDEP-259:
-

I met same error on 2.1 , update to latest 2.4 , it solved .

> copy-dependencies fails with "Error copying artifact from .../target/classes 
> to .../classes"
> 
>
> Key: MDEP-259
> URL: https://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
>  Issue Type: Bug
>  Components: copy-dependencies
>Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
>Reporter: Andreas Veithen
>Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is 
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven 
> project with generated test (re)sources. In this case, one would execute "mvn 
> generate-test-resources eclipse:eclipse" to make sure that the generated 
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin 
> executes generate-sources and generate-resources, but not 
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> [INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to 
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error copying artifact from 
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to 
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error: 
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No 
> such file or directory)
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with 
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because 
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package 
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails 
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the 
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed, 
> package phase not executed), Artifact#getFile() points to the target/classes 
> directory instead of the output artifact. dependency:copy-dependencies 
> doesn't detect this situation and blindly attempts to execute the copy 
> operation. This fails with the error message shown above. Note that even if 
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect 
> this situation and let it replace the original Artifact object by a new one 
> resolved from the repository (which would then refer to the artifact 
> generated by a previous build, exactly as in the mvn generate-resources case).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MEAR-141) No way to configure generate env-entry elements in generated application.xml

2012-02-21 Thread Kristian Rosenvold (JIRA)

 [ 
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reopened MEAR-141:
-


I just reverted this commit in r129166 since it was breaking the IT's on 32 bit 
linux.



> No way to configure generate env-entry elements in generated application.xml
> 
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stephane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring 
> security-role-names in a generated application.xml.  It does not offer such a 
> facility for generating {{env-entry}} elements.  It should.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] (MSHADE-103) maven-shade-plugin does not resolve from user-defined repositories

2012-02-21 Thread Henri Gomez (JIRA)

[ 
https://jira.codehaus.org/browse/MSHADE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292301#comment-292301
 ] 

Henri Gomez commented on MSHADE-103:


I've got the same behaviour but in another context.

A project with parent pom (in SNAPSHOT) deployed in artifactory.
Project build works fine from Maven (3.0.3) command line or via Jenkins (1.451) 
in a FreeStyle job but it fail with same error when building project in Jenkins 
as a Maven job.

If I put back artifactory repos location in pom.xml (which is weird), 
everything goes fine.

Tried with shade 1.3.2 and 1.5.0

Anyone encountered the problem ?

> maven-shade-plugin does not resolve from user-defined repositories
> --
>
> Key: MSHADE-103
> URL: https://jira.codehaus.org/browse/MSHADE-103
> Project: Maven 2.x Shade Plugin
>  Issue Type: Bug
>Affects Versions: 1.3.3, 1.4
> Environment: Maven 3.0.3 (works with 2.2.1)
>Reporter: Lukas Fryc
>
> maven-shade-plugin doesn't consult repositories defined in 
> settings.xml when trying to resolve parents of given pom. It contacts 
> only central repo: 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:1.4:shade (default) on 
> project richfaces-components-api: Error creating shaded jar: 1 problem 
> was encountered while building the effective model for 
> org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT 
> [ERROR] [FATAL] Non-resolvable parent POM for 
> org.richfaces:richfaces-bom:4.1.0-SNAPSHOT: Could not find artifact 
> org.richfaces:richfaces-parent:pom:10 in central 
> (http://repo1.maven.org/maven2) and 'parent.relativePath' points at 
> wrong local POM @ org.richfaces:richfaces-bom:4.1.0-SNAPSHOT, 
> /home/lfryc/workspaces/richfaces/build/bom/pom.xml, line 24, column 10 
> [ERROR] for project 
> org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at 
> /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
>  
> for project org.richfaces.ui:richfaces-components-api:4.1.0-SNAPSHOT at 
> /home/lfryc/workspaces/richfaces/components/dist/richfaces-components-api/dependency-reduced-pom.xml
>  
> [ERROR] -> [Help 1] 
> There is affected project (it references version 1.3.3, but the behavior is 
> same with 1.4) if you would like to try at own: 
> https://github.com/richfaces/components/blob/develop/dist/richfaces-components-api/pom.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira