[jira] [Closed] (JCRVLT-717) Update dependencies

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed JCRVLT-717.
--

> Update dependencies
> ---
>
> Key: JCRVLT-717
> URL: https://issues.apache.org/jira/browse/JCRVLT-717
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.6
>
>
> Several dependencies should be updated:
> # plexus-util 3.4.2 -> 4.0.0
> # maven-archiver 3.6.1 -> 3.6.1
> # plexus-archiver 4.4.0 -> 4.8.0
> # biz.aQute.bndlib 6.2.0 -> 6.4.0
> # maven-common-artifact-filters 3.3.0 -> 3.3.2
> # maven-filtering 3.3.0 -> 3.3.1
> # maven-shared-util 3.3.4 -> 3.4.2
> # animal-sniffer 1.21 -> 1.23



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (JCRVLT-723) validate-packages must only validate artifacts of type "content-package"

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed JCRVLT-723.
--

> validate-packages must only validate artifacts of type "content-package"
> 
>
> Key: JCRVLT-723
> URL: https://issues.apache.org/jira/browse/JCRVLT-723
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.3.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.6
>
>
> Otherwise you might run into issues like
>  
> {{[ERROR] Failed to execute goal 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.2:validate-package 
> (validate-package-cloud) on project acs-aem-commons-all: Could not validate 
> package 
> '/Users/davidg/Code/acs-aem-commons/target/checkout/all/target/acs-aem-commons-all-6.3.0-cloud.zip.asc':
>  zip END header not found -> [Help 1]}}
> (https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/3149#issuecomment-1779897403).
> Currently only classifier is checked but not type/extension.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (JCRVLT-715) Content Package with classifier potentially installed/deployed with wrong extension

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed JCRVLT-715.
--

> Content Package with classifier potentially installed/deployed with wrong 
> extension
> ---
>
> Key: JCRVLT-715
> URL: https://issues.apache.org/jira/browse/JCRVLT-715
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.6
>
>
> The "package" goal attaches the content package as secondary artifact when a 
> classifier is used 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/58a395fdbfccbecb772be2cec2b9e347d34d0d0f/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/mojo/VaultMojo.java#L568).
>  This uses the type of the underlying Maven project (which may be different 
> from content-package/zip), so you might end up with content packages with the 
> wrong extension in the local/remote repo.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (JCRVLT-713) filevault-package-maven-plugin wrongly reports duplicate files for same path

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed JCRVLT-713.
--

> filevault-package-maven-plugin wrongly reports duplicate files for same path
> 
>
> Key: JCRVLT-713
> URL: https://issues.apache.org/jira/browse/JCRVLT-713
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Reporter: Roy Teeuwen
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.6
>
>
> I have the following setup:
>  * a maven plugin generates css files from scss files in the 
> src/main/content/jcr_root folder, add's them to target/vault-work/jcr_root/...
>  * maven resources plugin adds all the other files that are in the 
> src/main/content/jcr_root to the target/vault-work/jcr_root
>  * filevault-package-maven-plugin creates the package, with as settings 
> jcrRootSourceDirectory = 
> ${project.build.directory}/vault-work/jcr_root
> When doing this, the filevault plugin throws errors on duplicate files, for 
> example:
> {code:java}
> Found duplicate file 'jcr_root/apps/author/websites/general/css/_header.scss' 
> from sources 
> 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss' 
> and 
> 'target/vault-work/jcr_root/apps/author/websites/general/css/_header.scss'{code}
>  
> As you can see, this is two times the same path.
> I'm not sure if this is fixable through different plugin configuration? I can 
> make a PR that checks if both paths are the same before logging as duplicate 
> file, but that just sounds like a workaround instead of a correct fix
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (JCRVLT-732) Use FileVault 3.7.2

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus closed JCRVLT-732.
--

> Use FileVault 3.7.2
> ---
>
> Key: JCRVLT-732
> URL: https://issues.apache.org/jira/browse/JCRVLT-732
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.6
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-733:
--

 Summary: Allow to enforce ancestor primary and mixin type
 Key: JCRVLT-733
 URL: https://issues.apache.org/jira/browse/JCRVLT-733
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Reporter: Konrad Windszus


Currently it is impossible to enforce a type for an uncovered ancestor node: 
https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
Existing nodes are never touched, and therefore might have an incompatible type 
which prevent the actual child node installation.

The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
which override the full ancestor node (but not arbitrary children). This might 
also destroy other properties though (apart from types).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-733:
---
Description: 
Currently it is impossible to enforce a type for an uncovered ancestor node: 
https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
Existing nodes are never touched, and therefore might have an incompatible type 
which prevent the actual child node installation.

The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
which override the full ancestor node (but not arbitrary children). This might 
also destroy other properties though (apart from types).

This is necessary whenever two packages might contribute to subtrees sharing a 
common ancestor. There is often no dependent package which just provides the 
common ancestor (as that would also overwrite the full subtree).

  was:
Currently it is impossible to enforce a type for an uncovered ancestor node: 
https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
Existing nodes are never touched, and therefore might have an incompatible type 
which prevent the actual child node installation.

The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
which override the full ancestor node (but not arbitrary children). This might 
also destroy other properties though (apart from types).


> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788724#comment-17788724
 ] 

Konrad Windszus commented on JCRVLT-733:


One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788724#comment-17788724
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/22/23 11:14 AM:
---

One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.
For example with an additional child element called {{ancestorTypes}} with 
comma-separated text values specifying the types. Additional attributes could 
be used to restrict where those types should be enforced like {{levelStart}} 
and {{levelEnd}} and maybe an additional boolean flag {{lenient}} which 
determines what should happen in case the type cannot be enforced (due to 
existing incompatible properties/child nodes).


was (Author: kwin):
One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788724#comment-17788724
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/22/23 11:17 AM:
---

One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.
For example with an additional child element called {{ancestorTypes}} with 
comma-separated text values specifying the types. Additional attributes could 
be used to restrict where those types should be enforced like {{levelStart}} 
and {{levelEnd}} and maybe an additional boolean flag {{lenient}} which 
determines what should happen in case the type cannot be enforced (due to 
existing incompatible properties/child nodes). Example filter.xml

{code}

  sling:Folder

{code}


was (Author: kwin):
One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.
For example with an additional child element called {{ancestorTypes}} with 
comma-separated text values specifying the types. Additional attributes could 
be used to restrict where those types should be enforced like {{levelStart}} 
and {{levelEnd}} and maybe an additional boolean flag {{lenient}} which 
determines what should happen in case the type cannot be enforced (due to 
existing incompatible properties/child nodes). Example filter.xml

{code}
 
   sling:Folder

{code}

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788724#comment-17788724
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/22/23 11:17 AM:
---

One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.
For example with an additional child element called {{ancestorTypes}} with 
comma-separated text values specifying the types. Additional attributes could 
be used to restrict where those types should be enforced like {{levelStart}} 
and {{levelEnd}} and maybe an additional boolean flag {{lenient}} which 
determines what should happen in case the type cannot be enforced (due to 
existing incompatible properties/child nodes). Example filter.xml

{code}
 
   sling:Folder

{code}


was (Author: kwin):
One possibility is to combine that with the node types used for validation 
outlined at JCRVLT-619. Another one is to extend the filter.xml to allow the 
enforcement of ancestor node types there.
For example with an additional child element called {{ancestorTypes}} with 
comma-separated text values specifying the types. Additional attributes could 
be used to restrict where those types should be enforced like {{levelStart}} 
and {{levelEnd}} and maybe an additional boolean flag {{lenient}} which 
determines what should happen in case the type cannot be enforced (due to 
existing incompatible properties/child nodes).

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789471#comment-17789471
 ] 

Konrad Windszus commented on JCRVLT-733:


Another possibility is to separate that info a dedicated properties file where 
each line consists of
{code}
=type{,}
{code}
This can be referenced from the general package properties and should be part 
of the package metadata.
The same format can then be used for validation during build time.

During installation the following options may be set
# IGNORE (don't consider info at all)
# VALIDATE (just make sure the existing ancestor nodes comply with the given 
node types)
# CREATE (create the ancestor nodes with given types but don't touch existing 
ones)
# CREATEORUPDATE (create or update the ancestor nodes with given types)



> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-734) Introduce PackageRegistryMBean

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-734:
--

 Summary: Introduce PackageRegistryMBean
 Key: JCRVLT-734
 URL: https://issues.apache.org/jira/browse/JCRVLT-734
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Reporter: Konrad Windszus


Similar to {{PackageManagerMBean}} there should be an MBean per package 
registry exposing the same statistics.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned JCRVLT-733:
--

Assignee: Konrad Windszus

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789549#comment-17789549
 ] 

Konrad Windszus commented on JCRVLT-733:


Although the proposed format outlined above for a properties file containing 
type information for certain paths works well for validation purposes, it 
shouldn't be necessary to use that within content packages. Instead content 
packages should only consider a new import option for uncovered ancestors (with 
CREATE being the default). The actual types should still be in DocView XML 
files (containing only the properties for {{jcr:primaryType}} and 
{{{}jcr:mixinTypes{}}}).

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789549#comment-17789549
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/25/23 10:51 AM:
---

Although the proposed format outlined above for a properties file containing 
type information for certain paths works well for validation purposes, it 
shouldn't be necessary to use that within content packages. Instead content 
packages should only consider a new import option for uncovered ancestors (with 
CREATE being the default). The actual types should still be in DocView XML 
files (where only the properties for {{jcr:primaryType}} and {{jcr:mixinTypes}} 
are considered).


was (Author: kwin):
Although the proposed format outlined above for a properties file containing 
type information for certain paths works well for validation purposes, it 
shouldn't be necessary to use that within content packages. Instead content 
packages should only consider a new import option for uncovered ancestors (with 
CREATE being the default). The actual types should still be in DocView XML 
files (containing only the properties for {{jcr:primaryType}} and 
{{{}jcr:mixinTypes{}}}).

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789471#comment-17789471
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/25/23 6:24 PM:
--

Another possibility is to separate that info a dedicated properties file where 
each line consists of
{code:java}
=type{,}
{code}
This can be referenced from the general package properties and should be part 
of the package metadata.
The same format can then be used for validation during build time.

During installation the following options may be set
 # IGNORE (don't consider info at all)
 # VALIDATE (just make sure the existing ancestor nodes comply with the given 
node types)
 # CREATE (create the ancestor nodes with given types but don't touch existing 
ones)
 # CREATEWITHPROPERTIES (create the ancestor nodes with all properties, but 
don't touch existing ones)
 # CREATEORUPDATE (create or update the ancestor nodes with given types)


was (Author: kwin):
Another possibility is to separate that info a dedicated properties file where 
each line consists of
{code}
=type{,}
{code}
This can be referenced from the general package properties and should be part 
of the package metadata.
The same format can then be used for validation during build time.

During installation the following options may be set
# IGNORE (don't consider info at all)
# VALIDATE (just make sure the existing ancestor nodes comply with the given 
node types)
# CREATE (create the ancestor nodes with given types but don't touch existing 
ones)
# CREATEORUPDATE (create or update the ancestor nodes with given types)



> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-733) Allow to enforce ancestor primary and mixin type

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789549#comment-17789549
 ] 

Konrad Windszus edited comment on JCRVLT-733 at 11/25/23 6:25 PM:
--

Although the proposed format outlined above for a properties file containing 
type information for certain paths works well for validation purposes, it 
shouldn't be necessary to use that within content packages. Instead content 
packages should only consider a new import option for uncovered ancestors (with 
CREATEWITHPROPERTIES being the default). The actual types should still be in 
DocView XML files (where only the properties for {{jcr:primaryType}} and 
{{jcr:mixinTypes}} are considered).


was (Author: kwin):
Although the proposed format outlined above for a properties file containing 
type information for certain paths works well for validation purposes, it 
shouldn't be necessary to use that within content packages. Instead content 
packages should only consider a new import option for uncovered ancestors (with 
CREATE being the default). The actual types should still be in DocView XML 
files (where only the properties for {{jcr:primaryType}} and {{jcr:mixinTypes}} 
are considered).

> Allow to enforce ancestor primary and mixin type
> 
>
> Key: JCRVLT-733
> URL: https://issues.apache.org/jira/browse/JCRVLT-733
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is impossible to enforce a type for an uncovered ancestor node: 
> https://jackrabbit.apache.org/filevault/filter.html#Uncovered_ancestor_nodes.
> Existing nodes are never touched, and therefore might have an incompatible 
> type which prevent the actual child node installation.
> The workaround outlined e.g. at JCRVLT-403 is to leverage include patterns 
> which override the full ancestor node (but not arbitrary children). This 
> might also destroy other properties though (apart from types).
> This is necessary whenever two packages might contribute to subtrees sharing 
> a common ancestor. There is often no dependent package which just provides 
> the common ancestor (as that would also overwrite the full subtree).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-735) Clarify null return values on JcrPackage

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-735:
--

 Summary: Clarify null return values on JcrPackage
 Key: JCRVLT-735
 URL: https://issues.apache.org/jira/browse/JCRVLT-735
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Reporter: Konrad Windszus


It is unclear from the javadoc under which circumstances either {{JcrPackage}}
# {{getDefinition()}}
# {{getDefNode()}}
# {{getNode()}}
may return {{null}}





--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-735) Clarify null return values on JcrPackage

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-735:
---
Description: 
It is unclear from the javadoc under which circumstances either {{JcrPackage}}
# {{getDefinition()}}
# {{getDefNode()}} or
# {{getNode()}}

may return {{null}}



  was:
It is unclear from the javadoc under which circumstances either {{JcrPackage}}
# {{getDefinition()}}
# {{getDefNode()}}
# {{getNode()}}
may return {{null}}




> Clarify null return values on JcrPackage
> 
>
> Key: JCRVLT-735
> URL: https://issues.apache.org/jira/browse/JCRVLT-735
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Konrad Windszus
>Priority: Major
>
> It is unclear from the javadoc under which circumstances either {{JcrPackage}}
> # {{getDefinition()}}
> # {{getDefNode()}} or
> # {{getNode()}}
> may return {{null}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-736) Allow to write validation CSV files without breaking the build

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-736:
--

 Summary: Allow to write validation CSV files without breaking the 
build
 Key: JCRVLT-736
 URL: https://issues.apache.org/jira/browse/JCRVLT-736
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: package maven plugin
Reporter: Konrad Windszus


In order to create all validation issues in separate CSV files for a reactor 
build one needs to tweak the severity of issues currently. It would be 
beneficial to have an option to not fail the build in case CSV reports are 
being generated in order to built all reports of all modules in one go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-737) Parent node not found when installing a package

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794329#comment-17794329
 ] 

Konrad Windszus commented on JCRVLT-737:


Which ID conflict policy has been used 
(https://jackrabbit.apache.org/filevault/referenceablenodes.html)?

> Parent node not found when installing a package
> ---
>
> Key: JCRVLT-737
> URL: https://issues.apache.org/jira/browse/JCRVLT-737
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.7.2
>Reporter: Timothee Maret
>Priority: Major
>
> When importing a resource that already exists at with the same jcr:uuid but 
> at a different path, the importer balks with :
>  
> {code:java}
> Caused by: javax.jcr.RepositoryException: Some errors occurred while 
> installing packages. Please check the logs for details. First exception is 
> logged as cause.
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:579) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:151)
>  [org.apache.sling.distribution.core:0.6.0.T202209271257-98a9dd5]
>   ... 11 common frames omitted
> Caused by: org.apache.jackrabbit.vault.packaging.PackageException: Error 
> creating/updating node 
> /content/dam/cgc/tenants/apac/documents/unitholder-letter/pds-cgnpau-12012023(au).pdf/jcr:content
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1177) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 12 common frames omitted
> Caused by: java.lang.IllegalStateException: Parent node not found.
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1103) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 23 common frames omitted  {code}
> After removing the resource from the target repository, re-applying the 
> package will succeed.
>  
> Configuration of the importer:
> {code:java}
> aclHandling :"MERGE_PRESERVE"
> cugHandling :"OVERWRITE"
> importMode: "REPLACE"
> autoSaveThreshold: 1000 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-737) Parent node not found when installing a package

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795285#comment-17795285
 ] 

Konrad Windszus commented on JCRVLT-737:


[~marett] Is that a regression (did it work in older versions)? Can you come up 
with a test case?

