[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1253 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1253)

Status: Failure

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1253/ to view 
the results.

Changes:
[tomekr] OAK-5035: Implement mini-benchmark for the PersistentCache

[stefanegli] OAK-5013 : introducing 
o.a.j.o.jcr.observation.filter.FilterFactory and

[stefanegli] OAK-5013 : introducing 
o.a.j.o.jcr.observation.filter.FilterFactory and

[stefanegli] OAK-5013 : introducing 
o.a.j.o.jcr.observation.filter.FilterFactory and

[stefanegli] OAK-5013 : introducing 
o.a.j.o.jcr.observation.filter.FilterFactory and

[frm] OAK-5034 - Set retry timeout to 20 seconds over 160 iterations

[frm] OAK-4969 - Ensure binary properties  are loaded when processing a node

[frm] OAK-4969 - Ensure binary properties  are loaded when processing a node

[stefanegli] OAK-5023 : introducing applyNodeTypeOnSelf feature which changes 
the way

[stefanegli] OAK-5020 : adding withIncludeAncestorsRemove support to the

[stefanegli] OAK-5022 : introducing withIncludeSubtreeOnRemove to the 
OakEventFilter

[tomekr] OAK-5035: Implement mini-benchmark for the PersistentCache

[stefanegli] OAK-5039 : changing definition of STAR in a glob path to 
correspond the

[stefanegli] OAK-5011 : adding EventAggregator to the FilterBuilder which 
allows to

[stefanegli] OAK-5019 : introducing support for glob include paths to the

[stefanegli] OAK-5019 : removing duplicate path addition to includeCondition

[stefanegli] OAK-5021 : introducing support for file aggregation, or more 
generally

 

Test results:
All tests passed

About Jackrabbit cluster

[Liang]

Hi, all
   In our cluster environment, the Journal is very huge (about 60g), so we'd 
like to enalbing janitor configuration into repository.xml. As the wiki page 
said, there are 3 caveats after enabling the janitor. I can understand the 
first and third caveat, but not quite catch the second one as below. What does 
it mean? Does it mean we need do some extra thing (coding, configuration??) to 
make sure enabling janitor can work well?
  
You must make sure that all cluster nodes have written their local revision to 
the database before the clean-up task runs for the first time because otherwise 
cluster nodes might miss updates (because they have been purged) and their 
local caches and search-indexes get out of sync.


What I expected is that we only need to add janitorEnabled=true, janitorSleep 
and janitorFirstRunHourOfDay under Cluster element, and then the journal table 
could be purged as expected and no extra work that needs us to do


Please help me! Thanks.


Regards,
-Liang

Re: [REVIEW][API] Additions to JackrabbitEventFilter

[Stefan Egli]

(+oak-dev as it meanwhile has move to oak features alone)

I've committed OAK-5013 which introduces the OakEventFilter extension and
a number of such extensions (OAK-5019, OAK-5020, OAK-5021, OAK-5022,
OAK-5023).

While they should all in principle work I don't consider them as done yet
as the test coverage is minimal and there's room for code(-style)
improvement.

But the point of this heads-up is about the API of OakEventFilter that
should ideally not have to change anymore, so if you're interested pls
have a look.

Cheers,
Stefan


On 26/10/16 19:09, "Stefan Egli"  wrote:

