[jira] [Comment Edited] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-209 at 10/19/17 5:21 AM:
---

[~kwin] I created a PR: 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/3

it implements the algorithm above. I changed it slightly, so that it fails, if 
a filter.xml is present due to the resource plugin *and* filters are specified 
in the pom.
I also added a bunch of tests.


was (Author: tripod):
[~kwin] I created a PR: 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/3

it implements the algorithm above. I changed it slightly, so that it fails, if 
a filter.xml is coming in through the resource plugin *and* filters are 
specified in the pom.
I also added a bunch of tests.

> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being 
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is 
> being generated which is irrelevant for the package 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
>  IMHO this is not a clever default behaviour because it forces to always use 
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter 
> {{filterSource}} should be used instead, but in any case the generated 
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated 
> filter file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-209 at 10/19/17 5:20 AM:
---

well, I disagree. most of the usages so far, are quite simple; just define the 
vault-work in the resources, and have a more or less empty plugin config:

{noformat}



${basedir}/META-INF
../vault-work/META-INF


${basedir}/jcr_root
.





com.day.jcr.vault
content-package-maven-plugin
true
0.5.14



{noformat}

additionally, there are many more files that potentially go into the 
META-INF/vault directory, like the nodetypes, privileges, entire package 
definition trees, etc. so using a deliberate filter.xml is rather the norm, 
than having everything in the pom.

so maybe the problem is not the filterSource alone, but the lacking capability 
to specify the meta-inf source. so we can do away from specifying the meta-info 
in the resource plugin. this is IMO also the goal of JCRVLT-210.

anyways, I don't think that the checksum would help here. because if someone 
modifies the filters in the pom, the content would also be different.
another alternative would be, to more or less keep the current way, but to set 
the last-modified date of the filter.xml to 0, so that the next resource-plugin 
run would update it. so no need to 'clean':

- if last modified of {{vault-work/META-INF/vault/filter.xml == 0}} -> delete it
- if a {{filter.xml}} exists and the pom defines filters, fail.
- if no filterSource exists, but {{filter.xml}} read the filters into 
{{sourceFilters}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- update the last modified time of {{filter.xml}} to 0






was (Author: tripod):
well, I disagree. most of the usages so far, are quite simple; just define the 
vault-work in the resources, and have a more or less empty plugin config:

{noformat}



${basedir}/META-INF
../vault-work/META-INF


${basedir}/jcr_root
.





com.day.jcr.vault
content-package-maven-plugin
true
0.5.14



{noformat}

additionally, there are many more files that potentially go into the 
META-INF/vault directory, like the nodetypes, privileges, entire package 
definition trees, etc. so using a deliberate filter.xml is rather the norm, 
than having everything in the pom.

so maybe the problem is not the filterSource alone, but the lacking capability 
to specify the meta-inf source. so we can do away from specifying the meta-info 
in the resource plugin. this is IMO also the goal of JCRVLT-210.

anyways, I don't think that the checksum would help here. because if someone 
modifies the filters in the pom, the content would also be different.
another alternative would be, to more or less keep the current way, but to set 
the last-modified date of the filter.xml to 0, so that the next resource-plugin 
run would update it. so no need to 'clean':

- if last modified of {{vault-work/META-INF/vault/filter.xml == 0}} -> delete it
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml}} read the filters into 
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- update the last modified time of {{filter.xml}} to 0





> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is

[jira] [Commented] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-209:
-

[~kwin] I created a PR: 
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/3

it implements the algorithm above. I changed it slightly, so that it fails, if 
a filter.xml is coming in through the resource plugin *and* filters are 
specified in the pom.
I also added a bunch of tests.

> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being 
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is 
> being generated which is irrelevant for the package 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
>  IMHO this is not a clever default behaviour because it forces to always use 
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter 
> {{filterSource}} should be used instead, but in any case the generated 
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated 
> filter file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4191:

Comment: was deleted

(was: Note that we have a similar problem in jackrabbit-jcr-rmi.)

> baseline checks fails for jackrabbit-webdav under Java 9
> 
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock  changed1.0.0  
> 1.0.0  1.0.1  Version increase required
> [INFO]  ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO]  ~ method hashCode()
> [INFO]  - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have 
> adding {{hashCode()}} have this effect, and only when the tools is run with 
> Java 9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-215) add option to check/lint the vault docview xmls

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-215:
---

 Summary: add option to check/lint the vault docview xmls
 Key: JCRVLT-215
 URL: https://issues.apache.org/jira/browse/JCRVLT-215
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: package maven plugin
Reporter: Tobias Bocanegra
Priority: Minor


