[jira] [Commented] (JCRVLT-271) Support a CLI command to format vault xml files
[ https://issues.apache.org/jira/browse/JCRVLT-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368419#comment-16368419 ] Tobias Bocanegra commented on JCRVLT-271: - thanks. I quickly looked at the PR. I think these changes cause the items to be sorted twice during normal package assembly. I added some comments to the PR in github. ps: thanks for the CLA. I can confirm that you are listed. > Support a CLI command to format vault xml files > --- > > Key: JCRVLT-271 > URL: https://issues.apache.org/jira/browse/JCRVLT-271 > Project: Jackrabbit FileVault > Issue Type: New Feature > Components: Misc >Reporter: Dirk Rudolph >Priority: Major > > In our projects we work with vlt IDE integrations (Intellij and Eclpise) to > have an easy and feature rich development process. On the other hand there > are situations where we are writing vlt xml files manually. To not have huge > diffs of formatting changes we tend to commit those vlt xml files formatted > in the way as they are produced by exporting the corresponding nodes from a > remote repository. > Unfortunately the format can not fully be achieved by formatting using the > build in xml formatters of the IDE, nor am I aware of any tooling that would > allow us to check the formatting using lets say a commit hook or maven > plugin. So the common approach we use at the moment is to push and afterwards > pull nodes to or from the remote repository. > To improve that, only formatting the local files with the format the export > uses is much more efficient and can also be automated. > This is a proposal to introduce a _format_ command for the vlt-cli that: > * accepts a list of file patterns that should be processed in the current > directory tree > * formats each file included by the patterns or > * checks if the file is in the right format and fails if not with a list of > all malformed files > This can then be used to: > * automatically format by cli invocation > * validate the format during build or as pre commit hook -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-271) Support a CLI command to format vault xml files
[
https://issues.apache.org/jira/browse/JCRVLT-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368293#comment-16368293
]
Dirk Rudolph edited comment on JCRVLT-271 at 2/17/18 5:28 PM:
--
Thank you for those information [~tripod]. With those I also added the
capability of sorting the attributes according to the format implied in the
DocViewSAXFormatter.
I moved the logic from the vault-cli to vault-core to not require consumers
(like IDE plugins) to depend on the vault-cli artefact. Additionally I moved
the logic of the attribute name sorting in AttributeNameComparator and used it
in the ItemNameComparator. The Comparator can now be set to the OutputFormat so
that the DocViewSerializer has exactly the same format as the methods for
formatting of the new DocViewFormat singleton. There is one thing I'm not sure
if it makes sense to be changed. The javadoc of XMLSerializer says:
{quote}This class and dependencies were copied from the sun jdk1.5 source base.
The original serializer is extended by a new OutputFormat setting that allows
to break the line for each attribute. additionally, *all attribute names are
sorted alphabetically*.
{quote}
which wasn't true, as until now there was no sorting of the attributes at all
in this class. Maybe we should rephrase or remove that.
+ CLA signed and I'm listed now as you requested.
was (Author: diru):
Thank you for those information [~tripod]. With those I also added the
capability of sorting the attributes according to the format implied in the
DocViewSAXFormatter.
I moved the logic from the vault-cli to vault-core to not require consumers
(like IDE plugins) to depend on the vault-cli artefact. Additionally I moved
the logic of the attribute name sorting in AttributeNameComparator and used it
in the ItemNameComparator. The Comparator can now be set to the OutputFormat so
that the DocViewSerializer has exactly the same format as the methods for
formatting of the new DocViewFormat singleton. There is one thing I'm not sure
if it makes sense to be changed. The javadoc of XMLSerializer says:
{quote}
This class and dependencies were copied from the sun jdk1.5 source base. The
original serializer is extended by a new OutputFormat setting that allows to
break the line for each attribute. additionally, *all attribute names are
sorted alphabetically*.
{quote}
which wasn't true, as until now there was no sorting of the attributes at all
in this class. Maybe we should rephrase or remove that.
> Support a CLI command to format vault xml files
> ---
>
> Key: JCRVLT-271
> URL: https://issues.apache.org/jira/browse/JCRVLT-271
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Misc
>Reporter: Dirk Rudolph
>Priority: Major
>
> In our projects we work with vlt IDE integrations (Intellij and Eclpise) to
> have an easy and feature rich development process. On the other hand there
> are situations where we are writing vlt xml files manually. To not have huge
> diffs of formatting changes we tend to commit those vlt xml files formatted
> in the way as they are produced by exporting the corresponding nodes from a
> remote repository.
> Unfortunately the format can not fully be achieved by formatting using the
> build in xml formatters of the IDE, nor am I aware of any tooling that would
> allow us to check the formatting using lets say a commit hook or maven
> plugin. So the common approach we use at the moment is to push and afterwards
> pull nodes to or from the remote repository.
> To improve that, only formatting the local files with the format the export
> uses is much more efficient and can also be automated.
> This is a proposal to introduce a _format_ command for the vlt-cli that:
> * accepts a list of file patterns that should be processed in the current
> directory tree
> * formats each file included by the patterns or
> * checks if the file is in the right format and fails if not with a list of
> all malformed files
> This can then be used to:
> * automatically format by cli invocation
> * validate the format during build or as pre commit hook
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-271) Support a CLI command to format vault xml files
[
https://issues.apache.org/jira/browse/JCRVLT-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368293#comment-16368293
]
Dirk Rudolph commented on JCRVLT-271:
-
Thank you for those information [~tripod]. With those I also added the
capability of sorting the attributes according to the format implied in the
DocViewSAXFormatter.
I moved the logic from the vault-cli to vault-core to not require consumers
(like IDE plugins) to depend on the vault-cli artefact. Additionally I moved
the logic of the attribute name sorting in AttributeNameComparator and used it
in the ItemNameComparator. The Comparator can now be set to the OutputFormat so
that the DocViewSerializer has exactly the same format as the methods for
formatting of the new DocViewFormat singleton. There is one thing I'm not sure
if it makes sense to be changed. The javadoc of XMLSerializer says:
{quote}
This class and dependencies were copied from the sun jdk1.5 source base. The
original serializer is extended by a new OutputFormat setting that allows to
break the line for each attribute. additionally, *all attribute names are
sorted alphabetically*.
{quote}
which wasn't true, as until now there was no sorting of the attributes at all
in this class. Maybe we should rephrase or remove that.
> Support a CLI command to format vault xml files
> ---
>
> Key: JCRVLT-271
> URL: https://issues.apache.org/jira/browse/JCRVLT-271
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Misc
>Reporter: Dirk Rudolph
>Priority: Major
>
> In our projects we work with vlt IDE integrations (Intellij and Eclpise) to
> have an easy and feature rich development process. On the other hand there
> are situations where we are writing vlt xml files manually. To not have huge
> diffs of formatting changes we tend to commit those vlt xml files formatted
> in the way as they are produced by exporting the corresponding nodes from a
> remote repository.
> Unfortunately the format can not fully be achieved by formatting using the
> build in xml formatters of the IDE, nor am I aware of any tooling that would
> allow us to check the formatting using lets say a commit hook or maven
> plugin. So the common approach we use at the moment is to push and afterwards
> pull nodes to or from the remote repository.
> To improve that, only formatting the local files with the format the export
> uses is much more efficient and can also be automated.
> This is a proposal to introduce a _format_ command for the vlt-cli that:
> * accepts a list of file patterns that should be processed in the current
> directory tree
> * formats each file included by the patterns or
> * checks if the file is in the right format and fails if not with a list of
> all malformed files
> This can then be used to:
> * automatically format by cli invocation
> * validate the format during build or as pre commit hook
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16368188#comment-16368188
]
Konrad Windszus commented on JCRVLT-274:
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/12
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-274:
---
Status: Patch Available (was: Open)
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16367490#comment-16367490
]
Konrad Windszus edited comment on JCRVLT-274 at 2/17/18 11:08 AM:
--
To make it more consistent and flexible the same approach should be applied to
{{classifier}}.
was (Author: kwin):
To make it more consistent and flexible the same approach should be applied to
{{scope}} and {{classifier}}.
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
