Issue 97633 - Please publish com.sun.star.deyployment.* API
Summary: Please publish com.sun.star.deyployment.* API
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: jsc
QA Contact: issues@api
URL: http://markmail.org/message/22nxn66zn...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-29 08:20 UTC by tobiaskrais
Modified: 2013-02-24 21:06 UTC (History)
1 user (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 tobiaskrais 2008-12-29 08:20:26 UTC
Please publish the API of the package com.sun.star.deyployment.*

Use cases can be:
1. A self updating extension.
2. A external application relies on an installed extension and can install it,
if not present.

The second use case is already reality. I am working for a company that has a
OOo communication application. This application stores an initilized Spring
Framework in a Singleton that is deployed in an extension.
Comment 1 jsc 2008-12-29 08:47:10 UTC
This API is not really intended to be used directly but i can understand your
needs but ...

1. we don't want that single extensions do it on their own. We want a well
defined workflow. It's also for security. That means the office checks for
updates of any installed extensions automatically or when the users request it
explicitly. Extension developers can easy update their extension in the
extension repository or can provide an own update url (own repository). The
official repository is recommended.  

2. This can be easy achieved by using the unopkg command line tool as well. Well
using the API is of course easier here because you don't have to search the
office if you use the simple bootstrap.

We haven't published the API because we are working on improvements in this area
and we want to keep the flexibility of easy changes. But we are thinking about a
way to become more flexible with published API's in the future. That means API's
might be change with new major versions. Not defined yet but i think we need
this flexibility in the future ...

I set this request on invalid because it's the normal process to publish API's
over time. We don't need requests for that -> too much overhead. Use the current
API, i don't expect big changes in the near future. Check it early with new
versions and adapt your code if necessary. 
 
Comment 2 jsc 2009-01-09 09:24:38 UTC
close