[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ]
Lennart Jörelid commented on FORGE-440:
---------------------------------------
Sounds good - I assumed that I would have to use a stateful StAX event handler or equivalent,
to acquire XML events in order to capture the whitespace and comments as per above.
Does the Forge XML parser detect arbitrary XML structures/events, such as comments and
the like (as described in http://docs.oracle.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader..., for example)?
And - more importantly (this is just to point me in the right direction):
# Where is the Forge XML parser implementation and callback structure?
# How do we detect XPath changes for an element (i.e. the XPath before a Forge operation started and the corresponding XPath of the element after the operation completed)?
> A pom.xml which contains comments loses all of them after Forge operates on it.
> -------------------------------------------------------------------------------
>
> Key: FORGE-440
> URL: https://issues.jboss.org/browse/FORGE-440
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 1.0.6.Final
> Environment: HEAD
> Reporter: Pete Muir
> Fix For: 2.x Future
>
> Attachments: pomComments.png
>
>
> Also looses formatting, but this is less of an issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ]
Lennart Jörelid edited comment on FORGE-440 at 6/26/13 10:15 AM:
-----------------------------------------------------------------
I'll give it a spin in a day or two, to see if we can apply the changes to the POM after the POM is fully written.
I don't think that we need to worry all that much about breaking formatting in the pom, as we originate from a well-formed (but commented) POM.
... but I may be wrong; will check sanity and get back to you.
WRT the actual implementation, I believe that we can use something like a SAX handler to simplify identifying the whitespace and the following POM XML element.
was (Author: lennartj):
I'll give it a spin in a day or two, to see if we can apply the changes to the POM after the POM is fully written.
I don't think that we need to worry all that much about breaking formatting in the pom, as we originate from a well-formed (but commented) POM.
... but I may be wrong; will check sanity and get back to you.
WRT the actual implementation, I believe that we can use something like a SAX handler to simplify identifying the witespace and the following POM XML element.
> A pom.xml which contains comments loses all of them after Forge operates on it.
> -------------------------------------------------------------------------------
>
> Key: FORGE-440
> URL: https://issues.jboss.org/browse/FORGE-440
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 1.0.6.Final
> Environment: HEAD
> Reporter: Pete Muir
> Fix For: 2.x Future
>
> Attachments: pomComments.png
>
>
> Also looses formatting, but this is less of an issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ]
Lennart Jörelid commented on FORGE-440:
---------------------------------------
I'll give it a spin in a day or two, to see if we can apply the changes to the POM after the POM is fully written.
I don't think that we need to worry all that much about breaking formatting in the pom, as we originate from a well-formed (but commented) POM.
... but I may be wrong; will check sanity and get back to you.
WRT the actual implementation, I believe that we can use something like a SAX handler to simplify identifying the witespace and the following POM XML element.
> A pom.xml which contains comments loses all of them after Forge operates on it.
> -------------------------------------------------------------------------------
>
> Key: FORGE-440
> URL: https://issues.jboss.org/browse/FORGE-440
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 1.0.6.Final
> Environment: HEAD
> Reporter: Pete Muir
> Fix For: 2.x Future
>
> Attachments: pomComments.png
>
>
> Also looses formatting, but this is less of an issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on FORGE-440:
------------------------------------------
Hmmm... while that would work, I think that it would still lead to breaking formatting of POM files. This is something we can probably address at the same time, by mapping the Maven model to our own XML parser. However... I really don't look forward to doing all of that.
I just checked the m2eclipse source code, and they wrapped their own parser (in this case, the eclipse parser.) I think we should really do the same, unfortunately.
~Lincoln
> A pom.xml which contains comments loses all of them after Forge operates on it.
> -------------------------------------------------------------------------------
>
> Key: FORGE-440
> URL: https://issues.jboss.org/browse/FORGE-440
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 1.0.6.Final
> Environment: HEAD
> Reporter: Pete Muir
> Fix For: 2.x Future
>
> Attachments: pomComments.png
>
>
> Also looses formatting, but this is less of an issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-914) Rework the handling of 1:M relationships by the Faces/RichFaces scaffold
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-914?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds updated FORGE-914:
----------------------------------
Description:
The generated Faces scaffold for 1:M relationships does not handle certain usability aspects.
For example, a new row is automatically added by default when displaying a 1:M relationship upon create. However, unless the add button is clicked, the contents of the row are not added to the underlying managed bean. If the add button is not clicked, the contents of the row are not treated as a new item to be added. This is very confusing.
Also, if bean validation is performed on the entities (in the rows of the 1:M relationship), and if it fails, then the contents need to be corrected, even though they may not be persisted in the database. Again, this is confusing behavior.
Additionally, deletion of entities from the collection (1-side of the association) seems to be broken (FORGE-974).
was:
The generated Faces scaffold for 1:M relationships does not handle certain usability aspects.
For example, a new row is automatically added by default when displaying a 1:M relationship upon create. However, unless the add button is clicked, the contents of the row are not added to the underlying managed bean. If the add button is not clicked, the contents of the row are not treated as a new item to be added. This is very confusing.
Also, if bean validation is performed on the entities (in the rows of the 1:M relationship), and if it fails, then the contents need to be corrected, even though they may not be persisted in the database. Again, this is confusing behavior.
Additionally, deletion of entities from the collection (1-side of the association) seems to be broken.
> Rework the handling of 1:M relationships by the Faces/RichFaces scaffold
> ------------------------------------------------------------------------
>
> Key: FORGE-914
> URL: https://issues.jboss.org/browse/FORGE-914
> Project: Forge
> Issue Type: Bug
> Components: Scaffold
> Affects Versions: 1.0.5.Final, 1.3.0.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: 1.x Future
>
>
> The generated Faces scaffold for 1:M relationships does not handle certain usability aspects.
> For example, a new row is automatically added by default when displaying a 1:M relationship upon create. However, unless the add button is clicked, the contents of the row are not added to the underlying managed bean. If the add button is not clicked, the contents of the row are not treated as a new item to be added. This is very confusing.
> Also, if bean validation is performed on the entities (in the rows of the 1:M relationship), and if it fails, then the contents need to be corrected, even though they may not be persisted in the database. Again, this is confusing behavior.
> Additionally, deletion of entities from the collection (1-side of the association) seems to be broken (FORGE-974).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-974) Faces scaffolding does not correctly update collection members involved in bi-directional relationships when saving an edited entity
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/FORGE-974?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated FORGE-974:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=978076
> Faces scaffolding does not correctly update collection members involved in bi-directional relationships when saving an edited entity
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-974
> URL: https://issues.jboss.org/browse/FORGE-974
> Project: Forge
> Issue Type: Bug
> Components: Scaffold
> Affects Versions: 1.3.1.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
>
> The generated scaffold does not contain any logic to update collection properties of a JPA entity. This results in incorrect behavior when the collection is part of a bi-directional relationship in JPA.
> This is because no logic exists to remove both sides of the relationship when an entity instance is removed from the collection. The result of this absence in logic is that removal of entities from collection properties do not succeed. Upon save, the collection returns to it's previous state.
> Addition of members to the collection property are however performed correctly. Since the Faces scaffold does not allow updates to properties of the the individual members in the collection, no other issue is observed, except for the inability to update the collection state correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-974) Faces scaffolding does not correctly update collection members involved in bi-directional relationships when saving an edited entity
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/FORGE-974?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on FORGE-974:
-----------------------------------------------
Vineet Reynolds <vpereira(a)redhat.com> made a comment on [bug 978076|https://bugzilla.redhat.com/show_bug.cgi?id=978076]
Description of problem:
Deletion of performance dates and Ticket Prices doesn't work from the Edit Show screen. The items disappear, but after pressing "Save" button, they are back.
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Click an existing Show from the list of all Shows to view the Show details.
2. Click the Edit button to begin editing the Show.
3. Delete an existing Performance and/or a Ticket price.
4. Save the modified Show.
5. View the modified Show.
Actual results:
The deleted performances and ticket prices re-appear.
Expected results:
The deleted performances and ticket prices should be deleted on saving the modified Show.
Additional info:
This an underlying issue in JBoss Forge and not in the TicketMonster example .No workaround for this issue is currently known.
> Faces scaffolding does not correctly update collection members involved in bi-directional relationships when saving an edited entity
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-974
> URL: https://issues.jboss.org/browse/FORGE-974
> Project: Forge
> Issue Type: Bug
> Components: Scaffold
> Affects Versions: 1.3.1.Final
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
>
> The generated scaffold does not contain any logic to update collection properties of a JPA entity. This results in incorrect behavior when the collection is part of a bi-directional relationship in JPA.
> This is because no logic exists to remove both sides of the relationship when an entity instance is removed from the collection. The result of this absence in logic is that removal of entities from collection properties do not succeed. Upon save, the collection returns to it's previous state.
> Addition of members to the collection property are however performed correctly. Since the Faces scaffold does not allow updates to properties of the the individual members in the collection, no other issue is observed, except for the inability to update the collection state correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (FORGE-440) A pom.xml which contains comments loses all of them after Forge operates on it.
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-440?page=com.atlassian.jira.plugin.... ]
Lennart Jörelid commented on FORGE-440:
---------------------------------------
Hello there, Lincoln.
First off, [https://jira.codehaus.org/browse/MNG-5488#comment-327349] could likely use a peek and a vote or 50000. (Go there, folks - and Vote!)
;)
WRT the Forge side of things, I believe we have likely 2 ways to proceed:
# Wait for a generally available comment property in all major maven model types. This could possibly take quite some time - maybe even to imply a release of Maven's Model version 5 if accepted by the Apache community. Thus ... impractical in the short term.
# Accept that the Maven model is fundamentally flawed WRT comments, and create a datastructure and parser/joiner for it ourselves. This is also likely to be a non-trivial endeavour, but certainly doable.
Therefore...
h3. Potential approach to preserve XML comments in POMs
The POM itself should hold all comments both before and after a Forge operation.
Therefore, we should not need to save comment texts persistently in other places.
Assuming that all POM comments occur *before* an XML element, we must:
# Slurp up all text (verbatim!) between the end tag of the preceding POM element and the start of the current POM element. (We don't want to change developer's carefully crafted/formatted comments, ASCII-art or whatever).
# We'll ignore patterns of the type [newline][whitespace][start XML element], since this is not a comment or significant whitespace.
# For non-ignored patterns, find out the XPath + Element ID of the POM element immediately following the text we just slurped up.
# Create a transient Map<String, String> relating XPath to Comment text.
# When the dust settles following a Forge operation, try to find all elements which had a comment and re-insert the corresponding comment text before the start tag of the element found.
Come to think of it, this is not a particularly over-complex task.
I'll go for a dive in MavenFacetImpl source code - need to get a feel for it before voicing any recommendations or supplying a patch.
I take comfort in that unit tests should be a lifesaver in this particular case.
Attaching a screenshot to illustrate.
> A pom.xml which contains comments loses all of them after Forge operates on it.
> -------------------------------------------------------------------------------
>
> Key: FORGE-440
> URL: https://issues.jboss.org/browse/FORGE-440
> Project: Forge
> Issue Type: Bug
> Components: Build Tools - Maven
> Affects Versions: 1.0.6.Final
> Environment: HEAD
> Reporter: Pete Muir
> Fix For: 2.x Future
>
>
> Also looses formatting, but this is less of an issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months