- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] Position opening in your area

by sergiu＠xwiki.org

I would like to take this time to welcome you to our hiring process and give you a brief synopsis of the position's benefits and requirements. If you are taking a career break, are on a maternity leave, recently retired or simply looking for some part-time job, this position is for you. Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation Salary: Starting salary is 3000 EUR per month plus commission. Region: European Union. Please note that there are no startup fees or deposits to start working for us. To request an application form, schedule your interview and receive more information about this position please reply to Chauncey(a)it-jobsearch.com with your personal identification number for this position IDNO: 9101

13 years, 11 months

1
0
0 0

[xwiki-devs] [VOTE] Don't embed dependencies by default in xar plugin

by Thomas Mortagne

hi devs, The idea is that in Maven in general you should never embed anything except for final distribution packages that are not supposed to be used as dependencies of other maven projects (installers, standalone packages, etc.). This will also allow us to properly setup dependencies in xar so that dependency is installed when installing a xar in Extension Manager without its pages being imported twice. So I propose the following changes: * in xar plugin: ** stop embedding dependencies as default behavior ** introduce an optional property for it. * in XE/XEM have two different xars: ** a normal one with just XE pages and proper dependencies setup ** a "standalone" one which embed all XE dependencies xar (basically the one we have now) WDYT ? Here is my +1 -- Thomas Mortagne

13 years, 11 months

5
15
0 0

[xwiki-devs] [VOTE] XWIKI-6990: Reduce the likelihood of having same (hibernate) document id for different documents

by Denis Gervalle

Hi devs, I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e3… Basically, it does the following: a) Add XWikiDocument#getKey() which return a unique text key like 8:fullname2:fr b) Add XWikiDocument#getKey(context) which return a unique text key like 5:xwiki8:fullname2:fr c) Change XWikiDocument#getId() to use the lowest 64bits of an MD5 hash of XWikiDocument#getKey() d) Deprecate all XWikiCacheStore#getKey(...) and use XWikiDocument#getKey(context) for the XWikiCacheStore map e) Introduce a data migration to convert existing database, also fixing links, rcs, attachements and deleted attachements use of docid. I am +1 only after XWIKI-7006 is fixed (see my previous vote), since any improper access to an outdated database would corrupt it. Currently the patch is ready for 3.3, but if XWIKI-7006 goes in 3.2, I am also +1 to have this in 3.2. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 11 months

4
5
0 0

[xwiki-devs] [VOTE] New XEclipse committer Jun Han

by Fabio Mancinelli

Hi everybody, I would like to propose Jun Han as a new committer on https://github.com/xwiki/xwiki-eclipse Jun took part to the last GSoC, working on the RESTification of XEclipse. The project aimed at developing a new backend for XEclipse so that it could take advantage of the XWiki RESTful API. Jun has been successfull in completing the project, delivered a good quality result and he also contributed fixing several bugs not directly related to the GSoC project. His work has been presented in a previous mail (http://markmail.org/thread/3udg2fycaaeg4sun) and has been merged in the master branch and will be the core of the next release. Jun was also very active during the GSoC and, though he's very busy with his own activities, he's very responsive even now that the GSoC is over (which is a very big +) So here it is my +1 for having Jun as a committer on XEclipse. Thanks, Fabio

13 years, 11 months

8
9
0 0

Re: [xwiki-devs] [VOTE] Move to Infinispan as default cache implementation (summary)

by Thomas Mortagne

