fyi. Seems like we can now refactor our ubespector to use Sergiu's
patch that was committed in Velocity 1.6. Well done Sergiu :)
Also this is very intriguing:
"macro libraries to be programatically included when calling
template.merge(...)"
-Vincent
Begin forwarded message:
> From: "Nathan Bubna" <nbubna(a)apache.org>
> Date: December 3, 2008 7:04:03 AM CEST
> To: announce(a)apache.org, announcements(a)jakarta.apache.org, dev(a)velocity.apache.org
> , user(a)velocity.apache.org
> Subject: [ANNOUNCE] Apache Velocity 1.6
>
> The Apache Velocity Team announces the immediate availability of the
> of Apache Velocity Engine 1.6. This release is fully compatible with
> the previous release and includes significant improvements in
> performance, stability and features.
>
> Apache Velocity is well-known in the Java field as a lightweight,
> easy-to-use templating library for creating dynamic web sites and
> performing other text-generation tasks.
>
> Much work in this release has gone to making significant improvements
> in the memory usage and speed of Velocity. Apart from this, a number
> of small parser bugs were fixed, tempate/line/column information in
> error messages has been corrected and made consistent, and many new
> features were added. Many of the latter are listed below:
>
> * There are three new directives:
> - #evaluate takes a single string of VTL as an argument and renders
> it.
> - #define is a cousin of #macro, that lets define a reference that
> represents the body of the directive, which is then evaluated when the
> reference is used.
> - #break lets you exit a #foreach loop early.
>
> * There are reflection improvements:
> - You may now call JDK 1.5 vararg methods on your tools and other
> references with variable arguments.
> - You can put a static utility class directly into the context and
> be able to call its methods; no instance necessary. (e.g.
> context.put("Math", java.util.Math.class))
> - If you have a reference that is an array, you can now call
> fixed-length list methods on it. (e.g. $array.size() and
> $array.get($index) )
> - There is now support for chaining and linking Uberspect
> implementations to simplify custom introspection.
>
> * The underlying Velocimacro code has been refactored to allow:
> - Much, much better performance than Velocity 1.5
> - #parse( 'mymacros.vm' ) to work as expected!!
> - macro libraries to be programatically included when calling
> template.merge(...)
> - users to configure a velocimacro.max.depth property (to limit
> recursion et al)
>
> * CommonsLogLogChute and ServletLogChute are now available without
> including VelocityTools
>
> * The StringResourceLoader has undergone major refactoring to make it
> much more user-friendly and flexible.
>
> * There is now an automatic $velocityHasNext reference in #foreach
> loops
>
> * You can now configure the connection timeout for URLResourceLoader
> (JDK 1.5+ only)
>
> Documentation Velocity 1.6 can be found here:
> http://velocity.apache.org/engine/releases/velocity-1.6/
>
> The change log is here:
> http://velocity.apache.org/engine/releases/velocity-1.6/changes-report.html
>
> Apache Velocity 1.6 can be downloaded here:
> http://velocity.apache.org/download.cgi
>
> For the Apache Velocity Team
> Nathan Bubna
On Fri, Dec 5, 2008 at 4:20 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
> tmortagne (SVN) wrote:
>> Author: tmortagne
>> Date: 2008-12-04 14:00:49 +0100 (Thu, 04 Dec 2008)
>> New Revision: 14542
>>
>> Log:
>> XWIKI-2824: Support multiwiki using path urls and not host urls
>>
>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java
>> ===================================================================
>> + public String getServletPath(String wikiName, XWikiContext context)
>> + {
>> + // unless we are in virtual wiki path mode we should return null
>> + if (!context.getMainXWiki().equalsIgnoreCase(wikiName) && "1".equals(Param("xwiki.virtual.usepath", "0"))) {
>> + String database = context.getDatabase();
>> + try {
>> + context.setDatabase(context.getMainXWiki());
>> + XWikiDocument doc = getDocument(getServerWikiPage(wikiName), context);
>> + BaseObject serverobject = doc.getObject("XWiki.XWikiServerClass");
>> + if (serverobject != null) {
>> + String server = serverobject.getStringValue("server");
>> + return "wiki/" + server + "/";
>> + }
>> + } catch (Exception e) {
>> + LOG.error("Failed to get URL for provided wiki [" + wikiName + "]", e);
>> + } finally {
>> + context.setDatabase(database);
>> + }
>> + }
>> +
>
> This means that only struts is accepted for this kind of virtual
> servers? What about xmlrpc, webdav, wysiwg, gwt, and the incoming REST?
It's really difficult to have a full support of url based multiwiki
with the current tricky way of handling URLs (it's already pretty
difficult to support only struts without breaking anything...). We
really need the unique component based entry point we discussed and
get rid of struts.
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
Marius Dumitru Florea wrote:
> Sorry. I'm keeping only the important part this time.
>
> Marius Dumitru Florea wrote:
>> Look at the end,
>>
>> lucaa (SVN) wrote:
>>> Author: lucaa
>>> Date: 2008-12-04 21:46:47 +0100 (Thu, 04 Dec 2008)
>>> New Revision: 14553
>>>
>
> [snip]
>
>>> -div.clear {
>>> +.xImagePreviewSelected img {
>>> + border: solid 2px #FFA500;
>>> +}
>>> +
>>> +div.clearfloats {
>> You either use the clearfloats class from the current skin or make the
>> selector specific to the image plugin.
>>
>>> clear: both;
>>> + display: none;
>> Does this work? From what I know if you set the display to none the DOM
>> elements matched by the selector are not displayed thus they are not
>> part of the flow thus they don't affect the flow.
>>
It doesn't. As you said, display: none makes clear to be ignored.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
I've created an XWiki plugin, which uses a whole lot of frameworks to
do it's job, including
WebObjects, ProjectWonder and some of our own frameworks. It's running
fine in Eclipse.
When I package the resulting webapp from the workspace's server area
(.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/xe-
debug-web)
into a war file, I can deploy the result in a webserver.
Now I would like to be able to package the xe-debug-web from the
command line
or Eclipse into a .war. However: When I invoke mvn clean package (or
any other
mvn command for that matter) inside the xe-debug-web project
directory, i get the
following error message:
mvn package :
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: xe-debug-web:xe-debug-web
Reason: Parent: null:xwiki-web-standard:war:null of project: xe-debug-
web:xe-debug-web has wrong packaging: war. Must be 'pom'. for project
xe-debug-web:xe-debug-web
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Parent: null:xwiki-
web-standard:war:null of project: xe-debug-web:xe-debug-web has wrong
packaging: war. Must be 'pom'. for project xe-debug-web:xe-debug-web
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:
430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Parent:
null:xwiki-web-standard:war:null of project: xe-debug-web:xe-debug-web
has wrong packaging: war. Must be 'pom'. for project xe-debug-web:xe-
debug-web
at
org
.apache
.maven
.project
.DefaultMavenProjectBuilder
.assembleLineage(DefaultMavenProjectBuilder.java:1377)
at
org
.apache
.maven
.project
.DefaultMavenProjectBuilder
.buildInternal(DefaultMavenProjectBuilder.java:821)
at
org
.apache
.maven
.project
.DefaultMavenProjectBuilder
.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org
.apache
.maven
.project
.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Wed Dec 03 18:41:14 CET 2008
[INFO] Final Memory: 1M/2M
[INFO]
------------------------------------------------------------------------
I don't know what to do about this message. So my thought was to
create a Maven goal
in Eclipse from the run configurations. However, the 'war' goal seems
to be quite fussy
about the layout, and the xe-debug-web project layout does not to be
satisfactory:
...
[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[xe-debug-web] in [/Users/simon/Projects/
Kontrast/MavenWorkspace/xe-debug-web/target/xe-debug-web-1.6.1]
[INFO] Processing war project
[INFO] Copy webapp webResources[/Users/simon/Projects/Kontrast/
MavenWorkspace/xe-debug-web/target/maven-shared-archive-resources] to[/
Users/simon/Projects/Kontrast/MavenWorkspace/xe-debug-web/target/xe-
debug-web-1.6.1]
[INFO] Copy webapp webResources[/Users/simon/Projects/Kontrast/
MavenWorkspace/xe-debug-web/target/maven-shared-archive-resources/META-
INF] to[/Users/simon/Projects/Kontrast/MavenWorkspace/xe-debug-web/
target/xe-debug-web-1.6.1]
[INFO] Copy webapp webResources[/Users/simon/Projects/Kontrast/
MavenWorkspace/xe-debug-web/src/main/webInfResources] to[/Users/simon/
Projects/Kontrast/MavenWorkspace/xe-debug-web/target/xe-debug-web-1.6.1]
Exception in thread "main" java.lang.IllegalStateException: basedir /
Users/simon/Projects/Kontrast/MavenWorkspace/xe-debug-web/src/main/
webInfResources does not exist
at
org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:
550)
...
Since both approaches failed, I need some advice on how to package the
xe-debug-web into
a proper WAR file again.
All pointers much appreciated,
J.L.Simon
Hi,
Please unsubscribe my Email ID from this blog.I dnt want further mails.
regards,
Deepak Sharma
ASE
Tata Consultancy Services
,Phase IV,
Gurgaon
Gurgaon - 122001,Haryana
India
Cell:- 9911502444
Mailto: deepak24.s(a)tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Outsourcing
____________________________________________
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Hi,
I'd like to suggest to postpone the release by a couple of days. The
reason is -- as explained in a previous email -- that in its current
state the WYSIWYG 2.0 :
1) Is still causing IE6 crashes on key press (Blocker). It has been
preventing testing on this browser during the last couple of weeks and
last commit from Marius doesn't help (again, IE is a pain). See
http://jira.xwiki.org/jira/browse/XWIKI-2915
2) Can't be considered as a valid replacement of the WYSIWYG 1.0
since the image and table plugins are deactivated by default
(XWIKI-2917 and XWIKI-2916). See pending issues here :
http://tinyurl.com/6hsaqg
If it's ok for everyone I'd like to define december 5th as the new
release date for XE 1.7 ?
Here's my +1.
Thanks,
JV.