> Parent node not found when installing a package
> ---
>
> Key: JCRVLT-737
> URL: https://issues.apache.org/jira/browse/JCRVLT-737
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.7.2
>Reporter: Timothee Maret
>Priority: Major
>
> When importing a resource that already exists at with the same jcr:uuid but 
> at a different path, the importer balks with :
>  
> {code:java}
> Caused by: javax.jcr.RepositoryException: Some errors occurred while 
> installing packages. Please check the logs for details. First exception is 
> logged as cause.
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:579) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:151)
>  [org.apache.sling.distribution.core:0.6.0.T202209271257-98a9dd5]
>   ... 11 common frames omitted
> Caused by: org.apache.jackrabbit.vault.packaging.PackageException: Error 
> creating/updating node 
> /content/dam/cgc/tenants/apac/documents/unitholder-letter/pds-cgnpau-12012023(au).pdf/jcr:content
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1177) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 12 common frames omitted
> Caused by: java.lang.IllegalStateException: Parent node not found.
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1103) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 23 common frames omitted  {code}
> After removing the resource from the target repository, re-applying the 
> package will succeed.
>  
> Configuration of the importer:
> {code:java}
> aclHandling :"MERGE_PRESERVE"
> cugHandling :"OVERWRITE"
> importMode: "REPLACE"
> autoSaveThreshold: 1000 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-737) Parent node not found when installing a package

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795285#comment-17795285
 ] 

Konrad Windszus edited comment on JCRVLT-737 at 12/11/23 10:54 AM:
---

[~marett] Is that a regression (did it work in older versions)? Can you come up 
with a test case? It is important to know where the conflicting UUID node is 
located as there is different behaviour if they share the same parent or not: 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html#LEGACY.


was (Author: kwin):
[~marett] Is that a regression (did it work in older versions)? Can you come up 
with a test case?

> Parent node not found when installing a package
> ---
>
> Key: JCRVLT-737
> URL: https://issues.apache.org/jira/browse/JCRVLT-737
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.7.2
>Reporter: Timothee Maret
>Priority: Major
>
> When importing a resource that already exists at with the same jcr:uuid but 
> at a different path, the importer balks with :
>  
> {code:java}
> Caused by: javax.jcr.RepositoryException: Some errors occurred while 
> installing packages. Please check the logs for details. First exception is 
> logged as cause.
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:579) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:151)
>  [org.apache.sling.distribution.core:0.6.0.T202209271257-98a9dd5]
>   ... 11 common frames omitted
> Caused by: org.apache.jackrabbit.vault.packaging.PackageException: Error 
> creating/updating node 
> /content/dam/cgc/tenants/apac/documents/unitholder-letter/pds-cgnpau-12012023(au).pdf/jcr:content
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1177) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 12 common frames omitted
> Caused by: java.lang.IllegalStateException: Parent node not found.
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1103) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 23 common frames omitted  {code}
> After removing the resource from the target repository, re-applying the 
> package will succeed.
>  
> Configuration of the importer:
> {code:java}
> aclHandling :"MERGE_PRESERVE"
> cugHandling :"OVERWRITE"
> importMode: "REPLACE"
> autoSaveThreshold: 1000 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795468#comment-17795468
 ] 

Konrad Windszus commented on JCR-4979:
--

Steps 1-3. have been done now by ASF INFRA.

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795468#comment-17795468
 ] 

Konrad Windszus edited comment on JCR-4979 at 12/11/23 6:03 PM:


Steps 1-3. have been done now by ASF INFRA.
Jenkins Jobs adjusted now (Step 6)


was (Author: kwin):
Steps 1-3. have been done now by ASF INFRA.

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-4979:
-
Description: 
In order to foster contribution and ease switching between 
branches/cherrypicking and in general to have a modern development workflow I 
propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).

It would comprise of the following steps:
 # migrate the SVN repository at 
[https://svn.apache.org/repos/asf/jackrabbit/branches], 
[https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
[https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
"jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
INFRA-25150)
 # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
 # make the SVN repository at the folders outlined at 1. read only (tracked in 
INFRA-25150)
 # adjust documentation, see attached patch
 ## 
 ## 
 # adjust check script
 # adjust Jenkins Jobs 
[https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
[https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
 # adjust pom.xml

VOTE thread in 
[https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]

  was:
In order to foster contribution and ease switching between 
branches/cherrypicking and in general to have a modern development workflow I 
propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).

It would comprise of the following steps:
 # migrate the SVN repository at 
[https://svn.apache.org/repos/asf/jackrabbit/branches], 
[https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
[https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
"jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
INFRA-25150)
 # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
 # make the SVN repository at the folders outlined at 1. read only (tracked in 
INFRA-25150)
 # adjust documentation, see attached patch
 ## 
 ## 
 # adjust check script
 # adjust Jenkins Jobs 
[https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
[https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]

VOTE thread in 
[https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]


> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795468#comment-17795468
 ] 

Konrad Windszus edited comment on JCR-4979 at 12/11/23 6:54 PM:


Steps 1-3. have been done now by ASF INFRA.
Jenkins Jobs adjusted now (Step 6).
Applied slightly adjusted patch for site in 
https://svn.apache.org/viewvc?view=revision&revision=1914542 (Step 6)


was (Author: kwin):
Steps 1-3. have been done now by ASF INFRA.
Jenkins Jobs adjusted now (Step 6)

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-4979:
-
Attachment: JCR4979-v1-check-release.sh.patch

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795494#comment-17795494
 ] 

Konrad Windszus commented on JCR-4979:
--

[~reschke] Any idea why  [^JCR4979-v1-check-release.sh.patch] cannot 
successfully check the RC of 2.21.21.  That fails for me with 

{{[ERROR]   NOT OK: Tagged sources are different from those in the archive}}. 

{code}
[INFO]Unzipping jackrabbit-2.21.21-src.zip...
[INFO]Comparing sources...
[INFO] 
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core:
 jmx
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query:
 pdf
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/stats:
 util
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/persistence:
 pool
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/test:
 resources
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit:
 jcr2spi
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-webdav/src/test/java/org/apache/jackrabbit/webdav:
 client
[ERROR]   NOT OK: Tagged sources are different from those in the archive
{code}

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795494#comment-17795494
 ] 

Konrad Windszus edited comment on JCR-4979 at 12/11/23 7:29 PM:


[~reschke] Any idea why  [^JCR4979-v1-check-release.sh.patch] cannot 
successfully check the RC of 2.21.21.  That fails for me with 

{{[ERROR]   NOT OK: Tagged sources are different from those in the archive}}. 

{code}
[INFO]Unzipping jackrabbit-2.21.21-src.zip...
[INFO]Comparing sources...
[INFO] 
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core:
 jmx
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query:
 pdf
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/stats:
 util
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/persistence:
 pool
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/test:
 resources
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit:
 jcr2spi
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-webdav/src/test/java/org/apache/jackrabbit/webdav:
 client
[ERROR]   NOT OK: Tagged sources are different from those in the archive
{code}

Update: Seems to be due to empty directories which do no longer exist with Git. 
Should not be a problem if the upcoming release is triggered from Git.


was (Author: kwin):
[~reschke] Any idea why  [^JCR4979-v1-check-release.sh.patch] cannot 
successfully check the RC of 2.21.21.  That fails for me with 

{{[ERROR]   NOT OK: Tagged sources are different from those in the archive}}. 

{code}
[INFO]Unzipping jackrabbit-2.21.21-src.zip...
[INFO]Comparing sources...
[INFO] 
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core:
 jmx
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query:
 pdf
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/stats:
 util
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/persistence:
 pool
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-commons/src/test:
 resources
diff -b -r 
./target/jackrabbit-2.21.21/scm/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-jcr-tests/src/main/java/org/apache/jackrabbit/test/XMLChar.java
46c46
<  * @version $Id$
---
>  * @version $Id: XMLChar.java 1910276 2023-06-07 11:15:10Z reschke $
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit:
 jcr2spi
Only in 
./target/jackrabbit-2.21.21/zip/jackrabbit-2.21.21/jackrabbit-webdav/src/test/java/org/apache/jackrabbit/webdav:
 client
[ERROR]   NOT OK: Tagged sources are different from those in the archive
{code}

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease sw

[jira] [Comment Edited] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795468#comment-17795468
 ] 

Konrad Windszus edited comment on JCR-4979 at 12/12/23 10:30 AM:
-

Steps 1-3. have been done now by ASF INFRA.
Jenkins Jobs adjusted now (Step 6).
Applied slightly adjusted patch for site in 
https://svn.apache.org/viewvc?view=revision&revision=1914542 (Step 4)


was (Author: kwin):
Steps 1-3. have been done now by ASF INFRA.
Jenkins Jobs adjusted now (Step 6).
Applied slightly adjusted patch for site in 
https://svn.apache.org/viewvc?view=revision&revision=1914542 (Step 6)

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795736#comment-17795736
 ] 

Konrad Windszus commented on JCR-4979:
--

[~reschke] If you could approve the changes for the check-release.sh that would 
be appreciated.

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795745#comment-17795745
 ] 

Konrad Windszus commented on JCR-4979:
--

POMs adjusted in 
https://github.com/apache/jackrabbit/commit/ef12034a7c935a9bf2a61cc5411ac9d2726262ee
 (step 7).

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCR-4979.
--
Fix Version/s: 2.21.22
   Resolution: Fixed

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.21.22
>
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795821#comment-17795821
 ] 

Konrad Windszus commented on JCR-4979:
--

Check script adjusted in https://dist.apache.org/repos/dist/dev/jackrabbit/, in 
r66008 (step 5).

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4979) Migrate from Subversion to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798955#comment-17798955
 ] 

Konrad Windszus commented on JCR-4979:
--

For the maven release process (i.e. pushing to the right repository during 
release:perform, 
https://maven.apache.org/maven-release/maven-release-plugin/usage/prepare-release.html)
 the one in the root pom.xml is enough.
The effective pom.xml of the individual modules do no longer have the scm 
elements (which is sometimes exposed by Mvn Search UIs like 
https://mvnrepository.com/ or search.maven.org). Therefore I would recommend to 
instead choose an approach like FileVault where the parent is even parent of 
the root pom.xml itself, and the scm info is exclusively maintained in the 
parent pom.xml. WDYT?

> Migrate from Subversion to Git
> --
>
> Key: JCR-4979
> URL: https://issues.apache.org/jira/browse/JCR-4979
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: candidate_jackrabbit_2_20
> Fix For: 2.22, 2.21.22
>
> Attachments: JCR-4979-site-v1.patch, JCR4979-v1-check-release.sh.patch
>
>
> In order to foster contribution and ease switching between 
> branches/cherrypicking and in general to have a modern development workflow I 
> propose to migrate Jackrabbit (Classic) from SVN to Git similarly to what was 
> done in Oak (https://issues.apache.org/jira/browse/OAK-9440) and Jackrabbit 
> FileVault (https://issues.apache.org/jira/browse/JCRVLT-398).
> It would comprise of the following steps:
>  # migrate the SVN repository at 
> [https://svn.apache.org/repos/asf/jackrabbit/branches], 
> [https://svn.apache.org/repos/asf/jackrabbit/trunk] and 
> [https://svn.apache.org/repos/asf/jackrabbit/tags] to a Git repository named 
> "jackrabbit" (hosted at [https://gitbox.apache.org/repos/asf]) (tracked in 
> INFRA-25150)
>  # migrate GitHub SVN mirror at [https://github.com/apache/jackrabbit] to 
> mirror the new native Git repo (at Gitbox) (tracked in INFRA-25150)
>  # make the SVN repository at the folders outlined at 1. read only (tracked 
> in INFRA-25150)
>  # adjust documentation, see attached patch
>  ## 
>  ## 
>  # adjust check script
>  # adjust Jenkins Jobs 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk] and 
> [https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-2.20/]
>  # adjust pom.xml
> VOTE thread in 
> [https://lists.apache.org/thread/2owqqjhk4wo9gk9jo7o02x73b2kfz7nj]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-4935) session.exportDocumentView() generates unparsable XML if a JCR Property contains invalid XML character

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17799136#comment-17799136
 ] 

Konrad Windszus commented on JCR-4935:
--

With XML 1.1 most limitations to invalid characters were lifted: 
https://www.w3.org/TR/xml11/#sec-xml11. Not sure if the JCR spec explicitly 
specifies an XML spec version...

> session.exportDocumentView() generates unparsable XML if a JCR Property 
> contains invalid XML character
> --
>
> Key: JCR-4935
> URL: https://issues.apache.org/jira/browse/JCR-4935
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.21.18
>Reporter: Yegor Kozlov
>Assignee: Julian Reschke
>Priority: Major
> Attachments: image-2023-05-29-14-58-05-591.png
>
>
> I came across this issue in AEM, where user content can contain all kinds of 
> special characters. In my case it was a 0x3 character (^C) in a node property 
> which was written in the JCR XML as-is, and it resulted in a unparsable 
> output. 
> !image-2023-05-29-14-58-05-591.png|width=968,height=305!
> IMO control characters, non-characters and out-of-unicode-range characters 
> should be skipped when writing XML. These can come from user data and can act 
> as a "poison pill" breaking the export/import functionality. 
>  
> The PR is coming.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

Konrad Windszus created JCR-5011:


 Summary: Restore SCM information in parent POM
 Key: JCR-5011
 URL: https://issues.apache.org/jira/browse/JCR-5011
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Reporter: Konrad Windszus
 Fix For: 2.22, 2.21.23


In JCR-4979 the SCM information was removed from the parent and only maintained 
in the reactor root. Although this is enough for releasing the effective POMs 
of the individual submodules now lack this metainformation (which is exposed 
e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803332#comment-17803332
 ] 

Konrad Windszus commented on JCR-5011:
--

Fixed for 2.22 in 
https://github.com/apache/jackrabbit/commit/79ff0db6ce42253041b652f84f2034c8e977.

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned JCR-5011:


Assignee: Konrad Windszus

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCR-5011.
--
Resolution: Fixed

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803332#comment-17803332
 ] 

Konrad Windszus edited comment on JCR-5011 at 1/4/24 9:30 PM:
--

Fixed for 2.22 in 
https://github.com/apache/jackrabbit/commit/79ff0db6ce42253041b652f84f2034c8e977.
Fixed for 2.21.4 in 
https://github.com/apache/jackrabbit/commit/4e56b0ffb0f8390df9fed2a982611b9fd74e3113.


was (Author: kwin):
Fixed for 2.22 in 
https://github.com/apache/jackrabbit/commit/79ff0db6ce42253041b652f84f2034c8e977.

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-5011:
-
Issue Type: Improvement  (was: Bug)

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCR-5011) Restore SCM information in parent POM

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCR-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCR-5011:
-
Fix Version/s: 2.20.14

> Restore SCM information in parent POM
> -
>
> Key: JCR-5011
> URL: https://issues.apache.org/jira/browse/JCR-5011
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.22, 2.20.14, 2.21.23
>
>
> In JCR-4979 the SCM information was removed from the parent and only 
> maintained in the reactor root. Although this is enough for releasing the 
> effective POMs of the individual submodules now lack this metainformation 
> (which is exposed e.g. in https://search.maven.org/).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-737) Parent node not found when installing a package

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805643#comment-17805643
 ] 

Konrad Windszus commented on JCRVLT-737:


Is this a regression? Something which is not documented in 
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html#LEGACY?
 I am not sure if we need a fix at all. Legacy is not a recommended policy.

> Parent node not found when installing a package
> ---
>
> Key: JCRVLT-737
> URL: https://issues.apache.org/jira/browse/JCRVLT-737
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: Packaging
>Affects Versions: 3.7.2
>Reporter: Timothee Maret
>Priority: Major
>
> When importing a resource that already exists at with the same jcr:uuid but 
> at a different path, the importer balks with :
>  
> {code:java}
> Caused by: javax.jcr.RepositoryException: Some errors occurred while 
> installing packages. Please check the logs for details. First exception is 
> logged as cause.
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:579) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:151)
>  [org.apache.sling.distribution.core:0.6.0.T202209271257-98a9dd5]
>   ... 11 common frames omitted
> Caused by: org.apache.jackrabbit.vault.packaging.PackageException: Error 
> creating/updating node 
> /content/dam/cgc/tenants/apac/documents/unitholder-letter/pds-cgnpau-12012023(au).pdf/jcr:content
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1177) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:976) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1018) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:531) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 12 common frames omitted
> Caused by: java.lang.IllegalStateException: Parent node not found.
>   at 
> org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:1103) 
> [org.apache.jackrabbit.vault:3.7.1.T20231005151103-335689a8]
>   ... 23 common frames omitted  {code}
> After removing the resource from the target repository, re-applying the 
> package will succeed.
>  
> Configuration of the importer:
> {code:java}
> aclHandling :"MERGE_PRESERVE"
> cugHandling :"OVERWRITE"
> importMode: "REPLACE"
> autoSaveThreshold: 1000 {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

Konrad Windszus created JCRSITE-55:
--

 Summary: Migrate to Git
 Key: JCRSITE-55
 URL: https://issues.apache.org/jira/browse/JCRSITE-55
 Project: Jackrabbit Site
  Issue Type: Improvement
Reporter: Konrad Windszus


The new repository https://github.com/apache/jackrabbit-site should be used 
instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
Publishing should work for the sub modules separately as outlined in 
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
 This affects:

# https://github.com/apache/jackrabbit-filevault -> 
https://jackrabbit.apache.org/filevault/
# https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
https://jackrabbit.apache.org/filevault-package-maven-plugin
# https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-741:
--

 Summary: Maven-Plugin: Publish site directly from Git repo
 Key: JCRVLT-741
 URL: https://issues.apache.org/jira/browse/JCRVLT-741
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Reporter: Konrad Windszus
Assignee: Konrad Windszus


As outlined in 
https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
 the website should be directly published from the Git repository instead of 
pushing to SVN first. This requires
- adjusting the 
[maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
 to publish to a branch of the source repository
- adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Moved] (JCRVLT-740) Publish site directly from Git repo

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus moved OAK-10602 to JCRVLT-740:
--

Component/s: (was: docs)
Key: JCRVLT-740  (was: OAK-10602)
   Workflow: no-reopen-closed, patch-avail  (was: no-reopen-closed)
Project: Jackrabbit FileVault  (was: Jackrabbit Oak)

> Publish site directly from Git repo
> ---
>
> Key: JCRVLT-740
> URL: https://issues.apache.org/jira/browse/JCRVLT-740
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806513#comment-17806513
 ] 