3 "+1", 1 "+0" and not other vote. Done. On Mon, Oct 10, 2011 at 8:44 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi devs, > > I just finished and committed an Infinispan > (http://www.jboss.org/infinispan) based cache API implementation. > > I would like to propose to move to it by default instead of the JBossCache one. > > Pros: > * Infinispan is basically the new name of JBossCache starting with version 4 > * as far as I can see the perf are a bit better especially in the > creation of new cache which is important for the cache macro which > potentially create lot's of caches > > WDYT ? > > here is my +1 > > -- > Thomas Mortagne > -- Thomas Mortagne

13 years, 11 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Move oldcore query plugin to legacy

by Thomas Mortagne

Hi dev, The new query manager component work pretty well and starts to be used more and more so I think we should remove com.xpn.xwiki.plugin.query. So here is the proposals: (1) move it to legacy (2) move it to retired is it's own maven project so that it's easy to build and produce a jar if someone wants to use it Note planning to do it in 3.2, that's for 3.3M1. WDYT ? +1 for (2): it's the last thing that trigger dependency on jackrabbit so even if we get rid of jackrabbit in oldcore by moving it to legacy-oldcore it would still be in XE -- Thomas Mortagne

13 years, 11 months

5
16
0 0

[xwiki-devs] [Proposal] [UX] Statistics Improvements

by Ecaterina Moraru (Valica)

Hi, This proposal is about improving the visuals of our Statistics application + adding a time filtering feature: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/StatsPage/page… Prototype at: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/StatsPage I would like to know your opinions. Thanks, Caty

13 years, 11 months

3
3
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 and XWiki Enterprise Manager 3.2 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.2. Following the goals established for the 3.x cycle, XWiki Enterprise 3.2 pushes forward in the directions of the Application Within Minutes and Extension Manager features. The highlights of this release are: * many extension manager improvements * new implementation of the sheet system making it easier to bind sheets to objects without an explicit inclusion of the sheet in the document content * user dashboards giving each user the possibility to configure their own home page * introduction of wiki workspaces, as a more collaborative way of managing an XWiki virtual farm * improvements of search results scoring * storage improvements, bringing in numerous performance and compatibility improvements * conversion of the panels application to the XWiki 2.0+ syntax * easier activation and configuration of Google Analytics And on the developers' front: * CSRF prevention enabled by default * support for DocBook syntax * xwiki-commons and xwiki-rendering are now published on the central Maven2 repository * some major code cleanup due to the retirement of some very old plugins and the move of legacy/deprecated code into separate modules See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

1
0
0 0

[xwiki-devs] [VOTE] Move to Infinispan as default cache implementation

by Thomas Mortagne

Hi devs, I just finished and committed an Infinispan (http://www.jboss.org/infinispan) based cache API implementation. I would like to propose to move to it by default instead of the JBossCache one. Pros: * Infinispan is basically the new name of JBossCache starting with version 4 * as far as I can see the perf are a bit better especially in the creation of new cache which is important for the cache macro which potentially create lot's of caches WDYT ? here is my +1 -- Thomas Mortagne

13 years, 11 months

4
3
0 0

[xwiki-devs] [VOTE] Retire xwiki watch

by Vincent Massol

Hi Devs, We've not been touching XWiki Watch for a long time and there's now the XWiki Reader contribution. Here's what I propose to do: * Move watch code to xwiki-contrib * Move documentation found on watch.xwiki.org on an extension page on extensions.xwiki.org. * Mention on that page that a new project has started: XWiki Reader and point to it * Remove watch.xwiki.org * Update home page of xwiki.org to remove watch from there and from the forge page Here's my +1 (and I'm ok to do it with maybe the help of sergiu for the github move) Thanks -Vincent

13 years, 11 months

7
10
0 0

[xwiki-devs] [VOTE] Leave CSRF protection enabled by default in 3.2 final

by Alex Busenius

Hello devs, As you know, the 3.2 branch currently has CSRF protection enabled by default for testing purposes. The tests are working fine with it since a couple of months now, and there were only some non-critical bugs found and fixed during that time. The only currently unresolved problem I'm aware of right now is http://jira.xwiki.org/browse/XWIKI-6784 I have some quick test for it locally, but I had very little time recently to clean it up and commit. The 3.2-M* and 3.2-rc* releases have the CSRF protection enabled and have been tested on myxwiki.org without big problems. CSRF protection is important security improvement and we should encourage users to enable it. Nevertheless, enabling it by default is a potentially dangerous change, since it will expose problems with not-CSRF protection aware third party extensions after the update, and therefore needs to be voted about. Related bugs (fixed): http://jira.xwiki.org/browse/XWIKI-4873 http://jira.xwiki.org/browse/XWIKI-6773 Here is my +1 for leaving it enabled. WDYT? Thanks Alex

13 years, 11 months

8
9
0 0

[xwiki-devs] Fwd: [ANNOUNCEMENT] Apache Commons IO 2.1 Released

by Vincent Massol

See below Begin forwarded message: > From: Gary Gregory <ggregory(a)apache.org> > Subject: [ANNOUNCEMENT] Apache Commons IO 2.1 Released > Date: October 10, 2011 5:13:43 PM GMT+02:00 > To: announce(a)apache.org, dev(a)commons.apache.org, user(a)commons.apache.org > > The Commons IO team is pleased to announce the Commons IO 2.1 release! > > The Commons IO library contains utility classes, stream implementations, file filters, file comparators and endian classes. > > This is a drop-in replacement for 2.0.1. A list of the 7 new features, 1 change and 7 bug fixes in this release are found in the > release notes and below. > > https://commons.apache.org/io/changes-report.html#a2.1 > > For general information on Commons IO please visit the website: > > http://commons.apache.org/io/ > > The latest version may be downloaded from the following page: > > http://commons.apache.org/io/download_io.cgi > > Thanks again to all involved in the release, both Commons users and > Commons developers. > > = New features since 2.0.1 = > > o Use standard Maven directory layout Issue: IO-285. Thanks to ggregory. > o Add IOUtils API toString for URL and URI to get contents Issue: IO-284. Thanks to ggregory. Could be useful to replace our XWiki.getURLContent() implementation. Thanks -Vincent > o Add API FileUtils.copyFile(File input, OutputStream output) Issue: IO-282. Thanks to ggregory. > o FileAlterationObserver has no getter for FileFilter Issue: IO-262. > o Add FileUtils.getFile API with varargs parameter Issue: IO-261. > o Add new APPEND parameter for writing string into files Issue: IO-182. > o Add new read method "toByteArray" to handle InputStream with known size. Issue: IO-251. Thanks to Marco Albini. > > = Fixed Bugs since 2.0.1 = > > o Dubious use of mkdirs() return code Issue: IO-280. Thanks to sebb. > o ReaderInputStream enters infinite loop when it encounters an unmappable character Issue: IO-277. > o FileUtils.moveFile() JavaDoc should specify FileExistsException thrown Issue: IO-264. > o ClassLoaderObjectInputStream does not handle Proxy classes Issue: IO-260. > o Tailer returning partial lines when reaching EOF before EOL Issue: IO-274. Thanks to Frank Grimes. > o FileUtils.copyFile() throws IOException when copying large files to a shared directory (on Windows) Issue: IO-266. Thanks to Igor Smereka. > o FileSystemUtils.freeSpaceKb throws exception for Windows volumes with no visible files. > Improve coverage by also looking for hidden files. Issue: IO-263. Thanks to Gil Adam. > > = Changes since 2.0.1 = > > o FileAlterationMonitor.stop(boolean allowIntervalToFinish) Issue: IO-259. > > Gary, on behalf of the Apache Commons community > -- > E-Mail: garydgregory(a)gmail.com | ggregory(a)apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory

13 years, 11 months

1
0
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Release Candidate 1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Release Candidate 1. This is the first (and hopefully last) release candidate for the 3.2 series. Apart from a few minor bugfixes, this version brings the Workspace Manager as a standard feature of the platform, as an alternative way of using virtual wikis, compared to XEM. See http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32RC1 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

1
0
0 0

[xwiki-devs] XEclipse RESTification

by Fabio Mancinelli

Hi everybody, I've just merged the work done by Jun Han in the master branch of the XEclipse repo (https://github.com/xwiki/xwiki-eclipse) Jun has worked during the summer for this GSoC project. Here it is a summary of what has been done, as summarized by Jun: Major work is listed below: 1. Implement an abstract storage layer independent of xmlrpc or rest backend 2. New storage implementation using the XWiki REST API 3. Multiwiki support in the navigator view (using the updated REST API storage) 4. Improve user interface and responsiveness 5. Use JSON library in local storage to replace XML 6. Add operations (add/delete/edit) of page, objects, attachments, class, revision, tag, translation, and comments supported by current REST API Fixed Issues include (not complete): 1. XWiki Eclipse XECLIPSE-154 Grab space operation fails on Spaces named in cyrillic 2. XWiki Eclipse XECLIPSE-137 Open version problem 3. XWiki Eclipse XECLIPSE-131 Error when clicking on a List type object field in the outline view 4. XWiki Eclipse XECLIPSE-41 Display references to document's attachments 5. XWiki Eclipse XECLIPSE-150 Move the build system to Tycho 6. XWiki Eclipse XECLIPSE-145 Maven-based build of XEclipse requires customization to work out of the box 7. XWiki Eclipse XECLIPSE-51 Eclipse update feature 8. XWiki Eclipse XECLIPSE-149 XEclipse does not start under Ubuntu 10.4 9. XWiki Eclipse XECLIPSE-133 XEclipse does not start on OSX if JDK 1.6 is selected 10. XWiki Eclipse XECLIPSE-94 When connecting to a multiwiki install, list all subwikis and ask to which one to connect to >From previous discussion, considering the big amount of new/improved features, we've decided to promote this new development line to 2.0.0-SNAPSHOT and deprecate the old 1.2 one. The idea is to fix the outstanding bugs in order to converge towards a 2.0.0-M1 and then 2.0.0 final. I'd like to thank Jun for his involvement and I hope that he will continue to help us making XEclipse improve. Thanks, Fabio

13 years, 11 months

4
4
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1, bugfix releases on the 3.1.x stable branch. This is the first (and probably last) bugfix release for the 3.1 series. It contains only small bugfixes backported from the 3.2 branch, mainly around missing CSRF-prevention tokens, the extension manager, and build improvements. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise311 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

1
0
0 0

[xwiki-devs] [VOTE] Improving the migration manager to fix XWIKI-7006, XWIKI-1859, XWIKI-2075, XWIKI-2066

by Denis Gervalle

Hi devs, I need to do XWIKI-6990 (Reduce the likelihood of having same (hibernate) document id for different documents), but XWIKI-7006 (Accessing a store that is not migrated to the lastest data version should not be allowed) is blocking for this to be safely introduced. So I have refactored the migration code to better protect the database, I would like your vote to introduce this patch first, another vote will come for XWIKI-6990. The proposed commit is available at https://github.com/dgervalle/xwiki-platform/commit/f1fa1b1357d17c1ee4ed65eb… In summary, here is what it does: a) Refactor the old XWikiMigrationInterface and XWikiMigratorInterface into new DataMigrationManager and DataMigration interfaces b) Implement the DataMigrationManager and the DataMigration interfaces using components for the hibernate stores c) Remove the migration check from XWiki and put them in hibernate stores components, freeing this from XWiki. Since store still use the XWikiContext, I still use it, but from the execution context, no more passing it everywhere. d) Use a cache for DB version to not degrade performance e) Remove many call to schemaUpdate which require synchronization, executing only schema updates during data migrations. f) Remove some data migration like code from schemaUpdate, convert it to HQL (in place of native SQL :() and put them in an initial LegacyDataMigration, that migrate from version 0 to version 1 g) Fix empty/new database issue by considering a database without version AND without documents as a new database, and initialize it with the current schema and the latest version. h) Properly report migration failure and prevent access on failure i) Prevent access to any database not being properly migrated to the latest version by never providing a valid transaction for it. By the way, fix another (unnoticed ?) bug: if a throw occurs during database switching, a transaction could be return and used improperly (mixing data from different database). j) deprecate xwiki.store.hibernate.updateschema, but use "1".equals(config.getProperty("xwiki.store.migration", "0") && !"0".equals(config.getProperty("xwiki.store.hibernate.updateschema") to enable migrations k) Now xwiki.store.migration.databases=all, before it was xwiki only, which is not right IMO Currently, migration manager is injected in stores, using a hint, since the migration manager will be different depending on the store that keep the data version. The migration manager lookup the store by hint to retrieve the data version. The migration manager lookup data migrations using hint as well. Finally, data migrations lookup stores again using hint. Some improvements would be to allow multiple data versions (one per store hint), and mix data migration, since stores could be mixed, but this is out of my scope currently. To support injecting store by scope properly, there is another separate commit, available at https://github.com/dgervalle/xwiki-platform/commit/6a353d6d45bfb73789ed0693…, which replace the default unnamed stores, by "hibernate" named stores. Since store are still initialized at XWiki initialization, migration still occurs during first request to the system, but this is no more related to the migration system, which intercept the first database access, but this is related to this XWiki initialization only now. So XWIKI-2075 is fixed for me. I have already work hard to reach this state, there is still room for improvements, but I will not be able to afford much more time on this right now (at least without a sponsor :)). Please be fair in your remarks ;) Here is my +1. Currently the patch is done for 3.3, but if you think it could go in 3.2, I am +1. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 11 months

2
1
0 0

[xwiki-devs] [VOTE] Fixing cyclic dependency introduced by the workspace module

by Eduard Moraru

Hi devs, The workspace module has a maven artefact (workspace-template) that produces an enhanced (adds extra pages, set some properties, overrides some pages, etc.) XE xar that is to be used by all the created workspaces. The problem is that, being part of the platform, this creates a cyclic dependency in maven thus breaking the build. Also, the 3.2RC1 release is supposed to be today, so the matter is rather urgent. To fix this, there might be a couple of solutions on which I`d like your opinion/vote: 1) Rewrite the workspace-template module and, instead of using maven to produce a customized XE xar, use velocity within the workspace application to enhance a standard XE xar at runtime, when actually creating the workspace. (needs some time) 2) Move the workspace-template module into the XEM build and bundle workspace by default with XEM. (quick to do) 3) Move the workspace-template module into the XE build, even though workspaces is not bundled by default with XE. (quick to do, but not necessarily right) 4) Unlink the workspace module from the platform build, so that it is skipped from the build and that it does not break it, but leave the hooks. (quick to do, leaves way for further work) 5) Just revert everything related to workspaces from the platform and possibly keep the existing work in a branch. (quick to do, but also removes the hooks) Here's my +1 for 2). Thanks, Eduard

13 years, 11 months

3
3
0 0

[xwiki-devs] [VOTE] Naming policy for "-manager" modules and naming the "Workspace feature"

by Eduard Moraru

Hi devs, Since starting to develop the workspaces feature, under the Wiki3.0 project, I`ve used internally the name "Workspace Manager" (providing the script service "$services.workspaceManager") by following the naming scheme used by the Wiki Manager plugin. When the code was moved into the platform, I`ve named the top maven artefact "xwiki-platform-workspace-manager" and the java package "org.xwiki.workspacemanager". Recently, Vincent proposed [1][2](see arguments) to drop the "-manager" suffix, thus, the following changes would occur: - "$services.workspace" instead of "$services.workspaceManager" - "org.xwiki.workspace" instead of "org.xwiki.workspacemanager" - "xwiki-platform-workspace" instead of "xwiki-platform-workspace-manager" - "Workspace Feature" instead of "Workspace Manager Feature" Since it's a new module, there are no problems with backward compatibility so the changes can be applied with some minor refactorings of the velocity code using the service. I did not know about this naming policy, so I`d like your opinion/vote on whether to apply the proposed changes and enforce this policy in the future as well. Here's my +1. Thanks, Eduard References: ----------------- [1] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540… [2] https://github.com/xwiki/xwiki-platform/commit/8c1cc0bc73249eee20159dc3e540…

13 years, 11 months

5
5
0 0

[xwiki-devs] [VOTE] Keep empty reference in XHTML

by Thomas Mortagne

Hi devs, When you want a local link you use something like [[label>>#anchor]] and it will produce an XHTML like <a href="/xwiki/bin/view/CurrentSpace/CurrentDocument#myanchor">label</a>. IMO this is not very good since: * it's doing lot's of useless work (resolving the reference, getting the corresponding XWikiDocument to finally generate the URL thanks to URLFactory * it's breaking any included local reference since it will be resolved based on the source document and not the current document which makes sense when you target a specific document but not when you asked for a local reference Note that it used to be that way (and I tough it was still the case) and I don't remember why this has been changed. So I proposed to put back the specific handling of empty reference: produce <a href="#myanchor">label</a> in the XHTML renderer for the previous example. WDYT ? Here is my +1 -- Thomas Mortagne

13 years, 11 months

5
5
0 0

[xwiki-devs] [Proposal] Add support for DocBook integration in XWiki Rendering

by Vincent Massol

Hi devs, This weekend I've been working on adding docbook support in XWiki Rendering by using the Doxia Bridge (since Doxia as both a DocBook parser and a DocBook renderer). I'd like to commit this now for 3.2RC1 if possible since it's not going to cause any issue with anything else (it's something new not impacting existing stuff). WDYT? Thanks -Vincent

13 years, 11 months

4
3
0 0

[xwiki-devs] [API BREAK] Fixing the directory structure of xwiki-store-filesystem-attachments.

by Caleb James DeLisle

When I made xwiki-store-filesystem-attachments, I made a mistake, I put the files which directly interface with the old core into the com.xpn.xwiki package. I realize it was a mistake not to ask about it and now I would like to correct it. This is an API break because these classes not under an /internal/ dir and are considered by clirr to be API. Since this implements interfaces which are defined in the old core, bridging is obviously impossible I would like to indicate somehow that those classes deal directly with old core and thus will be removed with it when the time comes. A) replace com.xpn.xwiki with org.xwiki.store.internal.legacy this will show that they are essentially with legacy code. B) replace com.xpn.xwiki with org.xwiki.store.filesystem.internal this will mix all of the implementations of oldcore interfaces with classes which provide services to them. Any other ideas? Caleb user@debo8:~/wrk/xwiki.git/xwiki-trunks/xwiki-platform/xwiki-platform-core/xwiki-platform-store/xwiki-platform-store-filesystem-attachments$ find

13 years, 11 months

1
0
0 0

[xwiki-devs] [Proposal] XEclipse Release

by Vincent Massol

Hi devs, Fabio and Eddy are working on merging Jun's GSOC code in master for XEclipse and are preparing for a release (could you send us a proposal guys?). It seems that the last release of XEclipse was 1.2RC1 so it's a bit of a shitty situation since normally so much change would have warranted a 1.3 release. However I'm proposing that the next release be 1.2RC2 and when we've tested it enough we then quickly release 1.2 final to get it over with. The alternative is to: - get the 1.2RC1 tag - release it again as 1.2 final - consider all Jun's changes to be 1.3M1 However that solution has 2 issues: - it's more time consuming - we're not 100% sure that the last 1.2RC1's quality was good enough to be named 1.2 final WDYT? My preferences goes to having Jun's code be in a 1.2RC2 release. Thanks -Vincent

13 years, 11 months

4
6
0 0

[xwiki-devs] [VOTE] Generalize concept of legacy module to XWiki Commons and even more generally

by Vincent Massol

Hi devs, I'd like to propose to apply the -legacy module concept we have in platform to XWiki Commons (and XWiki Rendering when a first need will arise). The idea is to introduce a xwiki-commons/xwiki-commons-core/xwiki-commons-legacy parent module. My first use case is: * Now that I've removed all usages of the old @Requirement annotation in commons, rendering, platform, enterprise I'd like to make sure we don't use it again and thus I'd like to add an aspect in xwiki-commons/xwiki-commons-core/xwiki-commons-legacy/xwiki-commons-legacy-component/ to add support for the old annotations. More specifically I'd like to remove the handling of the old Requirement annotation in ComponentDescriptorFactory and add an around aspect to add support for it in the legacy module. Thus I'd like to agree that we have 2 steps when it comes to deprecating code: 1) Start by deprecating it using the @deprecate and @Deprecated javadoc and java annotations. The code remains where it was before the deprecation happens. This is a first step. 2) When our own code doesn't use any of the deprecated APIs then move the code to a legacy module (either by moving an entire class if possible or by using some Aspect to weave some methods for ex). This is a second step. It has the following advantages: * Our code remains clean of old deprecated apis * Deprecated code is cleanly separated from new ways of doing things * When new users download the our code they see the new ways (same for javadoc generation) * Users wanting to use the old APIs can still do so Note: The question of when to remove completely the code from legacy is another topic that I'd like to bring up too but in a different email thread (I started writing a mail on this topic but need to finish it). Here's my +1 to follow this practice across our code base and to document it on xwiki.org Thanks -Vincent

13 years, 11 months

5
10
0 0

[xwiki-devs] [VOTE] Release XWiki Enterprise+Manager 3.1.1

by Sergiu Dumitriu

Hi devs, Since the 3.2 release is approaching, I'd like to close the stable 3.1.x branch as well with a final 3.1.1 release, probably on October 3rd. If you have any important bugfixes you want to see in this release, please push them ASAP. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

5
4
0 0

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Milestone 3 released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Milestone 3, the last milestone of the XWiki Enterprise 3.2 version (see the roadmap at http://enterprise.xwiki.org/xwiki/bin/Main/Roadmap ). Main new features include: * improved Lucene scoring * new implementation of the sheet system * support for OpenOffice 3.3 as the backend of the office importer * better support for IE9 in the WYSIWYG editor * many improvements in the extension manager and extension repository * the removal of the Albatross skin from the distribution * ... and quite a lot of dependency upgrades and bug fixes See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32M3 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs