JV which have you deleted this issue?
Generally speaking we shouldn't delete any issue (I guess we should
configure jira to remove delete permissions). We can close them as
"won't fix" or "invalid" instead.
-Vincent
On Jan 12, 2009, at 5:41 PM, Jean-Vincent Drean (JIRA) wrote:
>
> [ http://jira.xwiki.org/jira/browse/XPWATCHLIST-43?page=com.atlassian.jira.pl…
> ]
>
> Jean-Vincent Drean deleted XPWATCHLIST-43:
> ------------------------------------------
>
>
>> Remove sanitizeWatchlist from the plugin
>> ----------------------------------------
>>
>> Key: XPWATCHLIST-43
>> URL: http://jira.xwiki.org/jira/browse/XPWATCHLIST-43
>> Project: XWiki Watch List Application
>> Issue Type: Task
>> Reporter: Jean-Vincent Drean
>>
>> This method was meant to handle the migration between watchlist 1.2
>> and 1.3, since the last released version is 1.11 we need to remove
>> it (it makes xwiki init slower).
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi VIncent,
On Mon, Jan 12, 2009 at 2:13 PM, Vincent Massol <vincent(a)massol.net> wrote:
> Hi Asiri,
>
> This is good (the move to components for filters) except for one very
> important thing: now if some module implements some filter components
> using that interface they'll be used automagically by the HTMLCleaner.
> This makes the HTML Cleaner non safe with a non predictable behavior.
>
> Imagine for ex that in the office importer you implement the
> CleaningFilter interface and expose the implementations as components.
> These filters will be used even when not doing office imports.
>
> So +1 for components but you need a way to control which filters are
> used for a cleaning operation now.
I didn't think of this. For the moment I have changed the components.xml to
inject only those filters we require for DefaultHTMLCleaner. But yes, we
should have a mechanism to dynamically specify which filters we need to
apply...
Thanks.
- Asiri
>
>
> Thanks
> -Vincent
>
> On Jan 12, 2009, at 12:38 AM, asiri (SVN) wrote:
>
> > Author: asiri
> > Date: 2009-01-12 00:38:10 +0100 (Mon, 12 Jan 2009)
> > New Revision: 15346
> >
> > Added:
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/
> > filter/
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/
> > filter/CleaningFilter.java
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/filter/
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/filter/DocTypeCleaningFilter.java
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/filter/LineBreakCleaningFilter.java
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/filter/ListCleaningFilter.java
> > Removed:
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/CleaningFilter.java
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/DocTypeCleaningFilter.java
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/ListCleaningFilter.java
> > Modified:
> > platform/core/trunk/xwiki-xml/pom.xml
> > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> > html/DefaultHTMLCleaner.java
> > platform/core/trunk/xwiki-xml/src/main/resources/META-INF/plexus/
> > components.xml
> > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/
> > XMLUtilsTest.java
> > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/
> > html/DefaultHTMLCleanerTest.java
> > Log:
> > XWIKI-3101: Replace invalid xhtml <br/> elements with <div
> > class="wikimodel-emptyline"/> in DefaultHTMLCleaner
> > XWIKI-3094: Errornous rendering of xhtml content with <br/
> > >[newline]<p> sequence
> >
> > * LineBreakCleaningFilter implements the above functionality.
> > * Adding LineBreakCleaningFilter caused a fan-out of 21 in
> > DefaultHTMLCleaner. To overcome this problem CleaningFilter
> > implementations were made components and they are now injected via
> > plexus into DefaultHTMLCleaner (refer to components.xml) Necessary
> > package restructuring was done.
> > * Added tests to verify the behaviour of LineBreakCleaningFilter.
>
> [snip]
>
>
>
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
The XWiki development team is pleased to announce the release of XWiki
Eclipse 1.2 RC1.
Go grab it at http://xeclipse.xwiki.org
XWiki Eclipse 1.2 RC1 introduces several bug fixes and major
improvements such as syntax highlighting and completion, support for
objects and translations and much more.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEclipse12RC1
Thanks
-The XWiki dev team
Hi Asiri,
This is good (the move to components for filters) except for one very
important thing: now if some module implements some filter components
using that interface they'll be used automagically by the HTMLCleaner.
This makes the HTML Cleaner non safe with a non predictable behavior.
Imagine for ex that in the office importer you implement the
CleaningFilter interface and expose the implementations as components.
These filters will be used even when not doing office imports.
So +1 for components but you need a way to control which filters are
used for a cleaning operation now.
Thanks
-Vincent
On Jan 12, 2009, at 12:38 AM, asiri (SVN) wrote:
> Author: asiri
> Date: 2009-01-12 00:38:10 +0100 (Mon, 12 Jan 2009)
> New Revision: 15346
>
> Added:
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/
> filter/
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/
> filter/CleaningFilter.java
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/filter/
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/filter/DocTypeCleaningFilter.java
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/filter/LineBreakCleaningFilter.java
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/filter/ListCleaningFilter.java
> Removed:
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/CleaningFilter.java
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/DocTypeCleaningFilter.java
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/ListCleaningFilter.java
> Modified:
> platform/core/trunk/xwiki-xml/pom.xml
> platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/
> html/DefaultHTMLCleaner.java
> platform/core/trunk/xwiki-xml/src/main/resources/META-INF/plexus/
> components.xml
> platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/
> XMLUtilsTest.java
> platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/
> html/DefaultHTMLCleanerTest.java
> Log:
> XWIKI-3101: Replace invalid xhtml <br/> elements with <div
> class="wikimodel-emptyline"/> in DefaultHTMLCleaner
> XWIKI-3094: Errornous rendering of xhtml content with <br/
> >[newline]<p> sequence
>
> * LineBreakCleaningFilter implements the above functionality.
> * Adding LineBreakCleaningFilter caused a fan-out of 21 in
> DefaultHTMLCleaner. To overcome this problem CleaningFilter
> implementations were made components and they are now injected via
> plexus into DefaultHTMLCleaner (refer to components.xml) Necessary
> package restructuring was done.
> * Added tests to verify the behaviour of LineBreakCleaningFilter.
[snip]
I go on compiling XWiki under windows until I get back my beloved linux
platform :)... Finally, it appears not to be so trivial... Last week, I
found 2 minor issues but this last one is a blocking one.
When you build wysiwyg under windows, the gwt-maven plugin generates a
script "compile.cmd" in order to compile GWT code.
But, when it launches the script, you get an error "Line too long"...
And this is true, due to the huge number of dependencies with long
directories, the Classpath variables are too long for Windows... I love
Windows :):):)
Apparently, this is a well known bug of gwt-maven but seems not easy to
solve or not enough important to be solved :)
Anyway, until this bug is solved or if somebody finds a clever workaround
solution, it will remain impossible to compile wysiwyg under windows.
This is disturbing because, if you don't compile WYSIWYG, you can compile XE
without any problem but when you launch the server, you get a weird error
such as "Can't find class file RemoteService" and the jetty server don't
bind to classic port 8080.
So the only solution I found is to remove "wysiwyg" module from profile "xe"
in xwiki-web.
best regards
Pascal
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.7.1. This is a bugfix and minor enhancements release
following XE 1.7.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
WYSIWYG and Rendering 2.0 Improvements :
* You can now upload and insert image in your documents from the WYSIWYG
* You can create tables and manage them (row/columns addition and
deletion) from the WYSIWYG.
* Added support for explicit line breaks (\\) in XWiki Syntax 2.0
Important bug fixes:
* XWIKI-2988: The way to synchronize several LDAP groups with the
same XWiki group is wrong
* XWIKI-3024: XWiki authenticator load
xwiki.authentication..createuser in place of
xwiki.authentication.createuser from xwiki.cfg file
* XWIKI-3023: Timeout when trying to connect to Penrose LDAP server
* XWIKI-3010: By default the size of "ldap_group_mapping" field in
XWikiPreferences is too short
* Many WYSIWYG bugs fixed
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise171
Thanks
-The XWiki dev team
Hi Devs,
The office importer module has reached a point where it can be integrated
into XWiki's UI:
Currently there are two UI's provided by office importer:
1. The Wysiwyg plugin which should be integrated to Wysiwyg UI (obviously) :
http://91.121.237.216/xwiki/bin/view/Main/
2. The office importer application :
http://91.121.237.216/xwiki/bin/view/Import/
We need to decide how we will allow users to discover the office importer
application from the main UI. Following are some options:
a) Add the "import" action to one of our existing menus
Problem: I don't see any existing menus where "import" will fit in.
b) Add a new menu named "Import" into the main menu bar. like { | Edit |
show | print | import | actions | watch }
Problem: existing menus and their menu items always refer to actions
performed on the current document (wiki page) while importing is about
importing an office document to a new wiki page.
Possible solution : We can change the office importer slightly so that it
overwrites the current wiki page with the imported document.
Any other options ?
Thanks.
- Asiri