Hi devs,
As you may have seen, I've been working on the new model in a branch.
We need to decide on the naming of the Entity classes (wiki, space, document, object, object definition, etc).
We have several possibilities I know of for naming them:
1) Wiki, Space, Document, Object, ObjectDefinition
2) WikiEntity, SpaceEntity, DocumentEntity, ObjectDefinitionEntity
3) Wiki, Space, Document, XObject, XObjectDefinition (or simply ObjectDefinition)
4) XWiki, XSpace, XDocument, XObject, XObjectDefinition
5) Some other name for objects.
Some concerns:
* Using Object as in 1) is a bit of a pain since there's java.lang.Object which forces to use the FQN name when coding in Java. Which is why I've put proposals 2) and 3)
* In proposal 3) there's a bit of an inconsistency with the X in XObject which is not present in the other entity names, hence proposal 4 and 2)
* In proposal 1) there can be some other clashes. For example Document can clash with the DOM Document object
My personal vote goes to 2), even though it makes the entity names a bit longer.
Cast your votes!
Thanks
-Vincent
Hi,
I wanted to discuss about the future of the mailsender plugin ?
I've been working on a small tool to be able to send a Calendar Invitation
by email from a Meeting Notes AppWithinMinutes application and I found some
limitation in the mailsender plugin, namely you cannot add multipart
alternative email parts in addition to the text and html parts already
supported by the plugin.
I was able to hack the mailsender plugin to add a vcalendar part but it
does not really sound right to do that since we should support any part of
any content type, but this is a bigger refactoring.
I was wondering what the future is for the mailsender plugin. Do we plan to
make it a component and keep the same functionality ? Is there a plan for
an alternative component ?
And what would be the approach to add a vcalendar part in emails sent by
the current mailsender ? This would be needed to support the feature of
sending invitation emails which would be very powerfull.
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
We've moved more and more toward an UTF-8-only application, and XWiki
has only been tested with this configuration for several years.
I propose that we require UTF-8 for a valid, supported installation.
This means:
- JVM encoding (-Dfile.encoding=UTF8)
- Container default URL encoding (Tomcat has ISO-8859-1 by default)
- Database encoding (MySql is still configured with latin1 on some distros)
There's one big site to update on our side: xwiki.org.
Here's my +1. This is a move toward a future web, since more and more
standards require (or at least assume as a default) UTF-8.
After thinking a bit more, it would make sense to require a valid
Unicode encoding, including UTF-16, which is preferable in countries
that don't use a latin alphabet. However, XWiki doesn't currently work
under 16-bit encodings at all.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
Hi Devs!
Thought you might be interested
http://www.diagram.ly/
Roman Muntyanu | rmuntyan(a)softserveinc.com<mailto:rmuntyan@softserveinc.com> | Project Manager | SoftServe<http://www.softserveinc.com/> Inc. | +380-32-240-9090 x3738
Hi devs,
We have recently voted a rule where we said that we will do the following:
* Always deprecate APIs
* Always move them to Legacy modules
* And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API
(see http://markmail.org/message/tino4ngttflc5i3s).
This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR.
However I've seen that we have added some CLIRR excludes after the vote was passed.
I believe that the main issue we have is for "young" APIs that are not considered stable.
Proposal 1: Internal package
=========
* Young APIs must be located in the "internal" package till they become stable. I propose "internal" to reuse an existing package that we filter when testing for CLIRR. "internal" means that users should not use this API because it's considered unstable and can change at any time.
* When a Young API is considered stable enough and we want to open it to public consumption then we move it from "internal" to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy.
* If we want to add a new method to an existing public API then this should not be considered a "young" API. It's just an addition to an existing API and thus goes directly to the deprecation/legacy cycle.
* We need to be careful to isolate "young" APIs from public API so that users don't inadvertently use "young" unstable APIs by mistake. If not possible then directly go through the deprecation/legacy cycle.
The advantage of this proposal is that it doesn't change our current practices and is very easy to verify through CLIRR.
Proposal 2: Experimental package
=========
Another possibility I can think of is to introduce a new "experimental" package instead of reusing the "internal" one. It has the advantage of being able to follow "young" APIs and ensure they don't stay in that state indefinitely, while still allowing the user who uses it to notice it's experimental.
Proposal 3: Experimental Annotation
=========
Another idea is to just use an @Experimental javadoc tag for experimental code. It has the advantage of using the target package but it has drawbacks:
* It's impossible for users to notice that they're using Experimental APIs since when they import a class they won't see anything that'll tell them they're using a "young" API
* It's almost impossible to tell CLIRR to exclude those APIs from its checks. The only way to do this is to modify the source code of the CLIRR plugin AFAIK. Thus we would need to exclude those manually using CLIRR excludes and thus before we release we would need to go over the full list of CLIRR excludes to ensure the excludes listed are only for "young" APIs marked "experimental".
Note that I mentioned javadoc tag and not annotation because I believe we need to add information about when the Experimental API was first introduced so that we eventually move it as a proper API by removing the Experimental tag. Maybe we would need a rule such as: keep that tag for less or equal to 3 full minor releases (i.e. 6 months).
WDYT? Any other idea?
Thanks
-Vincent
Hi devs,
Well, the subject pretty much sums it up. I am proposing to skip any
testing while building a release, since that is the job of the CI
infrastructure and, it happened more than once for the build of the release
to fail because of a flickering test. This is really annoying for a release
manager that has to start over the entire build (since right now it's a
real pain to alter the scripts to continue the build).
Besides this, tests (specially the functional ones added into platform)
uselessly delay the build, thus, the release.
Note: We are already skipping tests for enterprise and manager. This vote
is actually about skipping tests for commons, rendering and platform as
well.
Here's my +1.
Thanks,
Eduard
Hi devs,
The last piece missing to the new localization framework for 4.x is to
allow providing translations in a jar extension.
Here are some ideas:
1) Continue with ApplicationResources_*.properties files but loads it from
everywhere instead of taking the first one we find like now
2) Same that 1) but place it somewhere a bit "cleaner" like
org/xwiki/localization/translation_*.properties
3) Completely different system. I looked a bit if any simple de facto
standard was already existing but was not obvious.
Keep in mind the localization framework allow providing any source so it's
easy to move/add a new way to get translations in jar extensions later
without touching the API so while it would be better to do something good
it's mostly implementation details and whatever we choose we are not going
to be stuck with it forever.
WDYT ?
I would go for 2) (I'm +0 for 1)) with
org/xwiki/localization/translation_*.properties for 4.x and keep 3) for
later when we have some time to work on it a bit more.
--
Thomas Mortagne