[jira] Created: (MNG-4490) Maven3 is inconsistent about handling POMs

2009-12-12 Thread JIRA
Maven3 is inconsistent about handling POMs
--

 Key: MNG-4490
 URL: http://jira.codehaus.org/browse/MNG-4490
 Project: Maven 2  3
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-5
Reporter: Tamás Cservenák


As we learned from discussion happened in issue MNG-4368, Maven3 -- depending 
on packaging (pom vs anything else)  -- handles the POM installation in 
different ways.

When packaging is pom, the POM is _handled as artifact_, and MNG-4368 (and 
any other future optimization) interferes with it's installation. When 
packaging is not pom, the POM is _handled as repository metadata in Maven3 
internals.

IMHO, the latter should be _always_ the case, regardless of the packaging type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MNG-4490) Maven3 is inconsistent about handling POMs

2009-12-12 Thread Benjamin Bentmann (JIRA)

[ 
http://jira.codehaus.org/browse/MNG-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202357#action_202357
 ] 

Benjamin Bentmann commented on MNG-4490:


For the record, this is not specific to Maven 3 but applies equally to Maven 2.

 Maven3 is inconsistent about handling POMs
 --

 Key: MNG-4490
 URL: http://jira.codehaus.org/browse/MNG-4490
 Project: Maven 2  3
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-5
Reporter: Tamás Cservenák

 As we learned from discussion happened in issue MNG-4368, Maven3 -- depending 
 on packaging (pom vs anything else)  -- handles the POM installation in 
 different ways.
 When packaging is pom, the POM is _handled as artifact_, and MNG-4368 (and 
 any other future optimization) interferes with it's installation. When 
 packaging is not pom, the POM is _handled as repository metadata in Maven3 
 internals.
 IMHO, the latter should be _always_ the case, regardless of the packaging 
 type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MNG-4491) Maven3 reports warnings about POM problems in very spurious way

2009-12-12 Thread JIRA
Maven3 reports warnings about POM problems in very spurious way
---

 Key: MNG-4491
 URL: http://jira.codehaus.org/browse/MNG-4491
 Project: Maven 2  3
  Issue Type: Bug
  Components: Errors
Affects Versions: 3.0-alpha-5
Reporter: Tamás Cservenák


In relation to issue MNG-4490, Maven3 reported the following on CLI:

{noformat}
[WARNING] Invalid artifact metadata for 
org.sonatype.nexus:nexus-proxy:jar:1.4.1-SNAPSHOT, transitive dependencies (if 
any) will not be available, enable debug logging for more details
{noformat}

This is due to the issue above (the branch i worked on completely revamped the 
dependencies in aggregator poms, hence the module pom became invalid, since 
it contained dependencies that would be filled in from dependency management 
section, but they were not, hence by Maven3 they were considered invalid).

What I was thinking, that maybe we should distinguish between corrupt POMs in 
way like:

* syntactical broken, which is like unparseable POM (usually corrupted during 
transport or proxy issues)

* semantically broken -- this is what Maven3 tried to tell me -- a POM that was 
not correct in validation sense (in this case, depepndency had no version 
declared)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MECLIPSE-628) eclipse:eclipse shall create Subclipse config

2009-12-12 Thread Markus KARG (JIRA)
eclipse:eclipse shall create Subclipse config
-

 Key: MECLIPSE-628
 URL: http://jira.codehaus.org/browse/MECLIPSE-628
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Improvement
  Components: Core : Workspace settings
 Environment: Subclipse
Reporter: Markus KARG


A rather popular plugin for Eclipse is Subclipse, which integrates 
Subversion into Eclipse.

It would be great if the mvn eclipse:eclipse command would create configuration 
information for Subclipse, taken from either the locally found .svn folder, or 
even better, from the pom's scm settings. As a result, one could use 
Subclipse menu items inside of Eclipse. Currently to do that, after mvn 
eclipse:eclipse one has to manually setup that.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (MCHANGES-190) HTML in changes.xml stopped working

2009-12-12 Thread Dennis Lundberg (JIRA)

[ 
http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=202367#action_202367
 ] 

Dennis Lundberg commented on MCHANGES-190:
--

Hi Christian

It was I who made the patch from MCHANGES-189. I was struggling to get issues 
that contains html-entities to show up correctly in both the announcement and 
in the changes-report. I'll upload an example shortly showing what I mean.

 HTML in changes.xml stopped working
 ---

 Key: MCHANGES-190
 URL: http://jira.codehaus.org/browse/MCHANGES-190
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: changes-report
Affects Versions: 2.3
 Environment: Maven version: 2.0.10
 Java version: 1.5.0_17
 OS name: linux version: 2.6.32-686 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Critical
 Attachments: changes.xml


 The fix for MCHANGES-189 does not seem to be correct. A changes.xml file 
 containing HTML-Tags got rendered correctly using version 2.2. Starting with 
 version 2.3, HTML-Tags will be encoded using HTML entities for the '' and 
 '' characters leading to the actual tags getting shown in the report. See 
 the attached example changes.xml file containing HTML no longer working with 
 version 2.3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MCHANGES-190) HTML in changes.xml stopped working