to ensure consistency between the files that are packaged and their format that 
eventually results after a server roundtrip, the package plugin could have an 
option to check that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-214) auto-import package analyzer needs option to exclude compiletime bundles

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-214:

Description: 
due to the setup of the class analyzer, it is almost impossible to get a clean 
class path for detecting the unused jars. also, for HTL scripting validation 
support, certain libraries, like the HTL script compiler are not really project 
dependencies, but only using at runtime.
but we can't use the maven _runtime_ scope to declare those dependencies, 
otherwise they don't get added to the compile classpath.

suggest to add new property:

- *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
of libraries to ignored in the import package analyzer. 

example:

{code:xml}

org.apache.jackrabbit
filevault-package-maven-plugin
true


org.osgi:org.osgi.service.component.annotations,
org.osgi:org.osgi.service.metatype.annotations,
org.osgi:osgi.annotation



{code}

  was:
due to the setup of the class analyzer, it is almost impossible to get a clean 
class path for detecting the unused jars. also, for HTL scripting validation 
support, certain libraries, like the HTL script compiler are not really project 
dependencies, but only using at runtime.
but we can't use the maven _runtime_ scope to declare those dependencies, 
otherwise they don't get added to the compile classpath.

suggest to add new property:

- *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
of libraries to ignored in the import package analyzer. 

example:

{code}

org.apache.jackrabbit
filevault-package-maven-plugin
true


org.osgi:org.osgi.service.component.annotations,
org.osgi:org.osgi.service.metatype.annotations,
org.osgi:osgi.annotation


{code}


> auto-import package analyzer needs option to exclude compiletime bundles
> 
>
> Key: JCRVLT-214
> URL: https://issues.apache.org/jira/browse/JCRVLT-214
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: package-maven-plugin-1.0.0
>
>
> due to the setup of the class analyzer, it is almost impossible to get a 
> clean class path for detecting the unused jars. also, for HTL scripting 
> validation support, certain libraries, like the HTL script compiler are not 
> really project dependencies, but only using at runtime.
> but we can't use the maven _runtime_ scope to declare those dependencies, 
> otherwise they don't get added to the compile classpath.
> suggest to add new property:
> - *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
> of libraries to ignored in the import package analyzer. 
> example:
> {code:xml}
> 
> org.apache.jackrabbit
> filevault-package-maven-plugin
> true
> 
> 
> org.osgi:org.osgi.service.component.annotations,
> org.osgi:org.osgi.service.metatype.annotations,
> org.osgi:osgi.annotation
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-214) auto-import package analyzer needs option to exclude compiletime bundles

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-214:

Description: 
due to the setup of the class analyzer, it is almost impossible to get a clean 
class path for detecting the unused jars. also, for HTL scripting validation 
support, certain libraries, like the HTL script compiler are not really project 
dependencies, but only using at runtime.
but we can't use the maven _runtime_ scope to declare those dependencies, 
otherwise they don't get added to the compile classpath.

suggest to add new property:

- *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
of libraries to ignored in the import package analyzer. 

example:

{code}

org.apache.jackrabbit
filevault-package-maven-plugin
true


org.osgi:org.osgi.service.component.annotations,
org.osgi:org.osgi.service.metatype.annotations,
org.osgi:osgi.annotation


{code}

  was:
due to the setup of the class analyzer, it is almost impossible to get a clean 
class path for detecting the unused jars. also, for HTL scripting validation 
support, certain libraries, like the HTL script compiler are not really project 
dependencies, but only using at runtime.
but we can't use the maven _runtime_ scope to declare those dependencies, 
otherwise they don't get added to the compile classpath.

suggest to add new property:

- *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
of libraries to ignored in the import package analyzer. 

example:

{code}

org.apache.jackrabbit
filevault-package-maven-plugin
true


org.osgi:org.osgi.service.component.annotations,
org.osgi:org.osgi.service.metatype.annotations,
org.osgi:osgi.annotation




