[jira] Commented: (MPPOM-4) pom:install should produce a temporary standalone POM to copy to repo
The following comment has been added to this issue:
Author: Felipe Leme
Created: Thu, 14 Oct 2004 7:46 AM
Body:
I was going to open a similar issue, as sometimes we have JEXL/EL expressions on the
POM that should be resolved before being the POM is deployed.
Take for instance the Cactus plugin:
cactus
cactus
13-${pom.currentVersion}
I could start the work on the "pom:generate-standalone" task, so it would resolve the
EL expressions, but I wouldn't be able to solve the XML issues (I don't know how to do
it and it would take to much time to figure it out).
-- Felipe
-
View this comment:
http://jira.codehaus.org/browse/MPPOM-4?page=comments#action_25361
-
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
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-pom-plugin
Assignee: Jason van Zyl
Reporter: John Casey
Created: Fri, 23 Jul 2004 11:47 AM
Updated: Thu, 14 Oct 2004 7:46 AM
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPPOM-4) pom:install should produce a temporary standalone POM to copy to repo
The following comment has been added to this issue: Author: John Casey Created: Fri, 23 Jul 2004 12:03 PM Body: seems like a better long-term solution than the doco upgrade to me...thought we should talk about it, so I put them both out there (one before this occurred to me, the second this one). - View this comment: http://jira.codehaus.org/browse/MPPOM-4?page=comments#action_22199 - 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 Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-pom-plugin Assignee: Jason van Zyl Reporter: John Casey Created: Fri, 23 Jul 2004 11:47 AM Updated: Fri, 23 Jul 2004 12:03 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPPOM-4) pom:install should produce a temporary standalone POM to copy to repo
The following comment has been added to this issue: Author: Julien Kirch Created: Fri, 23 Jul 2004 11:59 AM Body: Seems to be a sequel of MAVEN-1390 . - View this comment: http://jira.codehaus.org/browse/MPPOM-4?page=comments#action_22198 - 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 Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: maven-pom-plugin Assignee: Jason van Zyl Reporter: John Casey Created: Fri, 23 Jul 2004 11:47 AM Updated: Fri, 23 Jul 2004 11:59 AM 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
