Hi devs,
Some methods must be captured so that they don't create output when
called from velocity, usually with something like:
#set ($var = $obj.doSomething())
Where $var is a variable whose content isn't needed and won't be used.
And everyone seems to have his favorite name for it: $discard, $ok,
$ignore...
I'd like to have a single variable name, so that in the end we don't end
up creating 5 different variables for the same goal. So, which one do
you prefer:
1. $discard
2. $discarded
3. $ignore
4. $ignored
5. $ok
6. $output
$ok is the shortest, thus easier to type, faster to parse, and lighter
on the total size of the wiki. On the other hand, I prefer $discard
since it's more meaningful, it conveys exactly what that line does:
"$discard the output of this method call".
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
I'd like to get the XWiki on Cassandra project to be in contrib and get it building on Jenkins as soon as possible.
Unfortunately the Jenkins build requires integrating some changes into xwiki-store-filesystem-attachments which are now in the xwiki-store-legacy branch.
Todd Nine's Datanucleus-Cassandra-Plugin is nolonger being maintained by him, it is the only existing Datanucleus Cassandra plugin and my fork contains extensive changes.
It is licensed under the Apache 2 license and I would like to include it as well.
I would like to do this:
1. Move the repositories into contrib.
2. Bring the changes in the xwiki-store-legacy branch up to date and merge them into the trunk.
3. Start automated builds of Datanucleus-Cassandra-Plugin, and xwiki-store-datanucleus.
WDYT?
Caleb
Hi,
I remember once there was a contest for new XWiki logo but due to
elections fail (there would have been too many unsatisfied people if any of
newly suggested logos had been approved) the process has gracefully ended
(which, in my opinion, was a good decision)
I also think that it would be worthless to conduct another
competition/election amongst users because as the saying goes - tastes
differ. The only thing users can contribute are their ideas (which might be
accepted or might not which is fair) regarding shapes and symbols to use.
Decision about visual design should be made within very very small circle of
visual designers probably with one or two people involved in the project to
chill down designers' burning imagination :)
Having all of the above said, I would suggest to collect a set of shapes
and symbols for new XWiki logo each supplied with description of underlying
meaning. And then (having revised all of the comments in some of the former
posts regarding what new logo should be: symmetric/asymmetric,
complex/simple, round/firm) provide all that to a designer to draw several
sketches. And then by internal vote (at maximum the development team members
involved) choose the new logo.
This thread is for storing all of the ideas on the new XWiki logo. At
least that's what I (as a user) will be using it for may any ideas to come.
Join :)
Regards,
Roman
--
View this message in context: http://xwiki.475771.n2.nabble.com/XWiki-logo-around-tp6074956p6074956.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I've been finding that Jetty takes a lot of time to start lately. So I've run some profiling on it.
Starting Jetty (till the STARTING message) takes 15 seconds on my machine (in debug mode, we win 3 seconds, ie 12s start time), split like this:
* 50% of the time spent scanning jars in WEB-INF/lib (JarInputStream.getNextJar()) - 7s
* 10% in Jetty itself - 2s
* 40% in our code in Extension Manager init (2.5s) and in Component registration from their annotations (2.5s) - 5s
If I remove the start of the EM in XWikiServletContextListener, we start in 7 seconds (instead of 15s)
If I try to start Jetty without any webapp, it starts in 500ms.
If I remove the oldcore legacy jar (2.5MB) we win 1 second in start up time.
Note: This is all before XWiki.init() is called on the first request.
Analysis of ComponentAnnotationLoader (2.5s):
* 1.2s just loading classes from the CL
* 1s getDeclaredFields (reflection API)
* 800ms initializing SLF4J
Analysis of Extension Manager init (2.5s):
* In DefaultCoreExtensionScanner.loadExtensions():
** 500ms URL.toURI()
** 500ms MavenXpp3Reader.read() - POM reading
** 150ms org.Reflections scanning
** 150ms resource loading from CL (getResourceAsStream())
* In DefaultExtensionLicenseManager.initialize()
** 314ms in org.Reflections
* 130ms of loading xwiki.properties
Conclusion
=========
* XWiki's size in number of JARs and their sizes makes it long to start Jetty.
* We could make some small optimizations in EM and Component loading but we wouldn't win that much, on the order of 2s in total (i.e. 15% of total load time)
Thanks
-Vincent
Hi devs,
The 3.3 Milestone 2 release was supposed to happen this past Monday, but
the codebase hasn't been stable enough for a release (failing tests, hot
commits triggering comments, unmerged branches).
Proposal 1: Release 3.3 RC 1 next Monday, 21 November, effectively
dropping Milestone 2. This respects the initial schedule, although some
of the targeted features won't be fully usable. This means that everyone
should try to get their code stabilized.
Proposal 2: Lengthen the release by another week, releasing:
- Milestone 2 next Monday, November 21
- RC1 on November 28
- Final on December 5
I'm fine with either one, if the codebase is stable enough for a RC by
next Monday.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Since we're going to use Maven POM metadata to display extensions in the Extension Manager UI it's important that we have all data filled and with correct value.
Sergiu pointed to me that currently our website <url> are wrong.
This is because the top level POM has <url>http://xwiki.org</url> and Maven automatically suffixes it with artifact Ids.
For example for Commons Component API this gives us:
<url>http://xwiki.org/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-compone…</url>
which is not pointing to anything valid.
I see 2 ways of fixing this:
Solution 1
========
Do as I started this morning, i.e. set the <url> explicitly. For example I've set PHP Macro module URL this morning to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/PHP+Macro</url> and Commons Observation API (the 3 modules: parent + api + local) to <url>http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module</url>.
Pros:
- Easy and we can point to wherever the documentation is located
Cons:
- Tedious
- Fragile. If we rename a page on the wiki then the link is broken
Solution 2
========
Set the top level URL to something like:
<url>http://xwiki.org/documentation?id=</url>
For example for Commons Component API this will generate:
<url>http://xwiki.org/documenation?id=/xwiki-commons-pom/xwiki-commons-core/xwik…</url>
Then:
* Have an apache redirection for /documentation to some wiki page such as http://xwiki.org/xwiki/bin/view/Main/ModuleDocumentation
* Have the logic inside that page to transform paths (such as "/xwiki-commons-pom/xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-api" into proper URLs). Since I don't think we can have a generic logic, I'd simply put a big hashtable to start with.
Pros:
- Simple, no need to modify all poms. We only need to change the top level pom <url> value
- Much easier to keep up to date since when we rename pages all we need to do is edit the ModuleDocumentation page. Actually when we support page renames across wikis we could have the links in that page be automatically renamed ;) With Solution 1, when you rename the URL you need to re-release the module which is a big pain.
Cons:
- I can't see any really :) We just need to be sure that http://xwiki.org/documentation is available.
So I'm definitely for 2, WDYT?
Thanks
-Vincent
Hi
Today I tried to create a custom mapping for a class. One field of the
class is a DBList with the "Multiple Select" option activated. To save
the values to the DB I wanted to use a string field like I'm used to
with static lists and non multi select DB lists. Now I get the
following exception when trying to save a Document with an object
attached: "java.util.ArrayList cannot be cast to java.lang.String"
How could I custom map a DBList field if String ist not possible? or
is there even a simple Solution I missed?
A hint in the right direction would be appreciated
Edo
Hi Devs,
I've created a new FAQ application currently located at http://www.xwiki.org/xwiki/bin/view/FAQ/WebHomeNew
I'd like to publish it in platform since we need to maintain it anyway for xwiki.org (I'm also ok to maintain it).
Here's my +1
Thanks
-Vincent