> auto-import package analyzer needs option to exclude compiletime bundles
> 
>
> Key: JCRVLT-214
> URL: https://issues.apache.org/jira/browse/JCRVLT-214
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: package-maven-plugin-1.0.0
>
>
> due to the setup of the class analyzer, it is almost impossible to get a 
> clean class path for detecting the unused jars. also, for HTL scripting 
> validation support, certain libraries, like the HTL script compiler are not 
> really project dependencies, but only using at runtime.
> but we can't use the maven _runtime_ scope to declare those dependencies, 
> otherwise they don't get added to the compile classpath.
> suggest to add new property:
> - *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
> of libraries to ignored in the import package analyzer. 
> example:
> {code}
> 
> org.apache.jackrabbit
> filevault-package-maven-plugin
> true
> 
> 
> org.osgi:org.osgi.service.component.annotations,
> org.osgi:org.osgi.service.metatype.annotations,
> org.osgi:osgi.annotation
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-214) auto-import package analyzer needs option to exclude compiletime bundles

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-214:
---

 Summary: auto-import package analyzer needs option to exclude 
compiletime bundles
 Key: JCRVLT-214
 URL: https://issues.apache.org/jira/browse/JCRVLT-214
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: package maven plugin
Reporter: Tobias Bocanegra
Assignee: Tobias Bocanegra
 Fix For: package-maven-plugin-1.0.0


due to the setup of the class analyzer, it is almost impossible to get a clean 
class path for detecting the unused jars. also, for HTL scripting validation 
support, certain libraries, like the HTL script compiler are not really project 
dependencies, but only using at runtime.
but we can't use the maven _runtime_ scope to declare those dependencies, 
otherwise they don't get added to the compile classpath.

suggest to add new property:

- *{{ignoredUnusedLibs}}* comma separated string of partial maven coordinates 
of libraries to ignored in the import package analyzer. 

example:

{code}

org.apache.jackrabbit
filevault-package-maven-plugin
true


org.osgi:org.osgi.service.component.annotations,
org.osgi:org.osgi.service.metatype.annotations,
org.osgi:osgi.annotation





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9

[Karl Pauls (JIRA)]

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

Karl Pauls commented on JCR-4191:
-

Ultimately, I think you should take this to the bnd project. I would argue they 
should special case jdk.internal.* annotations for the baseline.

> baseline checks fails for jackrabbit-webdav under Java 9
> 
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock  changed1.0.0  
> 1.0.0  1.0.1  Version increase required
> [INFO]  ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO]  ~ method hashCode()
> [INFO]  - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have 
> adding {{hashCode()}} have this effect, and only when the tools is run with 
> Java 9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9

[Karl Pauls (JIRA)]

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

Karl Pauls commented on JCR-4191:
-

[~reschke], I think it is not adding the hashCode method (that is always 
there). It is the jdk.internal.HotSpotIntrinsicCandidate annotation that java9 
will add automagically. That will be picked up by bnd as a micro change. 
Normally, I would say that is correct and you should just bump the version 
number but in this case that would be bad because it would flip-flop 
dependening on the java version used to build the bundle. 

Regarding your test using bnd directly: did you maybe build 
target/jackrabbit-webdav-2.15.7-SNAPSHOT.jar with java8? I don't think it is 
important which java version you use to run bnd but rather which one you use to 
build the SNAPSHOT.

> baseline checks fails for jackrabbit-webdav under Java 9
> 
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock  changed1.0.0  
> 1.0.0  1.0.1  Version increase required
> [INFO]  ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO]  ~ method hashCode()
> [INFO]  - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have 
> adding {{hashCode()}} have this effect, and only when the tools is run with 
> Java 9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jackrabbit-trunk - Build # 2525 - Fixed

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2525)

Status: Fixed

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2525/ to 
view the results.

Jackrabbit-trunk - Build # 2524 - Still Unstable

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2524)

Status: Still Unstable

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2524/ to 
view the results.

[jira] [Commented] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4195:
-

trunk: [r1812554|http://svn.apache.org/r1812554]

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4195.
-
   Resolution: Fixed
Fix Version/s: 2.15.7

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

[Julian Reschke (JIRA)]

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

Julian Reschke reassigned JCR-4195:
---

Assignee: Julian Reschke

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4195) jcr-rmi on java 9: Cannot use SUN rmic, as it is not available

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4195:
-

- remove RMIC invocation
- bump up version numbers to 3.0.0 as suggested by bundle plugin

> jcr-rmi on java 9: Cannot use SUN rmic, as it is not available
> --
>
> Key: JCR-4195
> URL: https://issues.apache.org/jira/browse/JCR-4195
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-antrun-plugin:1.8:run (rmic) on project 
> jackrabbit-jcr-rmi: An Ant BuildException has occured: Cannot use SUN rmic, 
> as it is not available.  A common solution is to set the environment variable 
> JAVA_HOME
> [ERROR] around Ant part ... classpathref="maven.compile.classpath" 
> base="C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\classes"/>...
>  @ 4:140 in 
> C:\projects\apache\jackrabbit\trunk\jackrabbit-jcr-rmi\target\antrun\build-main.xml
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCR-4199) oak-solr-core test faillures with java 9

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4199:
---

 Summary: oak-solr-core test faillures with java 9
 Key: JCR-4199
 URL: https://issues.apache.org/jira/browse/JCR-4199
 Project: Jackrabbit Content Repository
  Issue Type: Task
  Components: query
Reporter: Julian Reschke


{noformat}
[ERROR] Tests run: 29, Failures: 2, Errors: 0, Skipped: 2, Time elapsed: 
156.134 s <<< FAILURE! - in 
org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT
[ERROR] 
testNativeMLTQueryWithStream(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
  Time elapsed: 5.501 s  <<< FAILURE!
org.junit.ComparisonFailure: expected: but was:
at 
org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQueryWithStream(SolrIndexIT.java:281)

[ERROR] 
testNativeMLTQuery(org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT)
  Time elapsed: 5.523 s  <<< FAILURE!
org.junit.ComparisonFailure: expected: but was:
at 
org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexIT.testNativeMLTQuery(SolrIndexIT.java:259)

{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4196) update surefire and failsafe plugins for use with java 9

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4196:
-

trunk: [r1812543|http://svn.apache.org/r1812543]

> update surefire and failsafe plugins for use with java 9
> 
>
> Key: JCR-4196
> URL: https://issues.apache.org/jira/browse/JCR-4196
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [WARNING] Error injecting: 
> org.apache.maven.plugin.failsafe.IntegrationTestMojo
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3110)
> at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2314)
> at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> {noformat}
> Surefire as well for consistency...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4196) update surefire and failsafe plugins for use with java 9

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4196:

Labels: candidate_jcr_2_14  (was: )

> update surefire and failsafe plugins for use with java 9
> 
>
> Key: JCR-4196
> URL: https://issues.apache.org/jira/browse/JCR-4196
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>  Labels: candidate_jcr_2_14
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [WARNING] Error injecting: 
> org.apache.maven.plugin.failsafe.IntegrationTestMojo
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3110)
> at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2314)
> at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> {noformat}
> Surefire as well for consistency...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-4196) update surefire and failsafe plugins for use with java 9

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4196.
-
   Resolution: Fixed
Fix Version/s: 2.15.7

> update surefire and failsafe plugins for use with java 9
> 
>
> Key: JCR-4196
> URL: https://issues.apache.org/jira/browse/JCR-4196
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16, 2.15.7
>
>
> {noformat}
> [WARNING] Error injecting: 
> org.apache.maven.plugin.failsafe.IntegrationTestMojo
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3110)
> at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2314)
> at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> {noformat}
> Surefire as well for consistency...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4196) update surefire and failsafe plugins for use with java 9

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4196:

Summary: update surefire and failsafe plugins for use with java 9  (was: 
update failsafe plugin for use of java 9)

> update surefire and failsafe plugins for use with java 9
> 
>
> Key: JCR-4196
> URL: https://issues.apache.org/jira/browse/JCR-4196
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-parent
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> {noformat}
> [WARNING] Error injecting: 
> org.apache.maven.plugin.failsafe.IntegrationTestMojo
> java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at 
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3110)
> at java.base/java.lang.Class.getDeclaredConstructors(Class.java:2314)
> at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
> {noformat}
> Surefire as well for consistency...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jackrabbit-trunk - Build # 2522 - Unstable

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2522)

Status: Unstable

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2522/ to 
view the results.

[jira] [Commented] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4078:
-

