Hi guys, oldcore contains references to Portlet API 1.0 in various API.
There is several issues:
1) Thoses API are useless since most of the code expect a servlet and
would never work inside a Portlet so that make this API totally
useless
2) It's a real pain for things like
https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-portlet (a
portlet proxy/translator in front of XWiki) since it makes impossible
to use Portlet API 2.0 (we had to create our own special branch were
we remove all reference to 1.0 API in oldcore)
3) XWiki cannot work without the portlet jar even when used as Servlet
which is quite ugly
Since we are starting a new major version and it's a breaking change I
propose to do it now.
Here is my +1
--
Thomas Mortagne
Dear community,
I would like to request for a new contrib project to store the Mail
Archive application I'm currently writing.
Name: xwiki-application-mailarchive
Description: A mailing-list archive application.
- For now a GitHub project to store sources should be fine. My
username on GitHub is "jbousque".
- For Jira it might be useful to have a project once the application
is released "officially", that is still not the case. Meanwhile the
generic project is ok for me.
- There is a specific page in Design space on xwiki.org :
http://dev.xwiki.org/xwiki/bin/view/Design/MailArchiveApplication ,
but for now no extension has been added. I would like if possible to
test my extension (automatic install with dependencies) before
publishing it
The Design page also gives some info about the current state and
progress, and some screenshots. There is many remaining work, but it
begins to look like something usable. The bad side is the lack of unit
tests most of all ...
A question : the groupId "org.xwiki.contrib" is to be used, do I have
to use this exact groupId or can there be sublevels if needed ?
If so I would use org.xwiki.contrib.mailarchive as groupId.
Thanks,
Jeremie
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.
At least in my office, the "big thing" these days is community building.
The intent to materialize "communities", that could be around subjects as
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.
For example community members could be a ldap or xwiki group of users.
Shared space for the community could be a xwiki Workspace, with workspace
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).
Comes also the idea that "flavors" could have some hierarchy, for example,
the "dev" flavor could be built on top of such "community" flavor,
extending it with other specific integrations (jira, ...).
Also brings the idea of optional dependencies between extensions. 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 :-)
BR,
Jeremie
Hi,
We were 9 xwikiers at FOSDEM this week-end and I wanted to take the
occasion to give some feedback on what I saw there.
The Community Dev Room
-----------------------------------------
First XWikiers participated in the devroom co-organized by Sergiu:
"Community Development and Marketing". The great news is that the room was
full quite a big amount of the time. It was not a huge room but well placed
(in the "original" area of FOSDEM which is still quite active). I think it
shows more and more interest of people for this subjects which are less
usual at FOSDEM which is very technological. Kudos to Sergiu for
co-organizing this dev room. There was also a keynote from Kohsuke
Kawaguchi (creator of jenkins) on how the jenkins community was build which
was on a similar subject as the dev room (I'll give some feedback on the
talk below).
Sergiu has a presentation about "how to cope with a proliferation of tools
in your community" which presented how XWiki can be used to be a portal to
all the contents of all the tools you have in your community (aka "the dev
flavor). The content of the talk was great but to my taste it was really
missing screenshots to show practically what happens. There was a mini demo
at the end but it was not enough to really make people realize how great
xwiki.org is :) But the idea of the presentation is great and if we can
spend a bit of time to not necessarly make the flavor, but publish the
different pieces of xwiki.org as extensions, including some simple macros
we are using (like how we integrate nabble). There was the 1M$ question of
if we can migrate existing wikis to which we could have answered a bit
better as we do have a few migrators for some specific wikis (Mediawiki,
dokuwiki) but nothing fully done and fully generic. This is another area
were we could spend some time making some specific migrators easier to use.
If there are any contributors that would like to help out improving and
publishing the migrators and "dev extensions" on extension.xwiki.org as
well as document how other communities could use our tools, it would be
very useful to help spread the XWiki work out there. Sergiu should publish
his slides and maybe somebody can improve them with screenshots.
Vincent and myself had a "devil (business) and angel (open source)"
presentation on "Combining Open Source ethics with private interests". 20
minutes was a bit short to cover this subject fully in details but it was
great to be able to share our experience on this. The room was quite full
when we did this presentation and there were a few questions which I
believe showed the interest of participants with this subject. Vincent will
publish the slides although it's not easy to follow without the additional
"talking". We should definitively try to do this again.
MySQL and Security
------------------------------
I attended a few MySQL presentations as well as some security
presentations. There seems to be some interesting improvements in InnoDB in
MySQL 5.5 and 5.6 (currently RC) and even MariaDB and Percona have some
work that improve InnoDB (with XTraDB). As we are planning to work on
performance we should look into testing how XWiki behaves on MySQL 5.1 to
5.6 and compare the performance also with Postgres. In any case we should
follow what is happening in this area. On security there was a presentation
about OWASP ZAP (
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) and attack
proxy to test the security of Web Applications. This is something to look
at for the Thomas D's coming work on security.
Kohshuke presentation on Jenkins community
-------------------------------------------------------------------
On the "community" subject there was interesting presentations about "how
to cope with assholes in your community" and the presentation of Kohshuke.
To summarize very quickly while Kohshuke says part of the big reasons why
jenkins has been succesful is "good software" and "being there at the right
time" he would like to believe that the way the community is run and the
software is architectured has a lot to do with this success. Some important
items:
- small core with apis, many extensions, extensions are "first-class
citizens" of jenkins
- very extensible
- very open to contribute an extension with almost automatic commit right
(with an IRC bot to get a rights)
What we can learn for XWiki
-----------------------------------------
There are a few things to learn here for XWiki I believe:
XWiki has a lot of what is said here, particularly the extensibility but we
could "finish" things a bit more with these learnings in mind.
XWiki is very extensible in many areas (but not all, like the old core). It
is very easy to publish an extension, particularly a XAR file on
extensions.xwiki.org and we have extension manager to install this
extension. However there are a few things we can do better:
1/ On the java side, contributing is still difficult. The core is still big
and not well defined. In the "platform" repository we have many different
things, including modules that are not vital to the XWiki core and that
could be maintained by contributors. Our development rules and
methodologies are very "strict" when it comes to the "platform", "commons"
or "rendering" and since many many things are published there it's not easy
to participate there.
If we separated a bit the "real core" from the additional modules that
depend on the core apis but are not as critical to the core, and we move
the additional modules to an area with potentially less stricts rules of
development and where each developer can decide his own rules, maybe we
would greatly improve potential contributions. It's also a question of how
we "consider" the extensions and we publish information about them and
recognize them when they end up in the default install. More on this below.
2/ On the xar/scripting side, it's "almost" easy to publish something and
make it available thanks to EM but there are a few quirks that we need to
solve:
- Exporting a XAR is not fully supported by the core (we need Admin Tools
and it's not enough documented).
- Committing your work is not easy which makes it more complicated to get
contributors to extend an existing extension.
But the good news is that we are quite close:
- AppWithinMinutes has an extension to publish an application on Extension
Repository
- SVN and GitHub app allow to commit XWiki pages
- Maven allows to build and release an XWiki app
- Admin Tools has ways to export multiple pages
- XEM code has an "Application Descriptor" which could be useful for not
AWM code
If we bind all these together a bit more we can have a killer. Let's image
the following:
1/ In an admin area you go to "Extensions" and you have a button to "create
a local extension" and can add XWiki pages to your extension which would
add your pages to an "Extension descriptor"
2/ AWM would automatically use this extension descriptor.
3/ You would have a way to:
- ask for a git repository for your extension
- commit your extension from XWiki
- release your extension from XWiki and publish it on extensions.xwiki.org
- allow another user to install this extension using EM and then decide
to fork it, modify it and commit the changes and create a pull request for
the changes
- finish the contribution loop
4/ On extensions.xwiki.org you could see who the contributors are for the
extension and what they committed.
Then you have an even more powerful way to contribute to XWiki, wether it
is an AWM application or just a snippet of code.
Aside from that we should make it a bit easier through documentation or
tools mainly) to publish java code as it is still slightly complicated to
make it easily installed using EM.
More important even would be to continue improving AWM to make it easier to
add Javascript, CSS or REST apis to an application but this is another
story for more complex applications.
This is food for thoughts to allow XWiki to get more help from new
committers which is a great solution to help XWiki spread more. On the
spreading subject, I also think we should make more effort to publish some
"mashup" macros or snippets and publish them both on
extensions.xwiki.orgas well on the other projects extensions or
plugins pages. This would help
show how easy it is to integrate XWiki with other tools.
I was quite happy with this year's FOSDEM. It's getting more and more
interesting. Open Source is alive and kicking.
We could push for happing a "Web Application Dev Room" (we tried to get a
"wiki one"), as there is not much on this subject.
There was a "web development" track but it was a bit empty. Maybe this is
an area to work on to get Wikis, CMS tools, Web and Javascript frameworks
presented.
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi,
I'd like to add require.js to XWiki to be included in every page just before prototype.js.
I would also like to add jQuery to our resources directory but only make it available to
scripts which "pull it in" using require().
I have come to the conclusion that jQuery is a de-facto standard and even if we don't port
to it, we should make it available to our users. Require.js is an implementation of the
Asynchronous Module Definition standard which will allow us to use both jQuery and prototype
relatively harmoniously.
I think it's obvious that if javascript rich webapps are going to scale, they need
modularity and I've reviewed AMD and the main competitor CommonJS and concluded that AMD
will provide the user with better page load time by asynchronously loading modules according
to a dependency tree while CommonJS blocks on each call to require().
I would like to see us move away from prototype but it provides more functionality than
jQuery including an OOP framework and while there are other libraries which show promise,
I don't feel right proposing a best practice without first porting some code to it to see
what issues arise so IMO we should begin using require.js but accept that prototype still
has it's place.
So I propose:
Include require in the header vm.
Include jQuery but only if a script "require()'s" it.
Establish a best practice of using require() and define() instead of global variables but
accept that prototype.js still has it's place.
WDYT?
Caleb
miscellany:
------------------------------
require.js vital statistics:
Dual licensed BSD and MIT.
Latest Release: 2.1.2
1,993 lines before minification
24,621 lines in every .js file in the /tests/ directory.
Used by:
https://github.com/adobe/brackets/https://github.com/ajaxorg/cloud9 (https://c9.io/)
http://browserquest.mozilla.org/http://www.bbc.co.uk/frameworks/barlesque/examples/global/requirejshttp://www.officejs.org/
-----------------------------
Optimization:
require.js comes with a tool for linting, compiling (using Closure Compiler),
and linking AMD modules together based on their dependencies. Complex projects
with many js files can be can be compiled into a single "statically linked" js file.
It supports Rhino so it could be included in the maven build.
-----------------------------
My experimentation with require.js:
I use the require.js legacy shim to make jquery.sheet function as a require.js module
without making any direct changes to jquery.sheet.
I was able to move the code from XWiki to the filesystem (file:///) a total change
of the directory structure and only needed to change the main example.html file.
I was able to include the content in an iframe simply by defining a require.js plugin
see: http://requirejs.org/docs/plugins.html for loading through an iframe and changing
the require() call to require the iframe'd sheet.
https://github.com/cjdelisle/jquery-sheet-amd
Hi Devs,
As you may have noted from a previous mail, I have given a try to skin
XWiki differently, based on Bootstrap. There is certainly many ways to get
it done, but IMO, building over any pre-made css solution requires an
adaptation of the HTML generated.
In the early days of XWiki, the were few places were we have HTML
generated. Most of the html produce came from three major places:
1) .vm templates including macros.vm
2) java generated (#display())
3) XWiki tech document
While 2) and 3) either provide very basic markup or customizable one and
are not so much, and 1) was fully customizable by skins, to work out a new
skin was not too complex.
Today however, the UI of XWiki has considerably increase its complexity,
and the source of HTML has followed, added to the above 3:
4) XWiki and Java macros
5) JavaScript (ie: annotation UI, comments preview)
Changing all these places has become really more painful. There is no
central place, and a lot of hidden dependencies between UI components
exists. Worse examples are those written in JS, that hook into the UI.
I should admit that I have not a clear idea of the best way to improve
that, but my feeling is that changing so much places simply to adapt our
wiki skin to the "a la mode" skin solution (something that will happen
again) is not nice.
So this thread is now open for anyone to discuss the situation and for
anyone interested to provide its input to the discussion.
Looking at what I face building the UI with bootstrap, here is what I
noticed:
1) Bootstrap customize standard tags, without any css class associated
2) Bootstrap provide standard css classes to skin a given kind of UI
component
3) Bootstrap use these class and custom attribute to inject JS interactivity
All these are really clean methods and work really well at building very
simple html construct while providing nice looking and easy interface.
Let's take a concrete example, to build a button, you may use either an a
tag, an input tag, a button tag or whatever, and set it a 'btn' css class.
You may complement it with additional 'btn-primary', 'btn-success', ... css
classes, to choose the kind of button you really want.
However, in our XWiki UI, there no single place where we construct buttons,
we do so in some velocity macros of macros.vm, we do so in .vm of the UI,
we also do so in javascript, and finally in some wiki documents, maybe we
also generate some in a java component.
All those buttons are usually built the same, with a very similar HTML, but
there is no central place where the button markup is produced.
And the same is true for most UI component. You may say we don't care, and
CSS could solve them all, making any kind of markup look the way we want.
But, we will loose the benefit of using existing CSS solution. And there
are interesting benefit to that, since those solution gets customized, see
BootsWatch for example.
Therefore, it seems to me that we need something like an UI generator, so
that when you build a application, you would simply says, I want a primary
button here, a secondary button there, and it gets created both the way it
should for your apps to use it, but also for the UI design we want to use.
Defining a list of these UI component is not simple, but we may take
Bootstrap as a starting point. There is in Bootstrap a large number of
control already, that should cover many UI possibilities.
How to provide that UI component to all the places we need it may be less
obvious. For example, we need to create button from .vm, XWiki document,
XWiki and java Macros, and even from javascript. Also defining how you
could expect to interact with each control, from Javascript or from java on
the server needs clarification.
I have not yet googled, but there may be existing experience regarding
these matters on other project. Not reinventing the wheel is always better.
Your ideas are welcome.
IMO, we really need that if we want our Skin 4.x to be really more usable
for customization.
WDYT ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO