You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by ji...@codehaus.org on 2004/10/16 03:02:21 UTC

[jira] Updated: (MPPOM-4) pom:install should produce a temporary standalone POM to copy to repo

The following issue has been updated:

    Updater: Brett Porter (mailto:brett@codehaus.org)
       Date: Fri, 15 Oct 2004 9:01 PM
    Changes:
             environment changed to 
             priority changed to Blocker
             Version changed to 1.4.1
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://jira.codehaus.org/browse/MPPOM-4?page=history

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/browse/MPPOM-4

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: MPPOM-4
    Summary: pom:install should produce a temporary standalone POM to copy to repo
       Type: Improvement

     Status: Open
   Priority: Blocker

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: maven-pom-plugin
   Fix Fors:
             1.4.2
   Versions:
             1.4.1

   Assignee: Brett Porter
   Reporter: John Casey

    Created: Fri, 23 Jul 2004 11:47 AM
    Updated: Fri, 15 Oct 2004 9:01 PM

Description:
Currently, pom:install does a file copy to the local repo. This has multiple problems.

* Entities are not resolved, and entity imports are not copied.
* Extends path can be relative, which makes it nearly impossible to use the pom in a meaningful way without also finding it's parent (usually the only way to resolve ../project.xml would be to do an scm checkout; but that info is in the pom that won't parse).

I propose the following:

prior to the file copy inside pom:install and pom:deploy, there should be a prereq="pom:generate-standalone" which would literally take the Project instance in memory and serialize it to a temporary project.xml (let's say target/project.xml or something). The pom:install and pom:deploy goals would then copy *that file* to the repo rather than the original project.xml file.

It would:

* Remove the extends element, because the Project instance is the result of any merges
* Remove the issue of discorporeal entities, since entity resolution would have happened before parsing the project.xml at the beginning of pom:xxx

I think this is still logically valid, since any pom in the repo is considered an artifact, and should be able to stand on it's own without complex interpretation. It would also be easy to do with xstream or any other type of xml serialization...even xpp3's XmlSerializer could do it, and the code to do so would be of minimal size.


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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