Konrad Windszus commented on JCRVLT-741:


The issue is that we feed two sibling subdirectories of jackrabbit.apache.org 
for the Maven plugin:

# https://jackrabbit.apache.org/filevault-package-maven-plugin-archives/
# https://jackrabbit.apache.org/filevault-package-maven-plugin/

This is currently not supported by subdirectory publishing. I raised 
https://issues.apache.org/jira/browse/INFRA-25379 for supporting this use case.

> Maven-Plugin: Publish site directly from Git repo
> -
>
> Key: JCRVLT-741
> URL: https://issues.apache.org/jira/browse/JCRVLT-741
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806518#comment-17806518
 ] 

Konrad Windszus commented on JCRVLT-741:


A potential workaround is switching to the following layout:

{code}
+ filevault-package-maven-plugin
+ /LATEST (being a link to the latest  sibling directory)
+ /
{code}

In addition redirects would need to be maintained for the old URLs (in the main 
Git repository https://github.com/apache/jackrabbit-site).
That way only the sub directory {{filevault-package-maven-plugin}} of the 
website would be fed from the Maven plugin's Git repository.

> Maven-Plugin: Publish site directly from Git repo
> -
>
> Key: JCRVLT-741
> URL: https://issues.apache.org/jira/browse/JCRVLT-741
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-742) Stop generating MD5 and SHA1 with Ant

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-742:
--

 Summary: Stop generating MD5 and SHA1 with Ant
 Key: JCRVLT-742
 URL: https://issues.apache.org/jira/browse/JCRVLT-742
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: package maven plugin
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Currently there is still manual generation of MD5, SHA1 and SHA512 checksum via 
Ant in 
https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
 and 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.

MD5 and SHA1 should no longer be provided according to 
https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 is 
automatically created through the ASF parent pom 
(https://maven.apache.org/pom/asf/#the-apache-release-profile).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-742:
---
Summary: Stop generating MD5, SHA1 and SHA512 with Ant  (was: Stop 
generating MD5 and SHA1 with Ant)

> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-742:
---
Description: 
Currently there is still manual generation of MD5, SHA1 and SHA512 checksum via 
Ant in 
https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
 and 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.

MD5 and SHA1 should no longer be provided according to 
https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 is 
automatically created through the ASF parent pom 
(https://maven.apache.org/pom/asf/#the-apache-release-profile).

In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the SHA512 
anyways.

Note: This is only about ASF dist not about the checksums used in Maven 
repositories which are transparently created by Maven Resolver.

  was:
Currently there is still manual generation of MD5, SHA1 and SHA512 checksum via 
Ant in 
https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
 and 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.

MD5 and SHA1 should no longer be provided according to 
https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 is 
automatically created through the ASF parent pom 
(https://maven.apache.org/pom/asf/#the-apache-release-profile).


> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).
> In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the 
> SHA512 anyways.
> Note: This is only about ASF dist not about the checksums used in Maven 
> repositories which are transparently created by Maven Resolver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810343#comment-17810343
 ] 

Konrad Windszus commented on JCRVLT-741:


The size of 
https://svn.apache.org/repos/asf/jackrabbit/site/live/filevault-package-maven-plugin-archives/
 (just the release version) is around 80 MB which would need to be cloned by 
everyone. Maybe using a dedicated repository for hosting the source of the 
website makes more sense, and probably keeping that in SVN is also reasonable...

> Maven-Plugin: Publish site directly from Git repo
> -
>
> Key: JCRVLT-741
> URL: https://issues.apache.org/jira/browse/JCRVLT-741
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810346#comment-17810346
 ] 

Konrad Windszus commented on JCRSITE-55:


Due to the size of website 
(https://svn.apache.org/repos/asf/jackrabbit/site/live) being almost 2GB it 
doesn't make sense to move that over to Git. OTOH 
https://svn.apache.org/repos/asf/jackrabbit/site/trunk (i.e. the source 
containing the markup and assets) from which the JR2 part of the website is 
built is just 120MB.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810346#comment-17810346
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 1/24/24 12:04 PM:
--

Due to the size of website 
(https://svn.apache.org/repos/asf/jackrabbit/site/live) being almost 2GB it 
doesn't make sense to move that over to Git. OTOH 
https://svn.apache.org/repos/asf/jackrabbit/site/trunk (i.e. the source 
containing the markup and assets) from which the JR2 part of the website is 
built is just 7MB.


was (Author: kwin):
Due to the size of website 
(https://svn.apache.org/repos/asf/jackrabbit/site/live) being almost 2GB it 
doesn't make sense to move that over to Git. OTOH 
https://svn.apache.org/repos/asf/jackrabbit/site/trunk (i.e. the source 
containing the markup and assets) from which the JR2 part of the website is 
built is just 120MB.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810343#comment-17810343
 ] 

Konrad Windszus edited comment on JCRVLT-741 at 1/24/24 12:11 PM:
--

The size of 
https://svn.apache.org/repos/asf/jackrabbit/site/live/filevault-package-maven-plugin-archives/
 (just the release version) is around 80 MB which would need to be cloned by 
everyone. Maybe using a dedicated repository for hosting the website makes more 
sense, and probably keeping that in SVN is also reasonable...


was (Author: kwin):
The size of 
https://svn.apache.org/repos/asf/jackrabbit/site/live/filevault-package-maven-plugin-archives/
 (just the release version) is around 80 MB which would need to be cloned by 
everyone. Maybe using a dedicated repository for hosting the source of the 
website makes more sense, and probably keeping that in SVN is also reasonable...

> Maven-Plugin: Publish site directly from Git repo
> -
>
> Key: JCRVLT-741
> URL: https://issues.apache.org/jira/browse/JCRVLT-741
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRVLT-741) Maven-Plugin: Publish site directly from Git repo

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRVLT-741.

Resolution: Won't Fix

> Maven-Plugin: Publish site directly from Git repo
> -
>
> Key: JCRVLT-741
> URL: https://issues.apache.org/jira/browse/JCRVLT-741
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRVLT-740) Publish site directly from Git repo

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRVLT-740.

Resolution: Won't Fix

This doesn't make sense: 
https://issues.apache.org/jira/browse/JCRSITE-55?focusedCommentId=17810346&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17810346

