[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/24/13 9:02 PM:
----------------------------------------------------------------
But we could possibly add API calls to Forge which inserts comments - say *before* an element.
I do agree that the Maven core treats its model in ... uhm ... interesting ways, but one
could claim that a tool ridding all POMs of comments is difficult (at best) to use or introduce
when dealing with larger POMs.
... because such POMs need to be commented quite a bit to provide some means of explaining
*why* some plugins/configuration/properties are present. For instance, a huge parent pom such as
https://bitbucket.org/lennartj/nazgul_tools/src/4c72405abda254318338c0527...
needs its comments - or the usability of it is reduced even further. If Forge squashes the
comments, it is basically impossible to use Forge in any project that values its comments in POMs.
BTW - for my info, where is this functionality being implemented in the 2.x branch?
I would like to take a look and - possibly - lend a hand.
was (Author: lennartj):
But we could possibly add API calls to Forge which inserts comments - say *before* an element.
I do agree that the Maven core treats its model in ... uhm ... interesting ways, but one
could claim that a tool ridding all POMs of comments is difficult (at best) to use or introduce
when dealing with larger POMs.
... because such POMs need to be commented quite a bit to provide some means of explaining
*why* some plugins/configuration/properties are present. For instance, a huge parent pom such as
https://bitbucket.org/lennartj/nazgul_tools/src/4c72405abda254318338c0527...
needs its comments - or the usability of it is reduced even further. If Forge squashes the
comments, it is basically impossible to use Forge in any project that values its comments in POMs.
> 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, 9 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/24/13 9:00 PM:
----------------------------------------------------------------
But we could possibly add API calls to Forge which inserts comments - say *before* an element.
I do agree that the Maven core treats its model in ... uhm ... interesting ways, but one
could claim that a tool ridding all POMs of comments is difficult (at best) to use or introduce
when dealing with larger POMs.
... because such POMs need to be commented quite a bit to provide some means of explaining
*why* some plugins/configuration/properties are present. For instance, a huge parent pom such as
https://bitbucket.org/lennartj/nazgul_tools/src/4c72405abda254318338c0527...
needs its comments - or the usability of it is reduced even further. If Forge squashes the
comments, it is basically impossible to use Forge in any project that values its comments in POMs.
was (Author: lennartj):
But we could possibly add API calls to Forge which inserts comments - say *before* an element.
I do agree that the Maven core treats its model in ... uhm ... interesting ways, but one
could claim that a tool ridding all POMs of comments is difficult (at best) to use or introduce
when dealing with larger POMs.
... because such POMs need to be commented quite a bit to provide some means of explaining
*why* some plugins/configuration/properties are present in a parent pom.
For instance, a huge parent pom such as https://bitbucket.org/lennartj/nazgul_tools/src/4c72405abda254318338c0527...
needs its comments - or the usability of it is reduced even further. If Forge squashes the
comments, it is basically impossible to use Forge in any project that values its comments in POMs.
> 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, 9 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:
---------------------------------------
But we could possibly add API calls to Forge which inserts comments - say *before* an element.
I do agree that the Maven core treats its model in ... uhm ... interesting ways, but one
could claim that a tool ridding all POMs of comments is difficult (at best) to use or introduce
when dealing with larger POMs.
... because such POMs need to be commented quite a bit to provide some means of explaining
*why* some plugins/configuration/properties are present in a parent pom.
For instance, a huge parent pom such as https://bitbucket.org/lennartj/nazgul_tools/src/4c72405abda254318338c0527...
needs its comments - or the usability of it is reduced even further. If Forge squashes the
comments, it is basically impossible to use Forge in any project that values its comments in POMs.
> 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, 9 months
[JBoss JIRA] (FORGE-913) RichFaces scaffolding does not handle temporal fields in JPA entities correctly
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-913?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds resolved FORGE-913.
-----------------------------------
Resolution: Done
Resolved in 1.3.2.Final.
> RichFaces scaffolding does not handle temporal fields in JPA entities correctly
> -------------------------------------------------------------------------------
>
> Key: FORGE-913
> URL: https://issues.jboss.org/browse/FORGE-913
> 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.3.2.Final
>
>
> The RichFaces scaffold generator creates {{rich:calendar}} components in the facelets, but without a {{datePattern}} attribute. The behavior of this component in such a case is to not provide the embeddded timepicker. This works for temporal fields of type Date.
> But, this is certainly not sufficient for temporal fields of type Timestamp. A {{datePattern}} with a time pattern like {{MMM d, yyyy HH:mm}} or {{MMM d, yyyy hh:mm:a}} needs to be generated for such fields to allow time inputs.
> For temporal fields of type Time, consider generating a different widget, since the RichFaces calendar widget is not capable of providing the timepicker alone.
--
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, 9 months
[JBoss JIRA] (FORGE-913) RichFaces scaffolding does not handle temporal fields in JPA entities correctly
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-913?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds updated FORGE-913:
----------------------------------
Fix Version/s: 1.3.2.Final
(was: 1.x Future)
> RichFaces scaffolding does not handle temporal fields in JPA entities correctly
> -------------------------------------------------------------------------------
>
> Key: FORGE-913
> URL: https://issues.jboss.org/browse/FORGE-913
> 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.3.2.Final
>
>
> The RichFaces scaffold generator creates {{rich:calendar}} components in the facelets, but without a {{datePattern}} attribute. The behavior of this component in such a case is to not provide the embeddded timepicker. This works for temporal fields of type Date.
> But, this is certainly not sufficient for temporal fields of type Timestamp. A {{datePattern}} with a time pattern like {{MMM d, yyyy HH:mm}} or {{MMM d, yyyy hh:mm:a}} needs to be generated for such fields to allow time inputs.
> For temporal fields of type Time, consider generating a different widget, since the RichFaces calendar widget is not capable of providing the timepicker alone.
--
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, 9 months
[JBoss JIRA] (FORGE-913) RichFaces scaffolding does not handle temporal fields in JPA entities correctly
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-913?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds updated FORGE-913:
----------------------------------
Status: Closed (was: Pull Request Sent)
Resolution: Done
Pushed upstream : https://github.com/forge/core/commit/bad139e68befddf1d1f30286978a746a7c16...
RichFaces calendar components are now created with a datePattern attribute that contains time attributes. This results in a time picker made available during input of timestamps.
It should be noted that the apply button is not shown, and hence the time is defaulted, but modifiable.
> RichFaces scaffolding does not handle temporal fields in JPA entities correctly
> -------------------------------------------------------------------------------
>
> Key: FORGE-913
> URL: https://issues.jboss.org/browse/FORGE-913
> 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 RichFaces scaffold generator creates {{rich:calendar}} components in the facelets, but without a {{datePattern}} attribute. The behavior of this component in such a case is to not provide the embeddded timepicker. This works for temporal fields of type Date.
> But, this is certainly not sufficient for temporal fields of type Timestamp. A {{datePattern}} with a time pattern like {{MMM d, yyyy HH:mm}} or {{MMM d, yyyy hh:mm:a}} needs to be generated for such fields to allow time inputs.
> For temporal fields of type Time, consider generating a different widget, since the RichFaces calendar widget is not capable of providing the timepicker alone.
--
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, 9 months
[JBoss JIRA] (FORGE-913) RichFaces scaffolding does not handle temporal fields in JPA entities correctly
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-913?page=com.atlassian.jira.plugin.... ]
Vineet Reynolds reopened FORGE-913:
-----------------------------------
Reopening to set the fix version.
> RichFaces scaffolding does not handle temporal fields in JPA entities correctly
> -------------------------------------------------------------------------------
>
> Key: FORGE-913
> URL: https://issues.jboss.org/browse/FORGE-913
> 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 RichFaces scaffold generator creates {{rich:calendar}} components in the facelets, but without a {{datePattern}} attribute. The behavior of this component in such a case is to not provide the embeddded timepicker. This works for temporal fields of type Date.
> But, this is certainly not sufficient for temporal fields of type Timestamp. A {{datePattern}} with a time pattern like {{MMM d, yyyy HH:mm}} or {{MMM d, yyyy hh:mm:a}} needs to be generated for such fields to allow time inputs.
> For temporal fields of type Time, consider generating a different widget, since the RichFaces calendar widget is not capable of providing the timepicker alone.
--
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, 9 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:
----------------------------------
Issue Type: Bug (was: Task)
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.
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.
This task is a holder to fix such kind of issues in handling associations in the generated scaffold. Create sub-tasks as necessary for the individual issues that need fixing.
> 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.
--
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, 9 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.
This task is a holder to fix such kind of issues in handling associations in the generated scaffold. Create sub-tasks as necessary for the individual issues that need fixing.
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.
This task is a holder to fix such kind of issues in handling associations in the generated scaffold. Create sub-tasks as necessary for the individual issues that need fixing.
> 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: Task
> 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.
> This task is a holder to fix such kind of issues in handling associations in the generated scaffold. Create sub-tasks as necessary for the individual issues that need fixing.
--
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, 9 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 reassigned FORGE-914:
-------------------------------------
Assignee: Vineet Reynolds
> 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: Task
> 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.
> This task is a holder to fix such kind of issues in handling associations in the generated scaffold. Create sub-tasks as necessary for the individual issues that need fixing.
--
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, 9 months