trunk: [r1812515|http://svn.apache.org/r1812515] 
[r1773332|http://svn.apache.org/r1773332]


> occasional test failure in GarbageCollectorTest.testSimultaneousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4078:

Comment: was deleted

(was: trunk: [r1773332|http://svn.apache.org/r1773332]
)

> occasional test failure in GarbageCollectorTest.testSimultaneousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4078:

Summary: occasional test failure in 
GarbageCollectorTest.testSimultaneousRunGC  (was: occasional test failure in 
GarbageCollectorTest.testSimulatenousRunGC)

> occasional test failure in GarbageCollectorTest.testSimultaneousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-210 at 10/18/17 12:58 PM:


I must have overlooked the .DS_Store in the defaults; I remove it again.

well, the META-INF/vault suffers from the same problem as the normal content. 
if a project wants to provide its own meta files, it needs to specify is via 
the resource plugin (see the confusion with the vault-work and filter.xml). 
having cleanly defined directories for the jcr root and vault meta-dir, 
probably helps. when specifying a {{vaultMetaDirectory}} it would copy it to 
the vault-work. but let's tackle the content first, and look at the vault-work 
in  a followup bug.

for both cases, I would not auto default, if {{target/classes/jcr_root}} exists 
or {{target/vault-work}} already exists.


was (Author: tripod):
I must have overlooked the .DS_Store in the defaults; I remove it again.

well, the META-INF/vault suffers from the same problem as the normal content. 
if a project wants to provide its own meta files, it needs to specify is via 
the resource plugin (see the confusion with the vault-work and filter.xml). 
having cleanly defined directories for the jcr root and vault meta-dir, 
probably helps. when specifying a {{vaultMetaDirectory}} it would copy it to 
the vault-work. 

for both cases, I would not auto default, if {{target/classes/jcr_root}} exists 
or {{target/vault-work}} already exists

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-210:
-

I must have overlooked the .DS_Store in the defaults; I remove it again.

well, the META-INF/vault suffers from the same problem as the normal content. 
if a project wants to provide its own meta files, it needs to specify is via 
the resource plugin (see the confusion with the vault-work and filter.xml). 
having cleanly defined directories for the jcr root and vault meta-dir, 
probably helps. when specifying a {{vaultMetaDirectory}} it would copy it to 
the vault-work. 

for both cases, I would not auto default, if {{target/classes/jcr_root}} exists 
or {{target/vault-work}} already exists

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4078:
-

The expected exception apparently is:

{noformat}
javax.jcr.RepositoryException: Cannot create GC. GC already running
at 
org.apache.jackrabbit.core.RepositoryImpl.createDataStoreGarbageCollector(RepositoryImpl.java:1454)
at 
org.apache.jackrabbit.core.SessionImpl.createDataStoreGarbageCollector(SessionImpl.java:599)
at org.apache.jackrabbit.core.data.GCThread.run(GCThread.java:52)
at java.lang.Thread.run(Unknown Source)
{noformat}

> occasional test failure in GarbageCollectorTest.testSimulatenousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCR-4078) occasional test failure in GarbageCollectorTest.testSimulatenousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke edited comment on JCR-4078 at 10/18/17 12:53 PM:


Note that 
{{org.apache.jackrabbit.core.data.GarbageCollectorTest#testCloseSessionWhileRunningGc}}
is already marked as failure.


was (Author: reschke):
Note that

  
org.apache.jackrabbit.core.data.GarbageCollectorTest#testCloseSessionWhileRunningGc

is already marked as failure.

> occasional test failure in GarbageCollectorTest.testSimulatenousRunGC
> -
>
> Key: JCR-4078
> URL: https://issues.apache.org/jira/browse/JCR-4078
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Julian Reschke
>
> 
> {noformat}
> Error Message
> only one gc should throw exception  expected:<1> but was:<0>
> Stacktrace
> junit.framework.AssertionFailedError: only one gc should throw exception  
> expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:67)
>   at junit.framework.Assert.assertEquals(Assert.java:199)
>   at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimulatenousRunGC(GarbageCollectorTest.java:214)
> {noformat}
> Minimally, the diagnostics are misleading. Maybe the first garbage collector 
> completes too soon?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-3547) Datastore GC doesn't reset updateModifiedDateOnAccess on datastore

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-3547:
-

trunk: [r1482732|http://svn.apache.org/r1482732]

> Datastore GC doesn't reset updateModifiedDateOnAccess on datastore
> --
>
> Key: JCR-3547
> URL: https://issues.apache.org/jira/browse/JCR-3547
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 2.4, 2.5
>Reporter: Shashank Gupta
>Assignee: Thomas Mueller
> Fix For: 2.7.1
>
> Attachments: GC_prevent_concurrent_run_app2.patch, 
> GC_prevent_concurrent_run_final.patch, GC_prevent_concurrnet_run_app1.patch, 
> GarbageCollector.java.patch
>
>
> In mark phase, GC updates store.updateModifiedDateOnAccess with current time, 
> so that datastore updates record’s lastModified timestamp upon subsequent 
> read/scan.
>  But  GC doesn't reset it to 0. So even after GC completes, datastore will 
> continue updating lastModified timestamp on read invocations and it will have 
> performance impact. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCR-4198) Occasional test failures in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke resolved JCR-4198.
-
Resolution: Duplicate

> Occasional test failures in GarbageCollectorTest.testSimultaneousRunGC
> --
>
> Key: JCR-4198
> URL: https://issues.apache.org/jira/browse/JCR-4198
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>
> {noformat}
> [ERROR] 
> testSimultaneousRunGC(org.apache.jackrabbit.core.data.GarbageCollectorTest)  
> Time elapsed: 1.263 s  <<< FAILURE!
> junit.framework.AssertionFailedError: None of the GCs threw an exception
> at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimultaneousRunGC(GarbageCollectorTest.java:215)
> {noformat}
> Timing?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4198) Occasional test failures in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4198:

Priority: Minor  (was: Major)

> Occasional test failures in GarbageCollectorTest.testSimultaneousRunGC
> --
>
> Key: JCR-4198
> URL: https://issues.apache.org/jira/browse/JCR-4198
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: core
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>
> {noformat}
> [ERROR] 
> testSimultaneousRunGC(org.apache.jackrabbit.core.data.GarbageCollectorTest)  
> Time elapsed: 1.263 s  <<< FAILURE!
> junit.framework.AssertionFailedError: None of the GCs threw an exception
> at 
> org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimultaneousRunGC(GarbageCollectorTest.java:215)
> {noformat}
> Timing?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCR-4198) Occasional test failures in GarbageCollectorTest.testSimultaneousRunGC

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4198:
---

 Summary: Occasional test failures in 