> Publish site directly from Git repo
> ---
>
> Key: JCRVLT-740
> URL: https://issues.apache.org/jira/browse/JCRVLT-740
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto
>  the website should be directly published from the Git repository instead of 
> pushing to SVN first. This requires
> - adjusting the 
> [maven-scm-publish-plugin|https://maven.apache.org/plugins/maven-scm-publish-plugin/]
>  to publish to a branch of the source repository
> - adjusting the .asf.yaml



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRSITE-55:
---
Attachment: authors.txt

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810372#comment-17810372
 ] 

Konrad Windszus commented on JCRSITE-55:


I created an authors.txt file from the SVN history and first name, last name 
and and email from https://whimsy.apache.org/roster/committee/:  
[^authors.txt] for mapping SVN author information to Git author information. 
Please cross-check.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810513#comment-17810513
 ] 

Konrad Windszus commented on JCRSITE-55:


Manually migrating with {{git-svn}} does not work as ASF uses one big 
repository for all projects. Don't know how to reasonably filter the revisions. 
Raised https://issues.apache.org/jira/browse/INFRA-25419 for that.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810513#comment-17810513
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 1/24/24 7:49 PM:
-

Manually migrating with {{git-svn}} does not work as ASF uses one big 
repository for all projects. Don't know how to reasonably filter the revisions. 
Raised https://issues.apache.org/jira/browse/INFRA-25419 for that.

Update: Was able to workaround that and imported the SVN via {{git fetch 
--log-window-size=1000 -r 1211903:HEAD}}. That way import finished within some 
minutes.


was (Author: kwin):
Manually migrating with {{git-svn}} does not work as ASF uses one big 
repository for all projects. Don't know how to reasonably filter the revisions. 
Raised https://issues.apache.org/jira/browse/INFRA-25419 for that.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810545#comment-17810545
 ] 

Konrad Windszus commented on JCRSITE-55:


Initial version now migrated to https://github.com/apache/jackrabbit-site.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810513#comment-17810513
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 1/24/24 7:54 PM:
-

Manually migrating with {{git-svn}} does not work as ASF uses one big 
repository for all projects. Don't know how to reasonably filter the revisions. 
Raised https://issues.apache.org/jira/browse/INFRA-25419 for that.

Update: Was able to workaround that and imported the SVN via {{git svn fetch 
--log-window-size=1000 -r 1211903:HEAD}}. That way import finished within some 
minutes.


was (Author: kwin):
Manually migrating with {{git-svn}} does not work as ASF uses one big 
repository for all projects. Don't know how to reasonably filter the revisions. 
Raised https://issues.apache.org/jira/browse/INFRA-25419 for that.

Update: Was able to workaround that and imported the SVN via {{git fetch 
--log-window-size=1000 -r 1211903:HEAD}}. That way import finished within some 
minutes.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813628#comment-17813628
 ] 

Konrad Windszus commented on JCRSITE-55:


I asked to put https://svn.apache.org/repos/asf/jackrabbit/site/trunk into 
read-only mode in https://issues.apache.org/jira/browse/INFRA-25452.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813665#comment-17813665
 ] 

Konrad Windszus commented on JCRSITE-55:


Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRSITE-55.

Resolution: Fixed

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813665#comment-17813665
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 2/2/24 4:54 PM:


Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

Update: Solved now.


was (Author: kwin):
Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRSITE-56) Do no longer expose the publish date

[Konrad Windszus (Jira)]

Konrad Windszus created JCRSITE-56:
--

 Summary: Do no longer expose the publish date
 Key: JCRSITE-56
 URL: https://issues.apache.org/jira/browse/JCRSITE-56
 Project: Jackrabbit Site
  Issue Type: Improvement
Reporter: Konrad Windszus


As recommended in https://infra.apache.org/project-site.html#generated we 
should no longer expose the publish date on each page as that
- changes with each publication
- does not reflect any content changes in most of the cases.

For now we should just not expose any date at all. In the future we can switch 
to exposing a last modified date (once that is available).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRSITE-56) Do no longer expose the publish date

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRSITE-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRSITE-56.

Resolution: Fixed

Fixed in 
https://github.com/apache/jackrabbit-site/commit/257808090eaa56ed62855f8bf9c5192651b882c6.

> Do no longer expose the publish date
> 
>
> Key: JCRSITE-56
> URL: https://issues.apache.org/jira/browse/JCRSITE-56
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> As recommended in https://infra.apache.org/project-site.html#generated we 
> should no longer expose the publish date on each page as that
> - changes with each publication
> - does not reflect any content changes in most of the cases.
> For now we should just not expose any date at all. In the future we can 
> switch to exposing a last modified date (once that is available).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813665#comment-17813665
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 2/8/24 8:49 AM:


Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

Update: Solved now.
Update2: Still now working correctly.


was (Author: kwin):
Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

Update: Solved now.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRSITE-55) Migrate to Git

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813665#comment-17813665
 ] 

Konrad Windszus edited comment on JCRSITE-55 at 2/8/24 8:49 AM:


Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

Update: Solved now.
Update2: Still not working correctly.


was (Author: kwin):
Automated build and deployment on ASF Jenkins 
(https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-site/job/main/) 
does not yet work due to missing credentials 
(https://issues.apache.org/jira/browse/INFRA-25453).

Update: Solved now.
Update2: Still now working correctly.

> Migrate to Git
> --
>
> Key: JCRSITE-55
> URL: https://issues.apache.org/jira/browse/JCRSITE-55
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: authors.txt
>
>
> The new repository https://github.com/apache/jackrabbit-site should be used 
> instead of https://svn.apache.org/repos/asf/jackrabbit/site/.
> Publishing should work for the sub modules separately as outlined in 
> https://cwiki.apache.org/confluence/pages/viewpage.action?spaceKey=INFRA&title=git+-+.asf.yaml+features#Git.asf.yamlfeatures-Specifyingasub-directorytopublishto.
>  This affects:
> # https://github.com/apache/jackrabbit-filevault -> 
> https://jackrabbit.apache.org/filevault/
> # https://github.com/apache/jackrabbit-filevault-package-maven-plugin -> 
> https://jackrabbit.apache.org/filevault-package-maven-plugin
> # https://github.com/apache/jackrabbit-oak/tree/trunk/oak-doc -> 
> https://jackrabbit.apache.org/oak/docs/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-742:
---
Fix Version/s: package-maven-plugin-1.3.8
   3.7.4

> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4, package-maven-plugin-1.3.8
>
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).
> In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the 
> SHA512 anyways.
> Note: This is only about ASF dist not about the checksums used in Maven 
> repositories which are transparently created by Maven Resolver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRVLT-742.

Resolution: Fixed

> Stop generating MD5, SHA1 and SHA512 with Ant
> -
>
> Key: JCRVLT-742
> URL: https://issues.apache.org/jira/browse/JCRVLT-742
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4, package-maven-plugin-1.3.8
>
>
> Currently there is still manual generation of MD5, SHA1 and SHA512 checksum 
> via Ant in 
> https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340
>  and 
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759.
> MD5 and SHA1 should no longer be provided according to 
> https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 
> is automatically created through the ASF parent pom 
> (https://maven.apache.org/pom/asf/#the-apache-release-profile).
> In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the 
> SHA512 anyways.
> Note: This is only about ASF dist not about the checksums used in Maven 
> repositories which are transparently created by Maven Resolver.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-744) Vaults do not handle multi workspace environments

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816441#comment-17816441
 ] 

Konrad Windszus commented on JCRVLT-744:


FileVault API is always bound to a JCR session which is always connected to 
exactly one workspace. By passing a Session bound to another workspace one can 
import/export from arbitrary workspaces already. 

I am not sure I get what exactly is missing here...
A content package conceptually can only contain serialized repository contents 
from exactly one workspace. Including the workspace name in the content package 
is possible, but not sure what should be done in case this content package is 
imported into a workspace with a different name. 

> Vaults do not handle multi workspace environments
> -
>
> Key: JCRVLT-744
> URL: https://issues.apache.org/jira/browse/JCRVLT-744
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Jochen
>Priority: Major
>
> The vault properties do not specify, for which workspace the package is.
> All the code implicitly assumes, that there is only one workspace.
> There should be a package property specifying the workspace.
> From a supplied session the switch to another workspace can be done via 
> session.getRepository().login(workspaceName)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-744) Vaults do not handle multi workspace environments

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816544#comment-17816544
 ] 

Konrad Windszus commented on JCRVLT-744:


I think the issue with the session is not only with 
{{JcrPackageManager.assemble()}} but probably also 
{{JcrPackageManager.extract(...)}} and most methods in {{JcrPackage}} (all 
currently just use the session of the package definition node which might be 
located in a different workspace). Not sure whether fixing the legacy 
JcrPackage/-Manager makes sense or whether just investing into JCRVLT-504 is 
more reasonable.

> Vaults do not handle multi workspace environments
> -
>
> Key: JCRVLT-744
> URL: https://issues.apache.org/jira/browse/JCRVLT-744
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Jochen
>Priority: Major
>
> The vault properties do not specify, for which workspace the package is.
> All the code implicitly assumes, that there is only one workspace.
> There should be a package property specifying the workspace.
> From a supplied session the switch to another workspace can be done via 
> session.getRepository().login(workspaceName)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-746) Exclude items are not added to WorkspaceFilter in RCP

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-746:
---
Fix Version/s: 3.7.4

> Exclude items are not added to WorkspaceFilter in RCP
> -
>
> Key: JCRVLT-746
> URL: https://issues.apache.org/jira/browse/JCRVLT-746
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: WalterSteiner
>Priority: Major
> Fix For: 3.7.4
>
>
> The excludes are not working ATM, see 
> [https://github.com/apache/jackrabbit-filevault/pull/332/files] for a simple 
> fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (JCRVLT-746) Exclude items are not added to WorkspaceFilter in RCP

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus resolved JCRVLT-746.

Resolution: Fixed

Fixed in 
https://github.com/apache/jackrabbit-filevault/commit/81fa88f1d7af07e77871e2c0bb03515107f18d74.

> Exclude items are not added to WorkspaceFilter in RCP
> -
>
> Key: JCRVLT-746
> URL: https://issues.apache.org/jira/browse/JCRVLT-746
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: WalterSteiner
>Priority: Major
> Fix For: 3.7.4
>
>
> The excludes are not working ATM, see 
> [https://github.com/apache/jackrabbit-filevault/pull/332/files] for a simple 
> fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-746) Exclude items are not added to WorkspaceFilter in RCP

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-746:
---
Component/s: RCP
 (was: vlt)

> Exclude items are not added to WorkspaceFilter in RCP
> -
>
> Key: JCRVLT-746
> URL: https://issues.apache.org/jira/browse/JCRVLT-746
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP
>Affects Versions: 3.7.2
>Reporter: WalterSteiner
>Priority: Major
> Fix For: 3.7.4
>
>
> The excludes are not working ATM, see 
> [https://github.com/apache/jackrabbit-filevault/pull/332/files] for a simple 
> fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (JCRVLT-746) Exclude items are not added to WorkspaceFilter in RCP

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus reassigned JCRVLT-746:
--

Assignee: Konrad Windszus

> Exclude items are not added to WorkspaceFilter in RCP
> -
>
> Key: JCRVLT-746
> URL: https://issues.apache.org/jira/browse/JCRVLT-746
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: RCP
>Affects Versions: 3.7.2
>Reporter: WalterSteiner
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.4
>
>
> The excludes are not working ATM, see 
> [https://github.com/apache/jackrabbit-filevault/pull/332/files] for a simple 
> fix.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-745) Stashing: naming and folder location

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817507#comment-17817507
 ] 

Konrad Windszus commented on JCRVLT-745:


I can't answer those questions. [~tripod] Do you remember?

> Stashing: naming and folder location
> 
>
> Key: JCRVLT-745
> URL: https://issues.apache.org/jira/browse/JCRVLT-745
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> We have seen cases where node stashing failed due to RuntimeExceptions (OOM 
> or MongoDB issues in Oak). In these cases, the tmp folder is not cleaned up. 
> If the operation is retried many times, there'll be many of these.
> Suggestion:
> 1. Do not use the root as default location,
> 2. Introduce an intermediary node that makes it clear that this is temp space 
> created by FileVault.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCR-5041) Javadoc build is broken

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827483#comment-17827483
 ] 

Konrad Windszus commented on JCR-5041:
--

Please use the short links introduced with JCR-4732. They seem to reference 
valid javadoc and spec.

> Javadoc build is broken
> ---
>
> Key: JCR-5041
> URL: https://issues.apache.org/jira/browse/JCR-5041
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: parent
>Reporter: Julian Reschke
>Priority: Blocker
>
> As 
>   https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0
> now fail with a 404. Apparently, this has started to fail in the last 48 
> hours.
> See
>   https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/277/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCR-5041) Javadoc build is broken

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCR-5041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827483#comment-17827483
 ] 

Konrad Windszus edited comment on JCR-5041 at 3/15/24 12:00 PM:


Please use the short links introduced with JCR-4732. They seem to reference 
valid javadoc and spec. The Adobe link seems to change from time to time and 
the short link allows us to change the target centrally (for website 
documentation and javadoc). Seems I missed 
https://github.com/apache/jackrabbit/blob/256869cae1564dab65dc35a663e34407b8fe/jackrabbit-parent/pom.xml#L224
 back then.


was (Author: kwin):
Please use the short links introduced with JCR-4732. They seem to reference 
valid javadoc and spec.

> Javadoc build is broken
> ---
>
> Key: JCR-5041
> URL: https://issues.apache.org/jira/browse/JCR-5041
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: parent
>Reporter: Julian Reschke
>Priority: Blocker
>
> As 
>   https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0
> now fail with a 404. Apparently, this has started to fail in the last 48 
> hours.
> See
>   https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-trunk/277/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-748) Fix XSD namespaces

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-748:
--

 Summary: Fix XSD namespaces
 Key: JCRVLT-748
 URL: https://issues.apache.org/jira/browse/JCRVLT-748
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Using the XSD as outlined in 
https://jackrabbit.apache.org/filevault/filter.html#general-structure does not 
work, because 
https://jackrabbit.apache.org/filevault/xsd/workspacefilter-1.0.xsd does not 
define a target namespace.
One either has to reference the schema without a namespace 
(https://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation) or define a target 
namespace in the XSD.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCRVLT-749) IAE in generate-metadata during incremental builds

[Konrad Windszus (Jira)]

Konrad Windszus created JCRVLT-749:
--

 Summary: IAE in generate-metadata during incremental builds
 Key: JCRVLT-749
 URL: https://issues.apache.org/jira/browse/JCRVLT-749
 Project: Jackrabbit FileVault
  Issue Type: Improvement
Affects Versions: package-maven-plugin-1.3.6
Reporter: Konrad Windszus
Assignee: Konrad Windszus


The following error can be seen with goal {{generate-metadata}} when being 
executed with m2e

{code}
Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata} 
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)

org.eclipse.core.runtime.CoreException: Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata}
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at 
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at 
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-generate-metadata of goal 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
failed: Could not figure out version part in filename 'pom.xml'. For this 
artifact you cannot use 'isAllVersionsFilter=true'
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version 
part in filename 'pom.xml'. For this artifact you cannot use 
'isAllVersionsFilter=t

[jira] [Updated] (JCRVLT-749) IAE in generate-metadata during incremental builds

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-749:
---
Description: 
The following error can be seen with goal {{generate-metadata}} when being 
executed with m2e

{code}
Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata} 
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)

org.eclipse.core.runtime.CoreException: Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata}
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at 
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at 
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-generate-metadata of goal 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
failed: Could not figure out version part in filename 'pom.xml'. For this 
artifact you cannot use 'isAllVersionsFilter=true'
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version 
part in filename 'pom.xml'. For this artifact you cannot use 
'isAllVersionsFilter=true'
at 
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMojo.getPathFilterSetForEmbeddedFile(GenerateMetadataMojo.java:1234)
at 
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMo

[jira] [Commented] (JCRVLT-749) IAE in generate-metadata during incremental builds

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834037#comment-17834037
 ] 

Konrad Windszus commented on JCRVLT-749:


This is an issue with m2e which returns sometimes
* The path to the pom.xml for dependencies which are Eclipse projects and 
sometimes
* The path to the classes folder for dependencies which are Eclipse projects

Not sure yet under which circumstances what is returned.

> IAE in generate-metadata during incremental builds
> --
>
> Key: JCRVLT-749
> URL: https://issues.apache.org/jira/browse/JCRVLT-749
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following error can be seen with goal {{generate-metadata}} when being 
> executed with m2e
> {code}
> Failed to execute mojo 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
> {execution: default-generate-metadata} 
> (org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
> org.eclipse.core.runtime.CoreException: Failed to execute mojo 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
> {execution: default-generate-metadata}
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
>   at 
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
>   at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
>   at 
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
>   at 
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
>   at 
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
>   at 
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
>   at 
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
>   at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
> default-generate-metadata of goal 
> org.a

[jira] [Comment Edited] (JCRVLT-749) IAE in generate-metadata during incremental builds

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834037#comment-17834037
 ] 

Konrad Windszus edited comment on JCRVLT-749 at 4/4/24 9:06 PM:


This is an issue with m2e which returns sometimes
* the path to the pom.xml for dependencies (type != pom) which are Eclipse 
projects and sometimes
* the path to the classes folder for dependencies which are Eclipse projects

Not sure yet under which circumstances what is returned.


was (Author: kwin):
This is an issue with m2e which returns sometimes
* The path to the pom.xml for dependencies which are Eclipse projects and 
sometimes
* The path to the classes folder for dependencies which are Eclipse projects

Not sure yet under which circumstances what is returned.

> IAE in generate-metadata during incremental builds
> --
>
> Key: JCRVLT-749
> URL: https://issues.apache.org/jira/browse/JCRVLT-749
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following error can be seen with goal {{generate-metadata}} when being 
> executed with m2e
> {code}
> Failed to execute mojo 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
> {execution: default-generate-metadata} 
> (org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
> org.eclipse.core.runtime.CoreException: Failed to execute mojo 
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
> {execution: default-generate-metadata}
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
>   at 
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
>   at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
>   at 
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
>   at 
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
>   at 
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
>   at 
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
>   at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
>   at 
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
>   at 
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
>   at 

[jira] [Updated] (JCRVLT-749) IAE in generate-metadata during incremental builds

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-749:
---
Description: 
The following error can be seen with goal {{generate-metadata}} when being 
executed with m2e

{code}
Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata} 
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)

org.eclipse.core.runtime.CoreException: Failed to execute mojo 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
{execution: default-generate-metadata}
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at 
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at 
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at 
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at 
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at 
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at 
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at 
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at 
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at 
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-generate-metadata of goal 
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata 
failed: Could not figure out version part in filename 'pom.xml'. For this 
artifact you cannot use 'isAllVersionsFilter=true'
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at 
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version 
part in filename 'pom.xml'. For this artifact you cannot use 
'isAllVersionsFilter=true'
at 
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMojo.getPathFilterSetForEmbeddedFile(GenerateMetadataMojo.java:1234)
at 
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMo

[jira] [Commented] (JCRVLT-750) startup error around unclosed archives

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17834337#comment-17834337
 ] 

Konrad Windszus commented on JCRVLT-750:


[~ankitaagar] You referenced a patch file from a private JIRA instance. Please 
rather attach the patch here.

> startup error around unclosed archives
> --
>
> Key: JCRVLT-750
> URL: https://issues.apache.org/jira/browse/JCRVLT-750
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Ankita Agarwal
>Priority: Major
>
> {code:java}
> 11.03.2024 13:33:10.690 *ERROR* [OsgiInstallerImpl] 
> org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive. 
> To figure out where it has been opened set the Java System property 
> 'vault.enableStackTraces' to 'true'11.03.2024 13:33:10.690 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.vault.fs.io.AbstractArchive 
> Detected unclosed archive. To figure out where it has been opened set the 
> Java System property 'vault.enableStackTraces' to 'true'11.03.2024 
> 13:33:10.690 *ERROR* [OsgiInstallerImpl] 
> org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive. 
> To figure out where it has been opened set the Java System property 
> 'vault.enableStackTraces' to 'true' 
> Full stacktrace of above unclosed archive is (it can be seen in logs using 
> the switch {{{}-Dvault.enableStackTraces=true{}}}):
> {code}
> {code:xml}
> java.lang.Exception: Open Stack Trace
>   at org.h2.util.CloseWatcher.register(CloseWatcher.java:85)
>   at 
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:156)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getArchive(ZipVaultPackage.java:107)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getMetaInf(ZipVaultPackage.java:145)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getPropertiesMap(ZipVaultPackage.java:323)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getProperty(PackagePropertiesImpl.java:265)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getId(PackagePropertiesImpl.java:62)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageDefinitionImpl.unwrap(JcrPackageDefinitionImpl.java:219)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.tryUnwrap(JcrPackageImpl.java:258)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:414)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:356)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:350)
>   at 
> com.adobe.granite.installer.factory.packages.impl.PackageTransformer$InstallPackageTask.execute(PackageTransformer.java:348)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:918)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:755)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:304)
>   at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
> It seems that, in case of sub packages, filevault opens the archive but only 
> processes (and close) them in case of non-recursive import option is set to 
> false [0]. Packages are deployed non-recursively in this case and filevault 
> is not closing the archives when subpacks are not empty.
> This seems to be happening for the we-retail packages, as in case of 
> we-retail the created archive is of type ZipArchive [1] (and we are adding a 
> close watcher for it [3]), for other cases in which subpacks are there, 
> archive is of type MemoryArchive [2]
> I believe this 
> [filevault.patch{^}!https://jira.corp.adobe.com/images/icons/link_attachment_7.gif|width=7,height=7!{^}|https://jira.corp.adobe.com/secure/attachment/11792561/11792561_filevault.patch]
>  should fix the problem,
> [0]: 
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L484]
> [1]: 
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L323-L333]
> [2]: 
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L306-L323]
> [3]: 
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/ZipArchive.java#L156]
> [Edit|https://jira.corp.adobe.com/secure/EditComment

[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840140#comment-17840140
 ] 

Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:31 PM:
-

In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as 
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.


was (Author: kwin):
In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP 
path `/home/users/test/__6k_test-user-a` (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path `/home/users/test/_6k_test-user-a` during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840140#comment-17840140
 ] 

Konrad Windszus commented on JCRVLT-751:


In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP 
path `/home/users/test/__6k_test-user-a` (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path `/home/users/test/_6k_test-user-a` during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840140#comment-17840140
 ] 

Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:32 PM:
-

In my tests the node path
{code}
/home/users/test/_6k_test-user-a
{code} is exported as ZIP path
{code}
/home/users/test/__6k_test-user-a
{code}
(which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.


was (Author: kwin):
In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as 
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to 
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and 
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during 
import.

> Can't import a user with parent folder that starts with _ and includes 
> another _ 
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly unescaped during filter rule mapping

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Summary: ExportOptions.rootPath not properly unescaped during filter rule 
mapping  (was: Can't import a user with parent folder that starts with _ and 
includes another _ )

> ExportOptions.rootPath not properly unescaped during filter rule mapping
> 
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Summary: ExportOptions.rootPath not properly converted to platform name 
format  (was: ExportOptions.rootPath not properly unescaped during filter rule 
mapping)

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Assignee: Konrad Windszus
  Status: Patch Available  (was: Open)

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format

[Konrad Windszus (Jira)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Konrad Windszus updated JCRVLT-751:
---
Fix Version/s: 3.7.4

> ExportOptions.rootPath not properly converted to platform name format
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Assignee: Konrad Windszus
>Priority: Major
>  Labels: vault
> Fix For: 3.7.4
>
>
> AEM has a user synchronisation capability in the publish tier. The 
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that 
> contain another _ can be exported but fail to be re-imported. For instance, 
> the user stored under the path /home/users/test/_6k_test-user-a won't be 
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a 
> namespace and thus skip the resource upon import because the paths don't 
> match.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard

[Konrad Windszus (Jira)]

Konrad Windszus created JCR-5051:


 Summary: ISO9075.encodePath/encode should preserve wildcard
 Key: JCR-5051
 URL: https://issues.apache.org/jira/browse/JCR-5051
 Project: Jackrabbit Content Repository
  Issue Type: New Feature
  Components: jackrabbit-jcr-commons
Reporter: Konrad Windszus


Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed 
character in the grammar 
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to 
explicitly add another method to keep the wildcard in place.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)