>On 26/10/16 16:48, "Michael Dürig"  wrote:
>
>>... Just ensure we expose the required
>>functionality on the Oak side as a proper API. That is, interface and
>>utility only and proper package versioning...
>
>Opened OAK-5013 for that which is just about the API.
>(it's a beautified version of the previous patches)
>
>Cheers,
>Stefan
>
>

Re: [REVIEW][API] Additions to JackrabbitEventFilter

[Stefan Egli]

(+oak-dev as it meanwhile has move to oak features alone)

I've committed OAK-5013 which introduces the OakEventFilter extension and
a number of such extensions (OAK-5019, OAK-5020, OAK-5021, OAK-5022,
OAK-5023).

While they should all in principle work I don't consider them as done yet
as the test coverage is minimal and there's room for code(-style)
improvement.

But the point of this heads-up is about the API of OakEventFilter that
should ideally not have to change anymore, so if you're interested pls
have a look.

Cheers,
Stefan


On 26/10/16 19:09, "Stefan Egli"  wrote:

>On 26/10/16 16:48, "Michael Dürig"  wrote:
>
>>... Just ensure we expose the required
>>functionality on the Oak side as a proper API. That is, interface and
>>utility only and proper package versioning...
>
>Opened OAK-5013 for that which is just about the API.
>(it's a beautified version of the previous patches)
>
>Cheers,
>Stefan
>
>

Re: globbing: oak style vs sling style

[Stefan Egli]

I've created 

https://issues.apache.org/jira/browse/OAK-5039

to follow up

Cheers,
Stefan

On 31/10/16 14:18, "Stefan Egli"  wrote:

>Hi,
>
>As being discussed in [0] in OAK-5021 there are 2 different ways how
>globbing is currently defined in Oak vs in Sling. In Oak globbing is
>restricted to ** being 0-n path elements and * being 1 path element, while
>in Sling it is more generic in that * means 0-n characters excluding path
>boundaries.
>
>IIUC then the GlobbingPathFilter is basically where Oak implements this
>and
>it looks like this is not yet exposed, as that's internal to observation
>filtering only.
>
>So my suggestion would be to simply extend the GlobbingPathFilter's
>globbing
>definition to match that of Sling.
>
>Any objections?
>
>Cheers,
>Stefan
>--
>[0] - 
>https://issues.apache.org/jira/browse/OAK-5021?focusedCommentId=15622005
>ag
>e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment
>-1
>5622005
>[1] - 
>https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/p
>lu
>gins/observation/filter/GlobbingPathFilter.html
>
>
>

Re: globbing: oak style vs sling style

[Carsten Ziegeler]

I just would like to add that this is not Sling's invention, but the
pattern matching known to Java developers since more than ten years.
First time i've seen it was in Ant:

http://ant.apache.org/manual/dirtasks.html#patterns

I think the usage of the "?" is very rare and potentially not needed
(Sling doesn't support it)

Carsten

Stefan Egli wrote
> Hi,
> 
> As being discussed in [0] in OAK-5021 there are 2 different ways how
> globbing is currently defined in Oak vs in Sling. In Oak globbing is
> restricted to ** being 0-n path elements and * being 1 path element, while
> in Sling it is more generic in that * means 0-n characters excluding path
> boundaries.
> 
> IIUC then the GlobbingPathFilter is basically where Oak implements this and
> it looks like this is not yet exposed, as that's internal to observation
> filtering only.
> 
> So my suggestion would be to simply extend the GlobbingPathFilter's globbing
> definition to match that of Sling.
> 
> Any objections?
> 
> Cheers,
> Stefan
> --
> [0] - 
> https://issues.apache.org/jira/browse/OAK-5021?focusedCommentId=15622005
> e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1
> 5622005
> [1] - 
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plu
> gins/observation/filter/GlobbingPathFilter.html
> 
> 
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

globbing: oak style vs sling style

[Stefan Egli]

Hi,

As being discussed in [0] in OAK-5021 there are 2 different ways how
globbing is currently defined in Oak vs in Sling. In Oak globbing is
restricted to ** being 0-n path elements and * being 1 path element, while
in Sling it is more generic in that * means 0-n characters excluding path
boundaries.

IIUC then the GlobbingPathFilter is basically where Oak implements this and
it looks like this is not yet exposed, as that's internal to observation
filtering only.

So my suggestion would be to simply extend the GlobbingPathFilter's globbing
definition to match that of Sling.

Any objections?

Cheers,
Stefan
--
[0] - 
https://issues.apache.org/jira/browse/OAK-5021?focusedCommentId=15622005
e=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1
5622005
[1] - 
https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plu
gins/observation/filter/GlobbingPathFilter.html

[jira] [Commented] (JCRVLT-138) Unzip test-packages for easier maintenance

[Julian Sedding (JIRA)]

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

Julian Sedding commented on JCRVLT-138:
---

Thanks for the quick fix! Looks good to me and should make tests much more 
accessible.

> Unzip test-packages for easier maintenance
> --
>
> Key: JCRVLT-138
> URL: https://issues.apache.org/jira/browse/JCRVLT-138
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.30
>Reporter: Julian Sedding
>Priority: Minor
> Fix For: 3.1.32
>
>
> As discussed in JCRVLT-111 it would be easier for maintenance of tests, and 
> more accessible, if the content-packages used in tests were exploaded.
> This can be done relatively easily, as shown in an [example 
> project|https://github.com/code-distillery/filevault-oak-reindex-hook/blob/master/src/test/java/net/distilledcode/tools/InstallHookTestUtils.java#L39].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1767213 [1/4] - in /jackrabbit/commons/filevault/trunk: parent/ vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ vault-core/src/test/java/org/apache/jackrabbit/vau

[Julian Sedding]

Hi Tobi

Thanks for the change.

Note: some of the files from the extracted packages have Adobe headers
and other are missing the Apache license headers.

Regards
Julian


On Mon, Oct 31, 2016 at 2:55 AM,   wrote:
> Author: tripod
> Date: Mon Oct 31 01:55:37 2016
> New Revision: 1767213
>
> URL: http://svn.apache.org/viewvc?rev=1767213=rev
> Log:
> JCRVLT-138 Unzip test-packages for easier maintenance
>
> Added:
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/config.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/definition/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/definition/.content.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/filter.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/nodetypes.cnd
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/properties.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/.content.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/node_a/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/node_a/.content.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/.content.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/_rep_policy.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/config.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/definition/
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/definition/.content.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/filter.xml
> 
> jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/nodetypes.cnd
> 
> 

[jira] [Created] (JCR-4051) Release Jackrabbit 2.12.5

[Julian Reschke (JIRA)]

Julian Reschke created JCR-4051:
---

 Summary: Release Jackrabbit 2.12.5
 Key: JCR-4051
 URL: https://issues.apache.org/jira/browse/JCR-4051
 Project: Jackrabbit Content Repository
  Issue Type: Task
Reporter: Julian Reschke
Assignee: Julian Reschke






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jackrabbit 2.12.5 release plan

[Julian Reschke]

Hi all,

I'd like to cut Jackrabbit 2.12.5 on November 2.

The list of unresolved issues for 2.12.5 is empty:
https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.12.5%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC

I will start the release process on Wednesday if there are no objections.

Best regards, Julian

Re: segment-tar depending on oak-core

[Julian Sedding]

Hi all

My preference is also with a higher degree of modularity. Compared to
a monolithic application it is a trade-off that leads to both, higher
complexity and higher flexibility. Provided we are willing to change
and learn, I am sure we can easily manage the complexity. Numerous
benefits of the extra flexibility have been mentioned in this thread
before, so I won't repeat them.

As I understand it the Oak package structure was designed to
facilitate modularity very early on. As Jukka wrote back in 2012:

"[...] Ultimately such extra plugin components may well end up as
separate Maven components, but until the related service interfaces
and plugin boundaries are well defined it's better to keep all such
code together and simply use Java package boundaries to separate them.
That's the rationale behind the .oak.plugins package [...]"[0].

IMHO, now that the API boundaries are well defined (I hope), it would
be great to finally move the structure of the code-base and release
artifacts towards a more modular approach.

Regards
Julian

[0] http://markmail.org/thread/cs34a637dr26xscj


On Fri, Oct 28, 2016 at 8:29 AM, Francesco Mari
 wrote:
> Hi
>
> 2016-10-27 19:08 GMT+02:00 Alexander Klimetschek :
>> Maybe looking at this step by step would help.
>
> The oak-segment-tar bundle was supposed to be the first step.
>
>>For example, start with the nodestore implementations and extract everything 
>>into separate modules that is necessary for this - i.e. an oak-store-api 
>>along with the impls. But keep other apis in oak-core in that first step, to 
>>limit the effort. (And try not renaming the API packages, as well as keeping 
>>them backwards compatible, i.e. no major version bump, if possible).
>
> This didn't happen because of lack of consensus. See my previous
> answer to Michael Marth.
>
>>See how that works out and if positive, continue with more.
>
> The reaction to the modularization effort was not positive, so
> oak-segment-tar backed up.
>
>>
>> Cheers,
>> Alex
>>
>> Am 27. Okt. 2016, 03:48 -0700 schrieb Francesco Mari 
>> :
>> Something did happen: the first NodeStore implementation living in its
>> own module was oak-segment-tar. We just decided to go back to the old
>> model exactly because we didn't reach consensus about modularizing its
>> upstream and downstream dependencies.
>>
>> 2016-10-27 12:22 GMT+02:00 Michael Marth :
>> fwiw: last year a concrete proposal was made that seemed to have consensus
>>
>> “Move NodeStore implementations into their own modules"
>> http://markmail.org/message/6ylxk4twdi2lzfdz
>>
>> Agree that nothing happened - but I believe that this move might again find 
>> consenus
>>
>>
>>
>> On 27/10/16 10:49, "Francesco Mari"  wrote:
>>
>> We keep having this conversation regularly but nothing ever changes.
>> As much as I would like to push the modularization effort forward, I
>> recognize that the majority of the team is either not in favour or
>> openly against it. I don't want to disrupt the way most of us are used
>> to work. Michael Dürig already provided an extensive list of what we
>> will be missing if we keep writing software the way we do, so I'm not
>> going to repeat it. The most sensible thing to do is, in my humble
>> opinion, accept the decision of the majority.
>>
>> 2016-10-27 11:05 GMT+02:00 Davide Giannella :
>> On 27/10/2016 08:53, Michael Dürig wrote:
>>
>> +1.
>>
>> It would also help re. backporting, continuous integration, releasing,
>> testing, longevity, code reuse, maintainability, reducing technical
>> debt, deploying, stability, etc, etc...
>>
>> While I can agree on the above, and the fact that now we have
>> https://issues.apache.org/jira/browse/OAK-5007 in place, just for the
>> sake or argument I would say that if we want to have any part of Oak
>> with an independent release cycle we need to
>>
>> Have proper API packages that abstract things. Specially from oak-core
>>
>> As soon as we introduce a separate release cycle for a single module we
>> have to look at a wider picture. What other modules are affected?
>>
>> Taking the example of segment-tar we saw that we need
>>
>> - oak-core-api (name can be changed)
>> - independent releases of the oak tools: oak-run, oak-upgrade, ...
>> - independent release cycle for parent/pom.xml
>> - anything I'm missing?
>>
>> So if we want to go down that route than we have to do it properly and
>> for good. Not half-way.
>>
>> Davide
>>
>>

[jira] [Created] (JCRVLT-140) Add support for transforming subpackages into dependency sets

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-140:
---

 Summary: Add support for transforming subpackages into dependency 
sets
 Key: JCRVLT-140
 URL: https://issues.apache.org/jira/browse/JCRVLT-140
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Reporter: Tobias Bocanegra


With the new introduction of dependency handling, it is now possible to treat 
subpackages differently, by "exploding" them into a set of packages that depend 
on their parent package. this allows to upload and "explode" several uber 
packages and have them installed the subpackages in the correct order.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCRVLT-139) Add support for package installation listeners

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-139:
---

 Summary: Add support for package installation listeners
 Key: JCRVLT-139
 URL: https://issues.apache.org/jira/browse/JCRVLT-139
 Project: Jackrabbit FileVault
  Issue Type: Improvement
  Components: Packaging
Reporter: Tobias Bocanegra






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes

[angela (JIRA)]

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

angela commented on JCR-4050:
-

There exists in fact a way to create users with existing password hashes and 
which is actually intended for synchronizing content between repositories: the 
JCR xml import. If import of the protected user properties is properly enabled 
this would exactly do, what you were looking for. Since the Xml import by 
default ignores protected JCR nodes/properties, we defined plugins for both 
Jackrabbit Core and Oak that provides that missing functionality.

For Oak it's documented at 
http://jackrabbit.apache.org/oak/docs/security/user/default.html#XML_Import
For Jackrabbit Core there exists no official documentation but the mechanism is 
the same: configure the protected item imports you wish to be active in the 
workspace.xml of your target workspace. For example something like this:

{code}
   
   [...]








{code}

Hope that helps


>  Allow creation of users with existing password hashes
> --
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes 
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting 
> passwords from existing users; we have no public API facing way to create 
> users with existing password hashes. We currently have to resort to using 
> reflection, grabbing internal tree objects, and a bunch of nastiness that we 
> would love to avoid with this change.
> Other consumers may also find this useful. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCRVLT-136) Add import option flags to enforce dependency checks

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-136.
-
   Resolution: Fixed
Fix Version/s: 3.1.32

fixed in r1767220.

new ImportOptions: {{DependencyHandling}} :

{code}
/**
 * Defines how package dependencies influence package installation and 
un-installation.
 */
public enum DependencyHandling {

/**
 * No dependency checks are enforced
 */
IGNORE,

/**
 * Dependency checks are performed but not enforced. If a dependency is 
present but not installed, it will be
 * installed prior to installing the referencing issue. However the 
installation will proceed, even if the dependency is missing.
 *
 * Un-installation will automatically uninstall referencing packages.
 */
BEST_EFFORT,

/**
 * Dependency checks are performed but not enforced. If a dependency is 
present but not installed, it will be
 * installed prior to installing the referencing issue. If a dependency is 
not present, installation fails.
 *
 * Un-installation will automatically uninstall referencing packages.
 */
REQUIRED,

/**
 * Full dependency checks are enforced. Packages with missing or 
uninstalled dependencies are not installed and
 * packages that are dependencies of other packages cannot be un-installed.
 */
STRICT

}

{code}



> Add import option flags to enforce dependency checks 
> -
>
> Key: JCRVLT-136
> URL: https://issues.apache.org/jira/browse/JCRVLT-136
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.1.30
>Reporter: Tobias Bocanegra
> Fix For: 3.1.32
>
>
> Package dependencies are not honoured by package installation.
> add import option to:
> - prevent installation of package (and/or subpackage) if a required 
> dependency is not installed
> - prevent uninstallation of package (and/or subpackage) if a required 
> dependency is still installed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)