2009-12-12 Thread Dennis Lundberg (JIRA)

 [ 
http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Lundberg updated MCHANGES-190:
-

Attachment: changes.xml

A file with  and  encoded as html entities. This file works as expected for 
both the announcement and the changes-report.

 HTML in changes.xml stopped working
 ---

 Key: MCHANGES-190
 URL: http://jira.codehaus.org/browse/MCHANGES-190
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: changes-report
Affects Versions: 2.3
 Environment: Maven version: 2.0.10
 Java version: 1.5.0_17
 OS name: linux version: 2.6.32-686 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Critical
 Attachments: changes.xml, changes.xml


 The fix for MCHANGES-189 does not seem to be correct. A changes.xml file 
 containing HTML-Tags got rendered correctly using version 2.2. Starting with 
 version 2.3, HTML-Tags will be encoded using HTML entities for the '' and 
 '' characters leading to the actual tags getting shown in the report. See 
 the attached example changes.xml file containing HTML no longer working with 
 version 2.3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MAVENUPLOAD-2689) TestNG 5.11

2009-12-12 Thread Cedric Beust (JIRA)
TestNG 5.11
---

 Key: MAVENUPLOAD-2689
 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2689
 Project: Maven Upload Requests
  Issue Type: Wish
Reporter: Cedric Beust
 Attachments: testng-5.11-bundle.jar

Hi guys,

Could you please publish TestNG 5.11, which I just released?

Thanks!


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MNG-4490) Inconsistent handling of POMs

2009-12-12 Thread Paul Benedict (JIRA)

 [ 
http://jira.codehaus.org/browse/MNG-4490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Benedict updated MNG-4490:
---

Summary: Inconsistent handling of POMs  (was: Maven3 is inconsistent about 
handling POMs)

 Inconsistent handling of POMs
 -

 Key: MNG-4490
 URL: http://jira.codehaus.org/browse/MNG-4490
 Project: Maven 2  3
  Issue Type: Bug
  Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-5
Reporter: Tamás Cservenák

 As we learned from discussion happened in issue MNG-4368, Maven3 -- depending 
 on packaging (pom vs anything else)  -- handles the POM installation in 
 different ways.
 When packaging is pom, the POM is _handled as artifact_, and MNG-4368 (and 
 any other future optimization) interferes with it's installation. When 
 packaging is not pom, the POM is _handled as repository metadata in Maven3 
 internals.
 IMHO, the latter should be _always_ the case, regardless of the packaging 
 type.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (MCHANGES-190) HTML in changes.xml stopped working

2009-12-12 Thread Christian Schulte (JIRA)

 [ 
http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christian Schulte updated MCHANGES-190:
---

Attachment: MCHANGES-190.zip

The changes file using HTML entities for the  and  characters does not work 
for me also.
Please unzip MCHANGES-190.zip and execute

{code}
mvn site
{code}

and compare the result using the 2.2 version and the 2.3 version. The 
changes.xml file therein contains two actions using the same HTML. In a cdata 
section and using HTML entities.

{code}
  action![CDATA[bbold/b - iitalic/i]]/action
  actionlt;bgt;boldlt;/bgt; - lt;igt;italiclt;/igt;/action
{code}

Using version 2.2, the raw HTML is rendered so a browser actually displays bold 
and italic text. Using version 2.3, the HTML got encoded so a browser displays 
the tags.


 HTML in changes.xml stopped working
 ---

 Key: MCHANGES-190
 URL: http://jira.codehaus.org/browse/MCHANGES-190
 Project: Maven 2.x Changes Plugin
  Issue Type: Bug
  Components: changes-report
Affects Versions: 2.3
 Environment: Maven version: 2.0.10
 Java version: 1.5.0_17
 OS name: linux version: 2.6.32-686 arch: i386 Family: unix
Reporter: Christian Schulte
Priority: Critical
 Attachments: changes.xml, changes.xml, MCHANGES-190.zip


 The fix for MCHANGES-189 does not seem to be correct. A changes.xml file 
 containing HTML-Tags got rendered correctly using version 2.2. Starting with 
 version 2.3, HTML-Tags will be encoded using HTML entities for the '' and 
 '' characters leading to the actual tags getting shown in the report. See 
 the attached example changes.xml file containing HTML no longer working with 
 version 2.3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira