Issue 78376 - Provide extension dependencies for unpublished API subsets
Summary: Provide extension dependencies for unpublished API subsets
Status: ACCEPTED
Alias: None
Product: utilities
Classification: Unclassified
Component: code (show other issues)
Version: 680m113
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-13 11:56 UTC by thb
Modified: 2017-05-20 11:33 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2007-06-13 11:56:44 UTC
As already discussed in dev@extensions (the thread originating from this post:
http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=705), it would
be quite useful if extensions could depend on certain properties of unpublished
UNO API.
Comment 1 thb 2007-06-13 11:57:41 UTC
target, cc list
Comment 2 Stephan Bergmann 2007-06-13 12:58:13 UTC
@thb:  This ought to be the other way around.  You tell me that you need a
specific dependency named N that checks that the (unpublished) UNO type system
entities E1, ..., En are in the form they have in OOo version V.  Then I can
implement that specific dependency.  I cannot implement a generic dependency

  <unpublished-UNO-API entities="E1, ..., En" as-in-version="V"/>

(What I *could* do in this issue is build the foundations into OOo so that
implementing such specific dependencies later on would become easy.  However, I
am reluctant to build anything into OOo until its need is proven.)
Comment 3 Stephan Bergmann 2007-06-13 13:39:57 UTC
[A phone call with af just revealed that it could be possible after all to have
a generic dependency

  <unpublished-UNO-API entities="some representation of the type information for
E1, ..., En"/>

that brings along all the necessary information to check against, although
writing down such a dependency (in an extension description.xml) could be rather
laborious.]
Comment 4 thb 2007-06-13 14:58:50 UTC
@sb: then please do so. I need this for the css::rendering & css::geometry part
of the API (from what I can tell you today - and if you don't want this
integrated, I'll also gladly take patch files or a ptr to a never-integrated CWS).
Comment 5 thb 2007-06-13 15:00:29 UTC
integrated _prematurely_, that should have read...
Comment 6 Stephan Bergmann 2007-06-13 15:09:11 UTC
@thb:  "then please do so."  Do what?  The "Additional comments from sb Wed Jun
13 12:39:57 +0000 2007" stuff?  Do we really want that (despite the "although"
part)?
Comment 7 thb 2007-06-13 15:43:39 UTC
@sb: yes to your second question. Yes to your third question as well - it offers
a nice flexible way (IMO) to handle this issues, without constant code changes.
Comment 8 Stephan Bergmann 2007-06-13 15:47:26 UTC
...and probably is the easiest to implement.  ;)
Comment 9 Mathias_Bauer 2007-12-04 14:47:48 UTC
according to release status meeting -> target 3.x
Comment 10 Marcus 2017-05-20 11:33:33 UTC
Reset assigne to the default "issues@openoffice.apache.org".