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

Re: [xwiki-devs] Release Version Numbering Strategy (was Re: [Proposal] XE 3.0 and Roadmap leading to it)

by Gregory GUENEAU

Hi vincent, On 2 nov. 2010, at 08:56, Vincent Massol <vincent(a)massol.net> wrote: > Hi Ludovic, > > On Nov 1, 2010, at 6:05 PM, Ludovic Dubost wrote: > >> >> I've been thinking a little more about the XE 3.0 idea and I came to the conclusion that there should be no XWiki version called 3.0. >> >> Here is my thinking. I agree with something that was discussed by multiple people which is that a potential main version switch is the sign of a progress and of a cycle of development (preferably of a coherent feature set that we have thought about). >> The probleme is that if you call this version 3.0 then people will think of what software usually is developped (in the proprietary world), where 3.0 is a start with major changes in the software. >> >> Now when we look at the way open source and XWiki in particular develop software, this is not at all the case. We make gradual changes in the whole cycle of the software and there is not that many more changes between 1.9 and 2.0 then there was betwee 1.6 and 1.7. In this life we introduce new features all the time. Usually the first time a features goes in, it's not perfect and it's improved in the next release (with the biggest bugs fixed in minor releases). >> >> In order to recognize that and make it more understandable I suggest we don't call ANYTHING a .0 release. Instead I suggest that we start calling things the way they are, which are releases of a cycle which are improvements on a path that has been explained. >> Therefore we should NAME the major releases (instead of numbering them, although we keep the number for tracking) and we number the sub releases starting with 1 and not 0. >> >> For example if we call the 2.x cycle XXXXX and the 3.x cycle YYYYY, then we release >> >> XWiki 2.1 -> Cycle XXXXX release 1 -> subname for that release >> XWiki 2.2 -> Cycle XXXXX release 2 -> subname for that release >> XWiki 2.3 -> Cycle XXXXX release 3 -> subname for that release >> XWiki 2.4 -> Cycle XXXXX release 4 -> subname for that release >> >> For each release we show with features are in beta/stable state. Then at some point we work on full stabilitization and we advertise >> >> XWiki XXXXX release 7 with all features in there being stable >> >> Then we start the next cycle with release 1 >> >> XWiki YYYYY release 1 >> etc.. >> >> And we show the path and objectives of the whole cycle in order to show some coherency. >> >> This way we avoid the .0 issues where it's not clear if a .0 is stable or not, the beginning or the end. >> >> -- >> >> Concerning the plan, I'm +1 for stabilitzation work. -0 for calling the result 3.0. >> +1 for calling the next release following 2.7, version 3.1 but having new features in them showing the path of the next development cycle. >> and +1 for finding a text naming instead of numbers >> >> For the next cycle (3) we would need to find a nice name that shows the path we want to follow. > > I don't like skipping a version. It's confusing and not logical (from a number POV) IMO. > > I'd be ok with one of the following strategies (listed in the order of my preference): > > 1) Same as now. I don't see it a problem at all. I'm not completely sure why we're having this discussion. Have many users raised a question regarding our current release scheme? If we balance marketing needs in release numbering i am +1 The question is therefore : how do we merge those interrest in a reliable process ? > > 2) Same as now but we don't release major versions for "marketing" reasons (like we did for the 2.0 release), i.e. we only make a major release when there's a large non backward compatible change (say for example when we introduce the new model, or a move to JCR for example as the new storage mechanism, etc). This means we could have a 2.55 version. -0 on this, i am not sure this reaches our goals > > 3) No major releases at all. This means that we acknowledge that we don't need them since we're making evolutive changes (without major breakages or breakages are done evolutively too with deprecation cycles, etc). This would mean a new numbering scheme that doesn't have a major value. For ex: Release 25, 26, ... 150, etc. I like that it's based on numbers since you know the previous and the next one easily (and technically it'll work with Maven, no need for a custom version comparator). +0 it could be a good way to remove any marketing issue from the numbering strategy, but it kills value > > Thanks > -Vincent > >> Ludovic >> >>> On Nov 1, 2010, at 12:50 PM, Gregory GUENEAU wrote: >>> >>>> Hi everyone, >>>> >>>> I am +1 to make stabilization work, on a couple of releases >>>> I am +1 to have soon a 3.0 release >>>> And i am +1 on the content vincent propose >>>> >>>> But my point of view is -1 stepping the release family number because the main purpose of what is discussed here is stabilization, and not showing the path of 3.x family. >>>> >>>> Therefore : >>>> - do we consider a january 2011 release to be stable enough ? >>> Speaking for myself of course... >>> >>> yes (otherwise I wouldn't have proposed it obviously). >>> >>>> - stabilization work wouldn'it be leading then to the last 2.x version instead of the first 3.x family version ? >>> no, it's the same. >>> >>>> - is there behind it a consensus on what we will concentrate our effort in 3.x versions ? I mean thematics we can talk about. >>> not needed to decide on the 3.0 release, this is a topic for another mail. >>> >>>> - therefore, are we in a situation where we can vote on the global thematics we will develop in 3.x releases ? >>> not needed at this stage >>> >>>> - do we have a clear consensus short list of features that show the path of 3.x family ? >>> not needed at this stage >>> >>>> - in consequence of that, is the release content here send a clear message to uneducated publics about what is in this future 3.x versions ? >>> not needed at this stage >>> >>>> - do educated people care this much about release number, that we absolutely have to release a 3.0 with the content presented below ? >>> yes (the content is open of course but provided it's not important new stuff IMO since otherwise it won't be about stabilization). >>> >>>> We have to make 100% sure our message will be understood by market. We are now in the Gartner magic quadrant and will increase our visibility outside the opensource community. >>>> In a world where new release number families means : "we show the path of the future of this software, even if the features we present are not perfect", i will strongly promote to answer in details the questions i mentionned before deciding 2.8 to be in fact 3.0. >>>> >>>> Then here is the two elements that are probably the biggest things in the roadmap for 3.x versions : >>>> - going social (workspaces in xem, twitter like app, page stats for the user, etc.) >>>> - going to be an easy place to develop in (extension manager of course, but also documentation for dummies and a first app like "app within minute" proposed by guillaume and strongly needed by our front team) >>>> >>>> Is there a consensus on this list ? Then what should be the "demo" features we could present to be consistent for a 3.0 release ? >>> Again this is not the topic of this mail. You're talking about deciding what's in for 4.0 when this mail is about deciding the 3.0 release. >>> >>> Thanks >>> -Vincent >>> >>>> Best >>>> >>>> >>>> >>>> On 1 nov. 2010, at 09:23, Vincent Massol<vincent(a)massol.net> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> Sergiu started mentioning the idea of a XE 3.0 when we defined the XE 2.6 roadmap. We need a more general agreement that we want a XE 3.0 and how to reach it. >>>>> >>>>> As Sergiu I believe we need a XE 3.0 ASAP for the following reasons: >>>>> >>>>> - it's been a bit more than 1 year since the XE 2.0 release and I feel it's good to have one major release every year >>>>> - we've added **lots** of features since XE 2.0. Check http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotes to get a feeling >>>>> - it's good for open source marketing >>>>> >>>>> Before being able to release XE 3.0 I think: >>>>> >>>>> - XE 2.6 is already planned for the 18th of November (with "mail this page" and "recent activity" features + icon/emoticon and wikiword support that was sneaked in surreptitiously) >>>>> - We should have a XE 2.7 release (1 month duration, ie leading us to the 18th of December) to finish started stuff: >>>>> -- Finish the Gadget integration since it's been started already and it's important. That said I'd actually be ok to not finish it if we think it's too much to release XE 3.0 quickly according to the dates below. Anca to tell us if it's possible in the timeframe. >>>>> -- First working extension manager that can be used to install XARs (replaces the old Packager on the back end side). Thomas to tell us if it's possible in the timeframe. >>>>> -- Recent Activity with apps sending events (XE 2.6 will already have a good part of it) >>>>> -- UI finishing touches >>>>> -- Some additional Security and Performance improvements if possible >>>>> -- etc (add what you'd like to see absolutely here - it should be work already started as much as possible and no new stuff) >>>>> - Release XE 3.0 one month after the XE 2.7 release, ie around 18th of January - ie end of January 2011) >>>>> >>>>> Very important: XE 3.0 should be a maturation/conclusion release, i.e. concluding all the work started in the 2.x series (same as what we did for XE 2.0). It shouldn't be seen as revolutionary stuff that we should add from now on since it'll take a year more before those can be fully stabilized and we would loose the window of opportunity of doing a major release now. >>>>> >>>>> Note: We shouldn't try to cram too much things in since that'll extend the lead time to release XE 3.0 and we'll loose the stabilization effect. >>>>> >>>>> WDYT? >>>>> >>>>> Thanks >>>>> -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 10 months

1
0
0 0

[xwiki-devs] [proposal] New module to handle large binary objects in a generic way.

by Caleb James DeLisle

In light of the need for better attachment handling, I spent the past few days working on the basic framework for a new module to support large objects. The code can be viewed here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-blob/src/main/java… Use case #1: Multiple methods of storing content and the ability to define more. Use case #2: Thread safe locking to prevent concurrent modifications from damaging content. Use case #3: ACID commit/rollback protection. The API user has 2 access points. BinaryObject is a thread safe interface with ACID and option of using OutputStream or InputStream to set and get data. StorageItem is a simplistic interface modeled after a small subset of the methods in java.io.File. If you create a component which implements StorageItem, BinaryObjectProvider will allow you to access a BinaryObject which uses your StorageItem for persistent storage. Example: @Requirement private BinaryObjectProvider provider; private BinaryObject binaryObj; public void initialize() { this.binaryObj = this.provider.get("myImpl"); } "myImpl" is the hint for the StorageItem which you may define. The next step is of course to add versioning support but I think this will provide a solid foundation to build that on. WDYT? Caleb

14 years, 10 months

2
3
0 0

[xwiki-devs] rendering breadcrumbs

by [Ricardo Rodriguez] eBioTIC.

Hi, Following this thread http://markmail.org/thread/jbd62pddnuqvm5ku and after trying the same example in the new XE 2.6-SNAPSHOT.32286, I see that variables set in the body of the document keep being well rendered/printed in the title of the document but not in the breadcrumbs. I would like to know if there is some design reason for printing breadcrumbs before the content of the document or we could expect that in some future version this could be possible. Thanks! Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

14 years, 10 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r32285 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl

by Vincent Massol

On Oct 31, 2010, at 5:48 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-31 05:48:50 +0100 (Sun, 31 Oct 2010) > New Revision: 32285 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfExportImpl.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/pdf/impl/PdfURLFactory.java > Log: > XWIKI-5639: PDF export doesn't contain images if the document name contains non-ASCII characters > Fixed. [snip] > - for (int i = 0; i < filelist.length; i++) { > - filelist[i].delete(); > + try { > + FileUtils.deleteDirectory(tempdir); > + } catch (IOException ex) { > + // Should not happen, but it's nothing serious, just that temporary files are left on the disk. > + log.warn("Failed to cleanup temporary files after a PDF export", ex); I thought our strategy was to not display stack trace unless the log was about an error? (at least this is the strategy I've always followed since a stack trace takes up a lot of space, draws the eye, etc). What I do usually is just display the nested message without the stack trace. Note: It might be good to have a utility method somewhere to extract all messages from all nested exceptions without the stack trace. WDYT? Thanks -Vincent [snip]

14 years, 10 months

3
2
0 0

[xwiki-devs] Document information panel - parent

by Paulo Zenida

Hello devs, I installed the latest stable version of XWiki (2.5) and I found out that the document information panel does not include a parent field. Therefore, I tried to include that field, as in the older version I had (2.4.3) but saving the document does not save the parent in the database. Is this a bug or was there a change in the way we say what is the parent page of a given document? I tried to search for known issues in Jira but had no success on this one. Best, Paulo Zenida

14 years, 11 months

1
1
0 0

[xwiki-devs] [Proposal]JavaScript console.log wrapper for our convenience

by Jerome Velociter

Hi devs, I'd like to commit a console.log wrapper in xwiki.js that does some checking before logging, in the spirit of http://paulirish.com/2009/log-a-lightweight-wrapper-for-consolelog/ Something like : var XWiki = { //snip /** * console#log wrapper for your developer own convenience */ log: function(){ if(typeof console != "undefined"){ console.log( Array.prototype.slice.call(arguments) ); } }, // snip } WDYT ? Jerome

14 years, 11 months

4
6
0 0

[xwiki-devs] [Proposal] Adopt the JavaScript module pattern

by Jerome Velociter

Hi devs, I'd like to propose we adopt the module pattern for our XWiki's javascript modules. The pattern and its variations is well described here : http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth I would follow the author advice and go for loose augmentation and sub-modules. I don't think we need private states. Main avantages I see over what we currently are doing are : * It enforces namespacing and the use of a private scope versus manual namespacing in the global window scope * It easily supports global imports (can be useful for example when using jQuery in addition to prototype) * It's more elegant and easier to read. For example : var XWiki = (function(XWiki, $j){ var mySubModule = XWiki.mySubModule = XWiki.mySubModule || {}; // my sub module code here return XWiki; })(XWiki, jQuery) instead of the tedious : if (typeof XWiki == "undefined") { XWiki = new Object(); } if (typeof XWiki.mySubModule == "undefined") { XWiki.mySubModule = new Object(); } // my sub module code here I'm +1 to adopt it. WDYT ? Jerome

14 years, 11 months

2
2
0 0

[xwiki-devs] Dennis Coonich wants to stay in touch on LinkedIn

by Dennis Coonich via LinkedIn

LinkedIn ------------Dennis Coonich requested to add you as a connection on LinkedIn: ------------------------------------------ Guillaume, I'd like to add you to my professional network on LinkedIn. - Dennis Coonich Accept invitation from Dennis Coonich http://www.linkedin.com/e/3vasf0-gftu99lf-2a/9s_c-0fN05p6qjQq9meQgfVB/blk/I… View invitation from Dennis Coonich http://www.linkedin.com/e/3vasf0-gftu99lf-2a/9s_c-0fN05p6qjQq9meQgfVB/blk/I… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/3vasf0-gftu99lf-2a/abq/inv-24/ -- (c) 2010, LinkedIn Corporation

14 years, 11 months

1
0
0 0

[xwiki-devs] [VOTE] XE 2.6 Roadmap

by Vincent Massol

Hi, I'd like to propose that we have a short XE 2.6 release. The rationale is that we've been developing lots of new features in the past releases and I think it's time to stabilize what we have. By stabilize I mean: - fix bugs - homogenize UI - clean up stuff (refactoring, etc) In addition we have 2 features we had planned for 2.5 which have slipped and we could finish them in 2.6 too (Sergiu said he was almost done with the "Email this page" feature and didn't have the time to slip it in the 2.5): - Email this page: Sergiu - Recent Activity (refactoring of Recent Changes based on the Activity Stream): Raluca + Caty + JV to apply the patch The idea would be to have the following dates: - 2.6RC1: 1st of November 2010 (there's no M1) - 2.6 final: 18h of November If we agree, is there anyone who'd like to be the release manager for this release? If nobody volunteers I can do it. If we agree, I'll send another mail afterwards with some ideas for XE 2.7 and a potential XE 3.0 release. Note that XE 2.6 would be a first step in stabilizing XE for an upcoming 3.0 release :) But even without this vision doing a short stabilization release from time to time is always a good think I believe. It's also not too long so that people don't need to hold new stuff for too long. Here's my +1 Thanks -Vincent

14 years, 11 months

11
22
0 0

[xwiki-devs] [Proposal] Transformation activation

by Vincent Massol

Hi, Requirement ========== UC1: ability to package transformations in the platform that are not enabled by default (for ex WikiWordTransformation) UC2: ability in the future to install a new transformation using the extension manager and make it active without restarting xwiki (and without complex operations to activate it) UC3: ability to have a list of transformations active in a given part of the xwiki code and another list in another part of the code Proposal ======= * Introduce a XWikiTransformationManager implementation (hint = "xwiki"), located in xwiki-core/ * Make it use CoreConfiguration and introduce core.viewTransformations configuration properties (in some future we'll have a separate module to perform page rendering - The rendering module is about rendering content not pages). Ex: core.transformations = macro, icon (values are role hints) * Default property value would be: macro, icon * DefaultTransformationManager will continue to exist and be part of the rendering module (and runs all transformation it can find). We could decide to remove it at some point if we don't see any value although it could stay as an example implementation in the rendering module (which can be used standalone). This proposal solves UC1 and UC3. It's less clear how it can solve UC2. When the extension manager is available we could simply remove this configuration property and simply "deactivate" a given transformation, thus making it inactive. I believe this will be the best practice in the future for activating/deactivating (set of) components. There could be 2 ways: making it not part of the classloader and/or telling the component manager to unregister/register a component. Thus I believe this proposal is good enough for now. WDYT? Thanks -Vincent

14 years, 11 months

3
5
0 0

[xwiki-devs] [Proposal] Bundle the WikiWord transformation by default but not enabled

by Vincent Massol

Hi, I'd like to implement http://jira.xwiki.org/jira/browse/XWIKI-2957 (WikiWord transformation), now that we can control which transformation gets executed by default. I've done a first implementation of it here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-transformation-wik… I'd like to move this to the rendering module as a new transformation module (next to the icon transformation). WDYT? Thanks -Vincent PS: This will allow to check the "CamelCase link" feature of the wikimatrix: http://www.wikimatrix.org/show/XWiki

14 years, 11 months

6
6
0 0

[xwiki-devs] Interesting calc/sum/summary macros for syntax 2.0

by Ludovic Dubost

Hi, I've published a macro allowing to do simple calculations inside a Wiki table in syntax 2.0. http://code.xwiki.org/xwiki/bin/view/Macros/CalcMacro Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

14 years, 11 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r32196 - in platform/xwiki-plugins/trunk/activitystream: . src/main/java/com/xpn/xwiki/plugin/activitystream/api src/main/java/com/xpn/xwiki/plugin/activitystream/impl

by Vincent Massol

On Oct 26, 2010, at 6:12 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-26 18:12:09 +0200 (Tue, 26 Oct 2010) > New Revision: 32196 > > Modified: > platform/xwiki-plugins/trunk/activitystream/pom.xml > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/api/ActivityEventType.java > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/impl/ActivityStreamImpl.java > Log: > XPAS-19: New event types for create, edit and delete comment > XPAS-20: New event types for create, edit and delete attachment > XPAS-21: New event type for create, edit and delete annotation > Done. > Patch from Stefan Abageru applied without changes. [snip] > @@ -87,6 +96,15 @@ > add(new DocumentSaveEvent()); > add(new DocumentUpdateEvent()); > add(new DocumentDeleteEvent()); > + add(new CommentAddEvent()); > + add(new CommentDeleteEvent()); > + add(new CommentUpdateEvent()); > + add(new AttachmentAddEvent()); > + add(new AttachmentDeleteEvent()); > + add(new AttachmentUpdateEvent()); > + add(new AnnotationAddEvent()); > + add(new AnnotationDeleteEvent()); > + add(new AnnotationUpdateEvent()); hmm this doesn't look right. I don't think the activity stream should know about all modules. Also this won't work when you add a new module which offers new events. There's a design problem. > } > }; > > @@ -875,21 +893,61 @@ > if (!Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()) { > String eventType; > String displayTitle; > - > + String additionalIdentifier = null; > + > if (event instanceof DocumentSaveEvent) { > eventType = ActivityEventType.CREATE; > displayTitle = currentDoc.getDisplayTitle(context); > } else if (event instanceof DocumentUpdateEvent) { > eventType = ActivityEventType.UPDATE; > displayTitle = originalDoc.getDisplayTitle(context); > - } else { // event instanceof DocumentDeleteEvent > + } else if (event instanceof DocumentDeleteEvent) { > eventType = ActivityEventType.DELETE; > displayTitle = originalDoc.getDisplayTitle(context); > + } else if (event instanceof CommentAddEvent) { > + eventType = ActivityEventType.ADD_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentAddEvent) event).getComment(); > + } else if (event instanceof CommentDeleteEvent) { > + eventType = ActivityEventType.DELETE_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentDeleteEvent) event).getComment(); > + } else if (event instanceof CommentUpdateEvent){ > + eventType = ActivityEventType.UPDATE_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentUpdateEvent) event).getComment(); > + } else if (event instanceof AttachmentAddEvent){ > + eventType = ActivityEventType.ADD_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentAddEvent) event).getName(); > + } else if (event instanceof AttachmentDeleteEvent){ > + eventType = ActivityEventType.DELETE_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentDeleteEvent) event).getName(); > + } else if (event instanceof AttachmentUpdateEvent){ > + eventType = ActivityEventType.UPDATE_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentUpdateEvent) event).getName(); > + } else if (event instanceof AnnotationAddEvent){ > + eventType = ActivityEventType.ADD_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationAddEvent) event).getIdentifier(); > + } else if (event instanceof AnnotationDeleteEvent){ > + eventType = ActivityEventType.DELETE_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationDeleteEvent) event).getIdentifier(); > + } else { // update annotation > + eventType = ActivityEventType.UPDATE_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationUpdateEvent) event).getIdentifier(); This also looks like a design issue. It's a lot of "if"s and duplicated code. [snip] In general this whole commit really smells like some code that was done without refactoring in mind. It shows problems but the time wasn't taken to refactor the issues IMO. Let's do that now since otherwise we're introducing technical debt. Thanks -Vincent

14 years, 11 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r32192 - platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event

by Vincent Massol

We need to decide where to put events but I think it's wrong to put them in the observation-api package. Thanks -Vincent On Oct 26, 2010, at 6:01 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-26 18:01:34 +0200 (Tue, 26 Oct 2010) > New Revision: 32192 > > Added: > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractAnnotationEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractAttachmentEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractCommentEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationAddEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationDeleteEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationUpdateEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentAddEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentDeleteEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentUpdateEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentAddEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentDeleteEvent.java > platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentUpdateEvent.java > Log: > XWIKI-5622: New event types: add/update/delete comment/annotation/attachment > Done. > Patch from Stefan Abageru applied with a bit of changes.

14 years, 11 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r32194 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki

by Vincent Massol

On Oct 26, 2010, at 6:01 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-26 18:01:43 +0200 (Tue, 26 Oct 2010) > New Revision: 32194 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > Log: > XWIKI-5624: Send observation events for adding/editing/deleting comments, annotations, and attachments > Done. > [snip] > > + for (AttachmentDiff diff : doc.getAttachmentDiff(originalDoc, doc, context)) { > + if (StringUtils.isEmpty(diff.getOrigVersion())) { > + om.notify(new AttachmentAddEvent(reference, diff.getFileName()), source, data); > + } else if (StringUtils.isEmpty(diff.getNewVersion())) { > + om.notify(new AttachmentDeleteEvent(reference, diff.getFileName()), source, data); > + } else { > + om.notify(new AttachmentUpdateEvent(reference, diff.getFileName()), source, data); > + } > + } > + } catch (XWikiException ex) { > + // TODO Auto-generated catch block > + ex.printStackTrace(); This is definitely wrong and needs to be fixed. > + } > + } > + > + private static final List<Event> LISTENER_EVENTS = new ArrayList<Event>() > + { > + { > + add(new DocumentSaveEvent()); > + add(new DocumentUpdateEvent()); > + add(new DocumentDeleteEvent()); > + } > + }; > + > + public List<Event> getEvents() > + { > + return LISTENER_EVENTS; > + } > + > + public String getName() > + { > + return "xwiki-core"; I don't think this is a good name, at least it's not following current practices. Thanks -Vincent

14 years, 11 months

1
0
0 0

[xwiki-devs] [discussion] Easier way to get configuration into modules.

by Caleb James DeLisle

I was wondering how the current method of configuration came into existence. I googled against the lists and didn't see anything particularly enlightening. IMO the promise of component management is "you ask for it and it's there". The best way I can imagine to ask for a configuration parameter would be: @Requirement("my-module.param") private String configParam = "default value"; If no parameter was defined then "default value" would be the value. Since I imagine making the component manager inject a String and know that it's a configuration parameter would be horrible, I would have chosen a workaround by creating an interface and class which is shared among all consumers of configuration. Something like: public interface ConfigurationString { java.lang.String get(); ConfigurationString default(java.lang.String); } Then to get the configuration parameter you need: @Requirement("my-module.param") private ConfigurationString myParam = ConfigurationString.default("default value"); Since the benefits of writing 2 lines to get a configuration parameter vs. writing 2 classes seem obvious, I assume that this idea was reviewed and cast aside and I was wondering why it was decided that something like this was the wrong approach. If anyone could shed some light on this, I'd appreciate it. Thanks Caleb

14 years, 11 months

2
1
0 0

[xwiki-devs] [VOTE] Don't [VOTE] for promoting contrib projects out of sandbox

by Jerome Velociter

Hey devs, I'd like to vote on changing the rule about promotion of contrib projects out of sandbox (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HPromotingaprojectouto… ), in particular skipping the VOTE part. The main reason is that contrib projects are not managed nor endorsed by the XWiki Development team, so it should not be their call to approve project promotion from sandbox/ to projects/ +1 to remove the need to VOTE, and to let project owners decide for themselves (either as individual developers, or as team decisions) when their project is ready to go out of the sandbox (usually this happens when a first release is needed). Jerome.

14 years, 11 months

7
7
0 0

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

by Sergiu Dumitriu

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.5 and XWiki Enterprise Manager 2.5. Go grab them at http://www.xwiki.org/xwiki/bin/view/Main/Download The highlights of this release are: * support for viewing attached office documents in the wiki * a new User Directory * an experimental Extension Manager * improvements to action menus * further improvements to the edit UI * support for activating a special accessibility stylesheet * more consistent use of user avatars * an experimental xwiki/2.1 wiki syntax * a mechanism for inserting custom links in the header * the introduction of cancelable events * better external search engine indexing support * experimental CSRF protection * experimental Cryptographic Module For more information, see the Release notes at http://www.xwiki.org/xwiki/bin/Main/ReleaseNotesXWikiEnterprise25 and http://www.xwiki.org/xwiki/bin/Main/ReleaseNotesXEM25 Thanks -The XWiki dev team

14 years, 11 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r32162 - in platform/core/trunk: . xwiki-component/xwiki-component-observation xwiki-core xwiki-crypto xwiki-csrf xwiki-extension xwiki-management xwiki-observation/xwiki-observation-api xwiki-office xwiki-rendering/xwiki-re

by Thomas Mortagne

On Mon, Oct 25, 2010 at 18:40, sdumitriu <platform-notifications(a)xwiki.org> wrote: > Author: sdumitriu > Date: 2010-10-25 18:40:28 +0200 (Mon, 25 Oct 2010) > New Revision: 32162 > > Modified: > platform/core/trunk/pom.xml > platform/core/trunk/xwiki-component/xwiki-component-observation/pom.xml > platform/core/trunk/xwiki-core/pom.xml > platform/core/trunk/xwiki-crypto/pom.xml > platform/core/trunk/xwiki-csrf/pom.xml > platform/core/trunk/xwiki-extension/pom.xml > platform/core/trunk/xwiki-management/pom.xml > platform/core/trunk/xwiki-observation/xwiki-observation-api/pom.xml > platform/core/trunk/xwiki-office/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-container/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-dashboard/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-transformations/xwiki-rendering-transformation-icon/pom.xml > platform/core/trunk/xwiki-rest/xwiki-rest-model/pom.xml > platform/core/trunk/xwiki-rest/xwiki-rest-server/pom.xml > Log: > [misc] Updated clirr skips > > Modified: platform/core/trunk/pom.xml > =================================================================== > --- platform/core/trunk/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -37,7 +37,7 @@ > <description>XWiki Platform - Core - Parent POM</description> > <properties> >  > - <clirr.previous.version>2.5-rc-1</clirr.previous.version> > + <clirr.previous.version>2.5</clirr.previous.version> > </properties> > <scm> > <connection>scm:svn:http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk</connection> > @@ -194,27 +194,6 @@ > exclude it for the moment. See http://bit.ly/c5Jnho Remove this exclude when the problem is fixed > in CLIRR. --> > <exclude>org/xwiki/officeimporter/openoffice/OpenOfficeManager$ManagerState</exclude> > -  > -  > - <exclude>org/xwiki/component/descriptor/ComponentInstantiationStrategy</exclude> > - <exclude>org/xwiki/model/EntityType</exclude> > - <exclude>org/xwiki/cache/eviction/EntryEvictionConfiguration$Algorithm</exclude> > - <exclude>org/xwiki/cache/tests/CacheEntryListenerTest$EventType</exclude> > - <exclude>org/xwiki/url/XWikiURLType</exclude> > - <exclude>org/xwiki/rendering/listener/Format</exclude> > - <exclude>org/xwiki/rendering/listener/HeaderLevel</exclude> > - <exclude>org/xwiki/rendering/listener/ListType</exclude> > - <exclude>org/xwiki/rendering/listener/chaining/BlockStateChainingListener$Event</exclude> > - <exclude>org/xwiki/rendering/listener/chaining/EventType</exclude> > - <exclude>org/xwiki/rendering/listener/chaining/EventType$*</exclude> > - <exclude>org/xwiki/formula/FormulaRenderer$FontSize</exclude> > - <exclude>org/xwiki/formula/FormulaRenderer$Type</exclude> > - <exclude>org/xwiki/rendering/macro/toc/TocMacroParameters$Scope</exclude> > - <exclude>org/xwiki/rendering/macro/include/IncludeMacroParameters$Context</exclude> > - <exclude>org/xwiki/rendering/macro/wikibridge/WikiMacroVisibility</exclude> > - <exclude>org/xwiki/annotation/maintainer/AnnotationState</exclude> > - <exclude>org/xwiki/annotation/renderer/AnnotationEvent$AnnotationEventType</exclude> >  > <exclude>org/xwiki/rendering/listener/reference/ResourceType</exclude> > <exclude>org/xwiki/bridge/SkinAccessBridge</exclude> > > Modified: platform/core/trunk/xwiki-component/xwiki-component-observation/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-component/xwiki-component-observation/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-component/xwiki-component-observation/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -33,10 +33,6 @@ > <name>XWiki Platform - Core - Component - Observation</name> > <packaging>jar</packaging> > <description>XWiki Platform - Core - Component - Observation</description> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> > <dependency> > <groupId>commons-logging</groupId> > > Modified: platform/core/trunk/xwiki-core/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-core/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-core/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -1431,9 +1431,6 @@ > <includes> > <include>**/api/**</include> > </includes> > - <excludes> > - <exclude>com/xpn/xwiki/user/api/XWikiGroupService</exclude> > - </excludes> > </configuration> > </plugin> > </plugins> > > Modified: platform/core/trunk/xwiki-crypto/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-crypto/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-crypto/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -32,10 +32,6 @@ > <artifactId>xwiki-core-crypto</artifactId> > <name>XWiki Platform - Core - Cryptographic Services</name> > <description>XWiki Platform - Core - Cryptographic Services</description> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> >  > <dependency> > > Modified: platform/core/trunk/xwiki-csrf/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-csrf/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-csrf/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -33,10 +33,6 @@ > <name>XWiki Platform - Core - CSRF</name> > <packaging>jar</packaging> > <description>XWiki CSRF Protection Module</description> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> > <dependency> > <groupId>org.xwiki.platform</groupId> > > Modified: platform/core/trunk/xwiki-extension/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-extension/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-extension/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -33,10 +33,6 @@ > <name>XWiki Platform - Core - Extension</name> > <packaging>pom</packaging> > <description>XWiki Platform - Core - Extension</description> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> As you can see in the comment this is to be removed when 2.6 is released, not 2.5. The reason is that it has been refactored as several module instead of only one in 2.5 branch. > <modules> > <module>xwiki-extension-api</module> > <module>xwiki-extension-handlers</module> > > Modified: platform/core/trunk/xwiki-management/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-management/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-management/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -56,9 +56,5 @@ > </plugin> > </plugins> > </build> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > </project> > > > Modified: platform/core/trunk/xwiki-observation/xwiki-observation-api/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-observation/xwiki-observation-api/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-observation/xwiki-observation-api/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -34,10 +34,6 @@ > <name>XWiki Platform - Core - Observation - API</name> > <packaging>jar</packaging> > <description>XWiki Platform - Core - Observation - API</description> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> > <dependency> > <groupId>org.xwiki.platform</groupId> > > Modified: platform/core/trunk/xwiki-office/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-office/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-office/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -64,9 +64,4 @@ > </plugin> > </plugins> > </build> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > </project> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-container/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-container/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-container/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -50,8 +50,4 @@ > </plugin> > </plugins> > </build> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > </project> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-dashboard/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-dashboard/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-dashboard/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -56,8 +56,4 @@ > <version>${project.version}</version> > </dependency> > </dependencies> > - <properties> > -  > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > </project> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-transformations/xwiki-rendering-transformation-icon/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-transformations/xwiki-rendering-transformation-icon/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-transformations/xwiki-rendering-transformation-icon/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -34,6 +34,7 @@ > <name>XWiki Platform - Core - Rendering - Transformation - Icon</name> > <description>XWiki Platform - Core - Rendering - Transformation - Icon</description> > <properties> > +  > <xwiki.clirr.skip>true</xwiki.clirr.skip> > </properties> > </project> > > Modified: platform/core/trunk/xwiki-rest/xwiki-rest-model/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rest/xwiki-rest-model/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-rest/xwiki-rest-model/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -32,10 +32,6 @@ > <artifactId>xwiki-rest-model</artifactId> > <name>XWiki Platform - Core - REST - Model</name> > <description>The (JAXB) model for XML resource representations served by the REST module.</description> > -  > - <properties> > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> > <dependency> > <groupId>javax.xml.bind</groupId> > > Modified: platform/core/trunk/xwiki-rest/xwiki-rest-server/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rest/xwiki-rest-server/pom.xml 2010-10-25 16:25:07 UTC (rev 32161) > +++ platform/core/trunk/xwiki-rest/xwiki-rest-server/pom.xml 2010-10-25 16:40:28 UTC (rev 32162) > @@ -34,10 +34,6 @@ > <packaging>jar</packaging> > <name>XWiki Platform - Core - REST - Server</name> > <description>Service for accessing XWiki through a RESTful API</description> > -  > - <properties> > - <xwiki.clirr.skip>true</xwiki.clirr.skip> > - </properties> > <dependencies> > <dependency> > <groupId>javax.servlet</groupId> > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

14 years, 11 months

1
0
0 0

[xwiki-devs] Real-time collaboration editor prototype

by Bogdan Flueras

Hello XWiki devs, Sorry for postponing this message and about seeing confusing svn commit messages! The partenership between XWiki and Loria(http://www.loria.fr) has produced an integrated editor (prototype still..) that allows real time collaboration. It means that it'll allow multiple users to concurrently edit the same xwiki page without stepping on each other toes... just like in GoogleWave, GoogleDocs aso. Thus I invite you to check it out: http://svn.xwiki.org/svnroot/xwiki/contrib/projects/wiki30/ give it a try (INSTALL.txt) and let me know WDYT. Feel free to use the mailing list as well as JIRA: http://jira.xwiki.org/jira/browse/WIKITHREEDOTO/ for bugs, comments, improvements ... Best regards and looking forward hearing from you! -- ing. Flueras Bogdan

14 years, 11 months

2
1
0 0

[xwiki-devs] [Proposal] Adding sibling information to rendering Block API + get/setNextSibling()

by Vincent Massol

Hi, I'm adding sibling information to the Block API in the rendering module. There are 3 reasons for this: 1) It'll make a lot of existing method implementations much faster since right now in order to insert or find blocks we have to traverse the list/tree. 2) There's a bug in the current implementation for SpaceBlock since it's immutable and we have a single instance of it. Thus when there are several SpaceBlock in a list doing a list.indexOf(SpaceBlock) will always return the first space block even if you're looking for a subsequent space block. 3) I'm implementing a generic emoticon Transformation and I need to get the sibling of a block. Just shout if you think there's a better way of doing it. I'm implementing it now. Thanks -Vincent

14 years, 11 months

3
3
0 0

[xwiki-devs] Velocity in title

by [Ricardo Rodriguez] eBioTIC.

Hi all! Please, is possible to include Velocity script in documents' title of a 1.3.8295 installation? Thanks! Cheers, Ricardo -- Ricardo Rodríguez CTO eBioTIC. Life Sciences, Data Modeling and Information Management Systems

14 years, 11 months

4
7
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.4.4 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.4.4. Important bug fixed: * XWIKI-5542 - Different rights in view and rest mode * XWIKI-5597 - File upload plugin doesn't strip the file path in IE * XWIKI-5598 - When importing a XAR, ignoring translated documents does not work * XWIKI-5309 - rest api query called by XE JumpToPage causes performance problem and even deadlock * XWIKI-5387 - Apache commons URIUtil is potentially unsafe * XWIKI-4366 - Blockquote is badly parsed when multiple lines are styled together * XWIKI-5525 - DBList request level cache is ignored * XWIKI-5591 - HTML to Wiki Syntax 2 looses color in certain cases * XWIKI-5599 - In the XAR importer UI, the initial space document count is wrong whenever that space has translated documents * XWIKI-5530 - LDAP module: Impossible to login with the same UID if your DN changes * XWIKI-5523 - NPE during parsing of a sequence table/style/paragraphe/paragraphe * XAANNOTATIONS-32 - Highlight does not disappear after deleting the last annotation from a page For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise244 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM244 Thanks -The XWiki dev team

14 years, 11 months

1
0
0 0

[xwiki-devs] [VOTE] Release XE and XEM 2.5

by Sergiu Dumitriu

Hi devs, I'd like to start releasing 2.5 this Friday, so that users can test the build until Monday. Are there still blocking issues that you'd like to fix? -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 11 months

7
8
0 0

[xwiki-devs] Work on converting from synthax 1.0 to 2.0

by Stefan abageru

Hello guys ! I am starting working on converting the documents in space Panels. In case anybody is working on it right now, please let me know :) Stefan

14 years, 11 months

4
3
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