GarbageCollectorTest.testSimultaneousRunGC
 Key: JCR-4198
 URL: https://issues.apache.org/jira/browse/JCR-4198
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: core
Reporter: Julian Reschke
Assignee: Julian Reschke


{noformat}
[ERROR] 
testSimultaneousRunGC(org.apache.jackrabbit.core.data.GarbageCollectorTest)  
Time elapsed: 1.263 s  <<< FAILURE!
junit.framework.AssertionFailedError: None of the GCs threw an exception
at 
org.apache.jackrabbit.core.data.GarbageCollectorTest.testSimultaneousRunGC(GarbageCollectorTest.java:215)
{noformat}

Timing?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCR-4189) Jackrabbit should compile & test on Java 9

[Julian Reschke (JIRA)]

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

Julian Reschke updated JCR-4189:

Attachment: JCR-4189.diff

wip changes for testing with jdk9

> Jackrabbit should compile & test on Java 9
> --
>
> Key: JCR-4189
> URL: https://issues.apache.org/jira/browse/JCR-4189
> Project: Jackrabbit Content Repository
>  Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
> Attachments: JCR-4189.diff
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9

[Julian Reschke (JIRA)]

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

Julian Reschke commented on JCR-4191:
-

Note that we have a similar problem in jackrabbit-jcr-rmi.

> baseline checks fails for jackrabbit-webdav under Java 9
> 
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock  changed1.0.0  
> 1.0.0  1.0.1  Version increase required
> [INFO]  ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO]  ~ method hashCode()
> [INFO]  - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have 
> adding {{hashCode()}} have this effect, and only when the tools is run with 
> Java 9.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Oak (1.8) and Jackrabbit (2.16) stable releases plan

[Julian Reschke]

Sounds good to me in general.

One thought however on...:

On 2017-10-18 12:12, Davide Giannella wrote:

Hello team,

I took the time to crunch in some dates and here's a proposal for our
next stable releases:

# 27th November

Branch and Release Jackrabbit 2.16.0
...


As we aren't doing any new feature work in Jackrabbit anyway (*), I 
might do the branch for 2.16 a bit earlier (maybe the week before).


Best regards, Julian

(*) Or does anybody have changes in mind that need to go into 2.16?

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on JCRVLT-210 at 10/18/17 10:34 AM:
---

.DS_Store is part of the default excludes already 
(https://github.com/sonatype/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/AbstractScanner.java#L83).
 I was more thinking about excluding  the conflict markers from Vlt in addition.

Regarding your proposal of deprecating {{builtContentDirectory}}. This sounds 
good in general.
I am just not sure about {{vaultMetaDirectory}} as we already have 
{{workDirectory}} which ends up in the package as well.
I would propose introducing a new parameter {{jcrRootSourceDirectory}} which 
may have the defaults you proposed (with several fallbacks). In any case the 
new parameter should have the {{Directory}} suffix to be in line with other 
parameters receiving a directory name.


was (Author: kwin):
.DS_Store is part of the default excludes already 
(https://github.com/sonatype/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/AbstractScanner.java#L83).
 I was more thinking about excluding  the conflict markers from Vlt.

Regarding your proposal of deprecating {{builtContentDirectory}}. This sounds 
good in general.
I am just not sure about {{vaultMetaDirectory}} as we already have 
{{workDirectory}} which ends up in the package as well.
I would propose introducing a new parameter {{jcrRootSourceDirectory}} which 
may have the defaults you proposed (with several fallbacks).

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on JCRVLT-210:


.DS_Store is part of the default excludes already 
(https://github.com/sonatype/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/AbstractScanner.java#L83).
 I was more thinking about excluding  the conflict markers from Vlt.

Regarding your proposal of deprecating {{builtContentDirectory}}. This sounds 
good in general.
I am just not sure about {{vaultMetaDirectory}} as we already have 
{{workDirectory}} which ends up in the package as well.
I would propose introducing a new parameter {{jcrRootSourceDirectory}} which 
may have the defaults you proposed (with several fallbacks).

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Oak (1.8) and Jackrabbit (2.16) stable releases plan

[Davide Giannella]

Hello team,

I took the time to crunch in some dates and here's a proposal for our
next stable releases:

# 27th November

Branch and Release Jackrabbit 2.16.0

# 5th December

Update Oak 1.7.x to Jackrabbit 2.16.0. This will give us maximum
coverage on the usage of this specific version in Oak based on our
current unstable release cycle

# 21st December

Release Oak 1.7.14. This will technically be our latest unstable cut as
there's the winter break in the middle and we won't have full coverage
from all of us

# 15th January

Branch and Release Oak 1.8.0 (or 2.0.0 see other thread).

After each stable release the effort should therefore move on the
stabilisation of the stable release branches of which we'll go for
releases on demand basis depending on what/if fixed. No more unstable
cut for now.

# Somewhere in the future

Resume of the unstable cuts: JR 2.17.x, Oak 1.9.x (or 2.1.x)

If there are any objections please reply. I've already updated the Oak
jira version dates to the above plan.

Cheers
Davide

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-210:
-

the mirror hasn't synced yet, I changed it:
https://svn.apache.org/viewvc?view=revision&revision=1812478

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-210:
-

argh. committed in r1812478 but messed up the commit line. I'm not going to 
change it, otherwise we might have problems with the github mirror.


> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-210:

Comment: was deleted

(was: merged in in r1812478)

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-210:
-

merged in in r1812478

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-210 at 10/18/17 9:03 AM:
---

thanks for the patch. I will merge it in shortly. I think the .DS_Store should 
also go in the default excludes. the rest is covered by the default excludes.

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?

the defaults could also be smart and check for:

{noformat}
${project.basedir}/jcr_root
${project.basedir}/src/main/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.build.outputDirectory}/jcr_root
{noformat}







was (Author: tripod):
thanks for the patch. I will merge it in shortly. I think the .DS_Store should 
also go in the default excludes. the rest is covered by the default excludes.

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?

the defaults could also be smart and check for:

{noformat}
${project.basedir}/jcr_root
${project.basedir}/src/main/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.outputDirectory}/jcr_root
{noformat}






> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-210 at 10/18/17 9:03 AM:
---

thanks for the patch. I will merge it in shortly. I think the .DS_Store should 
also go in the default excludes. the rest is covered by the default excludes.

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?

the defaults could also be smart and check for:

{noformat}
${project.basedir}/jcr_root
${project.basedir}/src/main/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.outputDirectory}/jcr_root
{noformat}







was (Author: tripod):
thanks for the patch. I will merge it in shortly. I think the .DS_Store should 
also go in the default excludes. the rest is covered by the default excludes.

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?

the defaults could also be smart and check for:

{noformat}
${project.basedir}/jcr_root
${project.basedir}/src/main/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.outputDirectory}/jcr_root
{noformat}






> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-210 at 10/18/17 9:02 AM:
---

thanks for the patch. I will merge it in shortly. I think the .DS_Store should 
also go in the default excludes. the rest is covered by the default excludes.

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?

the defaults could also be smart and check for:

{noformat}
${project.basedir}/jcr_root
${project.basedir}/src/main/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.basedir}/src/main/content/jcr_root
${project.outputDirectory}/jcr_root
{noformat}







was (Author: tripod):
thanks for the patch. I will merge it in shortly. I think the .DS_Store, 
.gitignore, .svn should also go in the default excludes

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?


> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-210 at 10/18/17 8:47 AM:
---

thanks for the patch. I will merge it in shortly. I think the .DS_Store, 
.gitignore, .svn should also go in the default excludes

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectory}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?



was (Author: tripod):
thanks for the patch. I will merge it in shortly. I think the .DS_Store, 
.gitignore, .svn should also go in the default excludes

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectoy}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?


> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra commented on JCRVLT-210:
-

thanks for the patch. I will merge it in shortly. I think the .DS_Store, 
.gitignore, .svn should also go in the default excludes

also, I think the {{builtContentDirectory}} is a legacy name that stipulates 
that the content directory is 'built'. how about adding:

- *{{jcrRootDirectory}}* defaults to builtContentDirectory/jcr_root
- *{{vaultMetaDirectoy}}* defaults to builtContentDirectory/META-INF/vault

or just:

- *{{packageSource}}* defaults to builtContentDirectory

and deprecate the {{builtContentDirectory}} ?


> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JCRVLT-210) Allow to define excludes for the ContentPackageArchiver to prevent copying of script files from src to target

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-210:
---

Assignee: Tobias Bocanegra

> Allow to define excludes for the ContentPackageArchiver to prevent copying of 
> script files from src to target
> -
>
> Key: JCRVLT-210
> URL: https://issues.apache.org/jira/browse/JCRVLT-210
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Similar to the {{maven-war-plugin}} it should be possible to define exclusion 
> filename patterns of files which should never end up in the filevault package 
> (compare with 
> https://maven.apache.org/plugins/maven-war-plugin/war-mojo.html, parameter 
> {{warSourceExcludes}}).
> The following filenames come to my mind, which would be useful to exclude by 
> default:
> # .DS_Store
> # SVN files
> # Git fles
> # FileVault conflict files
> That way it would be possible to create the package based on the source 
> directory without being forced to first use the {{maven-resource-plugin}} to 
> copy them somewhere to {{/target}} and do the filtering there.
> That would speed up the generation of large packages a lot.
> At the same time the default value of parameter {{builtContentDirectory}} 
> could be modified to point to the source directory e.g. 
> {{${basedir}/src/main/jcr_root}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-209 at 10/18/17 7:54 AM:
---

what we want:

- backward compatibility: if a filter.xml is copied to vault-work with the 
resource plugin, then it should still "work" correctly. 
- if there are any comments in the original filtere source, they should not get 
lost.
- if there are filters specified in the pom and in a filter source, they should 
get merged.
- if the {{prefix}} property is set, it should be used if no filter is set.

so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the 
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into 
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive



was (Author: tripod):
what we want:

- backward compatibility: if a filter.xml is copied to vault-work with the 
resource plugin, then it should still "work" correctly. 
- if there are any comments in the original filtere source, they should not get 
lost.
- if there are filters specified in the pom and in a filter source, they should 
get merged.
-- if the {{prefix}} property is set, it should be added to all filters.-
- if the {{prefix}} property is set, it should be used if no filter is set.

so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the 
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into 
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive


> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being 
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is 
> being generated which is irrelevant for the package 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
>  IMHO this is not a clever default behaviour because it forces to always use 
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter 
> {{filterSource}} should be used instead, but in any case the generated 
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated 
> filter file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra edited comment on JCRVLT-209 at 10/18/17 7:53 AM:
---

what we want:

- backward compatibility: if a filter.xml is copied to vault-work with the 
resource plugin, then it should still "work" correctly. 
- if there are any comments in the original filtere source, they should not get 
lost.
- if there are filters specified in the pom and in a filter source, they should 
get merged.
-- if the {{prefix}} property is set, it should be added to all filters.-
- if the {{prefix}} property is set, it should be used if no filter is set.

so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the 
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into 
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive



was (Author: tripod):
what we want:

- backward compatibility: if a filter.xml is copied to vault-work with the 
resource plugin, then it should still "work" correctly. 
- if there are any comments in the original filtere source, they should not get 
lost.
- if there are filters specified in the pom and in a filter source, they should 
get merged.
- if the {{prefix}} property is set, it should be added to all filters.

so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the 
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into 
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just 
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive


> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being 
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is 
> being generated which is irrelevant for the package 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
>  IMHO this is not a clever default behaviour because it forces to always use 
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter 
> {{filterSource}} should be used instead, but in any case the generated 
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated 
> filter file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JCRVLT-209) Always write to the filter.xml inside the vaultDir but never to filter-plugin-generated.xml

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-209:
---

Assignee: Tobias Bocanegra

> Always write to the filter.xml inside the vaultDir but never to 
> filter-plugin-generated.xml
> ---
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>
> Currently in case the filter configuration of the plugin has been changed and 
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being 
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is 
> being generated which is irrelevant for the package 
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
>  IMHO this is not a clever default behaviour because it forces to always use 
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter 
> {{filterSource}} should be used instead, but in any case the generated 
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated 
> filter file.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)