7 Feb
2013
7 Feb
'13
8 p.m.
Hi Vincent,
Le 7 févr. 2013 18:12, "Vincent Massol" <vincent(a)massol.net> a écrit :
as
workspace
"community", "workgroups", "groupware", etc.
extension can
depend on other extensions :)
I think so, but it's not really needed to materialize that optional
dependency at EM level I think. Showing info on extension page might be
enough.
BTW, I'm not sure "optional" in maven has exactly the same meaning,
it's
more used to remove a dependency from transitivity by default - but that
dependency is in no way optional for the module that declares it.
ExtensionManagerScriptService
Hi Jeremie,
On Feb 5, 2013, at 2:28 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
wrote:
> Hi xwiki devs,
> Don't know if it's really the right place, but something strikes me when
> re-reading the thread about XWiki development flavor, fosdem feedback
from
> Ludovic, last extensions posted on xwiki.org, and
my own requests /
> use-cases I have in my office ..., and I just wanted to share my
thoughts
with no
particular expectation.
This is great to share, thanks for doing that :)
> At least in my office, the "big thing" these days is community building.
> The intent to materialize "communities", that could be around subjects
> business interests, technical interests, skills,
...
> Currently our difficulty is that we have some "bricks", but they are
spread
> amongst several tools and not integrated.
> For example mailing-lists were defined in mail server (in fact,
> distribution lists with owner), the reason why I created the MailArchive
> application in first place, to archive these mails somewhere browsable
and
> searchable.
>
> But when I see the "Newsletter application", the "Meeting
application",
the
Workspace
feature, I can't help but think that ideally all these
should/could be linked together to materialize that "community" thing.
Indeed
> For example community members could be a ldap or xwiki group of users.
> Shared space for the community could be a xwiki Workspace, with > owner as guardian. Newsletters templates could be
automatically
generated
> for that community, using community members as
first newsletter target
> (using a mailing-list address or a list of distinct persons). Other
persons
> of a community could have a "view"
access to it (workspace, newsletter
> targets) if they decide to (or are volunteered into by community owner).
> The workspace of a community could come from a template, showing
configured
> newsletter, and a default mail archive with view
on specific
> mailing-list(s) for that community. There could be a documentation part
> (space?) with easy export to .doc/.pdf of multiple pages. The "topics"
of
> that community could be materialized as blog
categories, and suggested
as
> tags for othere pages...
> That "flavor" would not be particularly "social" (meaning,
connected
with
> facebook...) nor "dev", still reuse
existing components and add some
glue
> between them. As far as I know it could be merely
a Workspace template,
but
I don't
know if such workspace template could easily be packaged and
contributed as an extension (should be).
Yes there's a need for that flavor. There are various ways to call it:
> Comes also the idea that "flavors" could have some hierarchy, for
example,
the
"dev" flavor could be built on top of such "community" flavor,
Flavor do have hiearchies since a flavor is just an extension and extending it with other specific integrations
(jira, ...).
Also brings the idea of optional dependencies between extensions.
Maven supports "optional" but the EM doesn't ATM AFAIK. Thomas?
> Is there
> an (easy) way to know, for an extension, if a prerequisite extension is
> installed ? (something from EM public API for example). Currently I just
> check for specific page existence, or for specific $service... call, to
> infer that another extension is already installed. For example you could
> decide to create meetings from mail archive app, if and only if the
Meeting
> application is already installed. Integration of
remote systems is nice,
> but cross-integration of existing extensions would be even nicer to
start
with :-)
There's a script service for that. I don't know if it's documented:
For example:
$services.extension.getInstalledExtension("extensionid", "mywiki")
it'll return null if the extension isn't installed.
Great, thanks ! I'll use that now it's far more clean.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs