Hello,
First of all sorry for the my english, I hope it's understandable.
For the multiwiki plugin (mostly used for XEM product) needs I had
started to make some JAVA tools mostly for plugins development that
can be useful for others. I will expose you the ideas to let everyone
discuss around and see what I can change. First implementation (to
illustrate) of theses ideas are in jira.
SUPERCLASS:
http://jira.xwiki.org/jira/browse/XWIKI-1576
First the "SuperClass" concept: not very original (inspired by
"com.xpn.xwiki.plugin.userdirectory.Group" class), it's a Xwiki Class
and Xwiki Object management tool. It automate some very common actions
and assure that needed Class document exist and is valid.
It's composed in two interfaces and their abstract default
implementations : ISuperClass (and AbstractSuperClass) and
IsuperDocument (and IsuperDocument).
SuperClass : manage the Xwiki Class document :
- first it assure that when using it the class exists in the
database with all needed feelds. Not only the Class but also the
ClassSheet and the ClassTemplate documents.
- it generate, based on the actual pseudo xwiki product
implementation norm, all the "ClassName", "FullClassName",
"ClassSpace", "ClassSheetName", etc.
SuperDocument : manage document containing one instance object of this
XwikiClass : just encapsulate XwikiDocument and Document and simplify
creation, saving, deleting, merging.
These two java classes had to be extended with the type we want to
manage (Group, User, Application, Wiki, etc.).
XWIKI APPLICATION:
http://jira.xwiki.org/jira/browse/XWIKI-1577 (also a example of
"SuperClass" use)
To create a new sub wiki in XEM from template I need to determine in
the "template" wiki which document have to be copied and which
included. For this I think that have a real "Xwiki Application"
descriptor can be very useful. My implementation is composed in a
mainly document that contains all application configuration:
- application name (that can be different from Document name)
- other applications dependencies
- document that application contains (that is not in other
applications dependencies)
- in theses documents which have to be included
and other field that I had not implemented yet but can be very soon:
- plugins dependencies
- in theses document which have to be linked (need that XWiki
support this concept)
For now my "application packager" just give to the actual xwiki xar
packager all the documents including applications descriptors
documents and make a xar file with all this. I think an other format
that a maven plugin can parse like XML application descriptor to
generate the package combining all the applications dependencies can
be made later.
Regards,
Thomas
Hi,
We've just committed the patch for XWIKI-1459 yesterday. However we
may need to rollback it.
Let me explain the situation:
1) It's a big and dangerous patch
2) The Curriki project is currently building on top of XWiki trunk
and they're doing some important release soon.
3) They understand that using XWiki trunk is risky and they're going
to branch off xwiki trunk real soon (I heard it's planned for next week)
4) They have some test server and it seems the recent commit broke a
few things. No investigations done yet.
As a consequence, they're asking us if we could rollback that patch
and release 1.1M4 without it so that they can branch at 1.1M4. We can
then apply the patch after.
The problem is that 1.1M4 was supposed to be our last release with
new features and 1.1M5/M6 were supposed to be 1.1RC1/RC2 till the
final release planned for the 3rd of September.
I don't think we'll be able to release a good 1.1 version if we only
have one release for hunting down bug fixes. I also think Curriki is
right in that committing such a big change one or 2 days before a
release is asking for trouble...
Thus I'd like to propose the following:
A) We rollback the patch and release 1.1M4 without it
B) We shift the final 1.1 release by 15 days - New date: 17th of
September. We add one release: 1.1M5 and then 1.1RC1 and 1.1RC2
C) We add this patch in 1.1M5. However we don't generally allow any
other important change unless there's a good reason. I.e. we consider
1.1M5 almost like a RC except for this patch
WDYT?
Thanks
-Vincent
Hi Tharindu,
(I've copied the dev list, please send all dev related information to
the list please so that we're all on the same page)
See below.
On Aug 6, 2007, at 8:34 AM, tharindu jayasuriya wrote:
> Hi Vincent,
>
> Sorry about the late reply.
>
> I have mistaken the XWiki account information with object web details.
>
> Tharindu - tharinduj
>
> Asiri - asiri (newly created)
Done. You can now do commits on xwiki-sandbox/xeclipse.
> ----------------------------------------------------------------------
> ------------
>
> Also, we need some help regarding XEclipse off-line. We are
> struggling bit to find a place to start development. And one more
> question, do we need to complete the off-line operation mode within
> GSoC time period ? we're having trouble with academic work load.
I think you need to provide a simple offline feature which is the
ability to:
- save pages locally (I recall there's an easy eclipse api for this)
- ability to choose what to download from the server: a page, a full
space or a full wiki
- ability to check if the page isn't more recent on the server on
save and if so warn the user and let him decide what to do: overwrite
the server version or cancel
- ability to refresh one's own copy of saved pages with the server's
versions
Basically this means everything except the hard part which is the
synchronization.
Let me know if this is possible but I don't think this is too hard to
do and it's important for such a tool I think.
Now I haven't reviewed what's left you have to do for 1.1M2 but that
needs to be finished as a priority.
Let me know if you have any schedule issues with this and we'll try
to find a solution. I'll work on the m2 build this coming week to
help you.
Thanks
-Vincent
> On 8/4/07, Vincent Massol <vincent(a)massol.net> wrote:
> Hi Tharindu,
>
> I've tried adding both of you but your ids don't exist on
> forge.objectweb.org...
>
> I've committed xeclipse into xwiki-sandbox but you don't have
> write access yet as I couldn't add you...
>
> Thanks
> -Vincent
>
> On Aug 3, 2007, at 5:56 PM, tharindu jayasuriya wrote:
>
>> Hi Vincent,
>>
>> On 8/3/07, Vincent Massol <vincent(a)massol.net > wrote:
>> Hi Tharindu/Asiri,
>>
>> I have reviewed the patch and it looks good. Only potential issue
>> is the package name you've used: org.xwiki.plugins. So far we've
>> used com.xpn.xwiki.*. However you're correct that we want to move
>> to org.xwiki. That said we need to decide if we want to do the
>> move right now for the Eclipse extension. I think it's a good idea
>> to do so and the strategy would be that any new extension/plugin
>> or any component in the new architecture should be located in the
>> org.xwiki package. What do others think?
>>
>> I'm going to commit it to xwiki-sandbox for now (till we have a
>> maven2 build for it, then I'll move it to xwiki-extensions/
>> eclipse) and we have already voted to give you access to it.
>>
>> Thanks a lot. We were thinking about moving into implementing the
>> off-line operations asap, i think we need to take few design
>> decisions upfront regarding off-line operations (mainly issues
>> regarding synchronization). I'll make a post once we have thought
>> about an initial idea so that we can optimize it on the dev list.
>>
>> I'll just need your ObjectWeb user id to give you write access.
>>
>> Tharindu - tharindujayasuriya
>>
>> Asiri - asiri
>>
>> Thanks.
>>
>> - Tharindu & Asiri
>>
>> Thanks
>> -Vincent
>>
>> On Jul 31, 2007, at 2:45 PM, Vincent Massol wrote:
>>
>>> Hi Tharindu,
>>>
>>> I'll review this latest patch later today or tomorrow.
>>>
>>> Thanks
>>> -Vincent
>>>
>>> On Jul 28, 2007, at 7:32 PM, tharindu jayasuriya wrote:
>>>
>>>> Hi All,
>>>>
>>>> Attached are the latest sources and binaries of XEclipse m1.
>>>>
>>>> Issues Fixed,
>>>>
>>>> 1. All Jigloo dependencies removed.
>>>>
>>>> 2. Code documentation improved according to instructions from
>>>> Vincent.
>>>>
>>>> 3. Back-End XML RPC's patched to suite XEclipse (Asiri)
>>>>
>>>> http://jira.xwiki.org/jira/browse/XWIKI-1520
>>>>
>>>> http://jira.xwiki.org/jira/browse/XWIKI-1521
>>>>
>>>> http://jira.xwiki.org/jira/browse/XWIKI-1524
>>>>
>>>> Let's hope this would finalize XEclipse m1 ... :)
>>>>
>>>> Hoping to hear from you soon...
>>>>
>>>> Thanks.
>>>>
>>>> - Tharindu & Asiri
>>>>
>>>> On 7/16/07, Vincent Massol < vincent(a)massol.net > wrote:
>>>> Hi Tharindu,
>>>>
>>>> I have done a first pass on the code review and I have a few
>>>> comments:
>>>>
>>>> 1) You seem to have use Cloudgarden's Jigloo and unfortunately
>>>> the license isn't good enough for us so we cannot use it...
>>>> Here's what it says in the generated file:
>>>>
>>>> /**
>>>> * This code was edited or generated using CloudGarden's Jigloo
>>>> SWT/Swing GUI Builder, which is free
>>>> * for non-commercial use. If Jigloo is being used commercially
>>>> (ie, by a corporation, company or
>>>> * business for any purpose whatever) then you should purchase a
>>>> license for each developer using
>>>> * Jigloo. Please visit www.cloudgarden.com for details. Use of
>>>> Jigloo implies acceptance of these
>>>> * licensing terms. A COMMERCIAL LICENSE HAS NOT BEEN PURCHASED
>>>> FOR THIS MACHINE, SO JIGLOO OR THIS
>>>> * CODE CANNOT BE USED LEGALLY FOR ANY CORPORATE OR COMMERCIAL
>>>> PURPOSE.
>>>> */
>>>>
>>>> We cannot use Jigloo because we want commercial companies using
>>>> XWiki under the LGPL license. Thus we cannot commit this code.
>>>>
>>>> Could you find some alternative? The UI doesn't seem too complex
>>>> so I should be easy to do it by hand I think.
>>>>
>>>> 2) Thanks for your javadoc. It's nice and helps a lot. However
>>>> it can be improved, especially for Classes. This is the most
>>>> important Javadoc and should answer the question "what is the
>>>> class for?".
>>>>
>>>> Also please see:
>>>> http://www.xwiki.org/xwiki/bin/view/Community/
>>>> CodeStyle#HDonotuse27public27ininterfaces
>>>> http://www.xwiki.org/xwiki/bin/view/Community/
>>>> CodeStyle#HDonotduplicatemethodcommentswithparameterscomments
>>>>
>>>> Parameters and return value shouldn't start with "-" in javadoc.
>>>> See the Sun's Javadoc coding conventions.
>>>>
>>>> 3) Please add copyright to all classes and don't use the @author
>>>> tag. Instead we'll add Asiri and yourself to the Hall of Fame +
>>>> in the SVN commits.
>>>>
>>>> The rest sounds good. We need to add maven build of course. I'll
>>>> start looking into that after we fix the points above.
>>>>
>>>> Also, I haven't coded plugins in Eclipse for a very very long
>>>> time so I have no idea if what you've done is the right way of
>>>> doing it so I'll assume it is :-)
>>>>
>>>> Thanks again and keep up the good work!
>>>> -Vincent
>>>>
>>>> On Jul 15, 2007, at 10:04 AM, tharindu jayasuriya wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> This is about r.1.0.m1 version of xeclipse (XWiki-Eclipse-Plugin).
>>>>>
>>>>> We have completed following tasks in this release,
>>>>>
>>>>> 1. Cleaned up source code ( need to be confirmed by Vincent )
>>>>>
>>>>> 2. Implemented adding/deleting pages.
>>>>>
>>>>> - Adding pages does not seem to work correctly due to some
>>>>> errors in XML-RPC implementation of XWiki, need to look into this.
>>>>> - Removing pages does not work at all because the
>>>>> corresponding XML-RPC is not implemented in XWiki.
>>>>>
>>>>> 3. Implemented adding/deleting spaces.
>>>>>
>>>>> - Adding spaces work fine.
>>>>> - Deleting spaces does not work (RPC not implemented in XWiki)
>>>>>
>>>>> As it's obvious by now, we need to peek into XWiki internals to
>>>>> get these issues fixed. But since we have a scheduled release
>>>>> today (and these issues showed up all of a sudden), we thought
>>>>> of finishing the work from the plugin's end and uploading the
>>>>> relevant work. Anyway, those issues need to be fixed asap.
>>>>>
>>>>> We have tested the work on a stand alone (HSQLDB) Xwiki
>>>>> installation, it would be really nice if someone can test the
>>>>> plugin on a real server and confirm the results :)
>>>>>
>>>>> Vincent, I couldn't find an appropriate place to upload the
>>>>> files in XWIKI JIRA, so i thought of attaching relevant files
>>>>> into this email. I'm really sorry for any inconveniences.
>>>>>
>>>>> Hope to hear from you very soon.
>>>>>
>>>>> Thanks a lot!
>>>>>
>>>>> - Tharindu & Asiri
>>>>>
>>
>
>
Hi all,
I have a few doubts that might arise when we're implementing off-line
operation of XEclipse.
1. Currently, when the user saves a page after editing, no checks are made
to ensure that if the same page has been modified by someone else at the
same time. But avoiding this is a problem since that would require us to
retrieve the page again (to check locks) every-time user tries to save a
page.
2. Also, when a page is retrieved for the first time if there are any locks
are present, we must convey that information to the user (in the extreme
case, we can disallow any attempts to modify a page with any locks in it).
3. How permissions should be conveyed to users ? And how to handle them ?
(currently, this is ignored)
We can use different icons for all of these situations (for permissions ,
dirty pages etc.), but that would require a lot of icons (and we're running
out of appropriate icons too).
Any thoughts ?
Thanks.
- Asiri
Hi,
I've committed in the Sandbox a first shot at componentizing XWiki.
The idea is to have concrete examples so that:
1) you can all see how it's meant to work
2) to validate we can use Plexus without having a single import on
plexus in our components
For 2), I can say it's been successful so far. I've grouped all
Plexus stuff in the xwiki-plexus module and that's the only place
where there are plexus imports. If we want to use another component
system we should be able to do the same (provided that other
component system is transparent too).
Some more information:
* Components are described in components.xml files (check them out)
* I haven't committed the plexus.xml file that goes in xwiki-platform-
web/standard/src/main/webapp/WEB-INF. See attached.
There's plenty more to say but it'd be great if you could check this
out and ask questions here and we'll go from there.
I'm really happy with the result. I think it makes writing components
a breeze and I really like the separation of concerns.
Let's get all your questions answered and then we can decide how we
want to integrate this in a XWiki release.
Thanks
-Vincent
Hi all,
This is about r.1.0.m1 version of xeclipse (XWiki-Eclipse-Plugin).
We have completed following tasks in this release,
1. Cleaned up source code ( need to be confirmed by Vincent )
2. Implemented adding/deleting pages.
- Adding pages does not seem to work correctly due to some errors in
XML-RPC implementation of XWiki, need to look into this.
- Removing pages does not work at all because the corresponding XML-RPC
is not implemented in XWiki.
3. Implemented adding/deleting spaces.
- Adding spaces work fine.
- Deleting spaces does not work (RPC not implemented in XWiki)
As it's obvious by now, we need to peek into XWiki internals to get these
issues fixed. But since we have a scheduled release today (and these issues
showed up all of a sudden), we thought of finishing the work from the
plugin's end and uploading the relevant work. Anyway, those issues need to
be fixed asap.
We have tested the work on a stand alone (HSQLDB) Xwiki installation, it
would be really nice if someone can test the plugin on a real server and
confirm the results :)
Vincent, I couldn't find an appropriate place to upload the files in XWIKI
JIRA, so i thought of attaching relevant files into this email. I'm really
sorry for any inconveniences.
Hope to hear from you very soon.
Thanks a lot!
- Tharindu & Asiri
Hi XWikiers,
In BaseClass there is possibility to add Boolean type field with
"addBooleanField". In XwikiDocument (and then in BaseCollection), we
use "getIntValue" and "setIntValue" to retrieve or set the value with
0=false and 1=true. It's very simple but I think a
"get/setBooleanValue" that do the conversion would be much more
readable and avoid developper to search how boolean values are really
stored.
Regards,
Thomas Mortagne