To test... and fix hacks we had to introduce to see if they can now be
removed.
-Vincent
Begin forwarded message:
> From: John Casey <jdcasey(a)apache.org>
> Date: January 5, 2009 9:25:04 PM CEST
> To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org
> >
> Subject: [ANN] Maven Assembly Plugin 2.2-beta-3 Released
> Reply-To: "Maven Users List" <users(a)maven.apache.org>
>
> The Maven team is pleased to announce the release of the Maven
> Assembly Plugin, version 2.2-beta-3
>
> This plugin is used to create custom archives using the build
> output, dependencies, and other files owned by a Maven project. You
> can find more information, including instructions and examples, at:
>
> http://maven.apache.org/plugins/maven-assembly-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-assembly-plugin</artifactId>
> <version>2.2-beta-3</version>
> </plugin>
>
>
> Release Notes - Maven 2.x Assembly Plugin - Version 2.2-beta-3
>
> ** Sub-task
> * [MASSEMBLY-361] - Fix MASSEMBLY-285 default behaviour to be the
> correct behaviour
>
> ** Bug
> * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file
> mode nor uid/gid
> * [MASSEMBLY-165] - Test error on Windows XP + Cygwin
> * [MASSEMBLY-190] - Problem with dependency conflict resolution
> on multi-module project
> * [MASSEMBLY-196] - use of repository assembly is no longer working
> * [MASSEMBLY-201] - classifier not included in name of dependency
> set
> * [MASSEMBLY-211] - assembly plugin and jar plugin disagree about
> whether to use uniqueVersion snapshot names
> * [MASSEMBLY-213] - jar-with-dependencies and signed jars issue
> again
> * [MASSEMBLY-217] - <outputFileNameMapping> needs to report
> collision.
> * [MASSEMBLY-230] - <fileset> not filtering resources, but
> <files> does filter
> * [MASSEMBLY-236] - assembly:assembly resolves excluded artifacts
> * [MASSEMBLY-237] - lineEnding ignored in a child project
> * [MASSEMBLY-238] - Assembly plugin removes file permissions
> * [MASSEMBLY-241] - Multiple includes in dependencySet
> * [MASSEMBLY-242] - transitive dependencies do not get included
> * [MASSEMBLY-245] - Manifest Section configuration does not work
> properly
> * [MASSEMBLY-251] - NullPointer wehn using scope system in a
> dependencySet
> * [MASSEMBLY-256] - Regression: pom properties are no longer
> expanded in descriptor.
> * [MASSEMBLY-264] - Filtering in Assembly Generates Blank Files
> in the Archive
> * [MASSEMBLY-270] - Assembly does not resolved managed
> dependencies correctly
> * [MASSEMBLY-280] - Regression: Dependency resolution for
> dependencySets does broken things
> * [MASSEMBLY-284] - regression: line ending setting is not honoured
> * [MASSEMBLY-285] - regression: duplicate files added to the
> assembly
> * [MASSEMBLY-287] - Unable to pass -DskipAssembly=true through
> the command line to skip the assembly plugin.
> * [MASSEMBLY-291] - attach the resulting assembly not working as
> expected
> * [MASSEMBLY-293] - <fileSets> not filtered in multimodule build,
> but <files> are
> * [MASSEMBLY-294] - Regression - dependency is skipped?
> * [MASSEMBLY-297] - Assembly broke on GNU/Linux -
> NullPointerException
> * [MASSEMBLY-298] - Includes/Excludes within <unpackOptions> are
> ignored
> * [MASSEMBLY-300] - Regression: outputFileNameMapping variable
> resolution
> * [MASSEMBLY-301] - assembly:attach wrongly renames/overwrites
> assemblies to the primary artifact
> * [MASSEMBLY-302] - Maven assembly plugin should use plexus-
> archiver version
> * [MASSEMBLY-306] - Dependency resolution fails with an NPE for a
> provided dependency with a fixed version
> * [MASSEMBLY-308] - Syntax Problem in Example Doco
> * [MASSEMBLY-309] - outputFileNameMapping fails and includes
> parent's name
> * [MASSEMBLY-312] - outputFileNameMapping not respected when the
> unpack=true
> * [MASSEMBLY-314] - Multiple inclusion of dependencies in binary
> assembly
> * [MASSEMBLY-318] - Example to attach assembly to package incorrect
> * [MASSEMBLY-319] - Cannot bind to lifecycle with multiple modules
> * [MASSEMBLY-322] - Filtering in filesets in multimodule build
> does not work
> * [MASSEMBLY-328] - When assembly is attached to pom with
> appendAssemblyId disabled, it won't be installed or deployed
> * [MASSEMBLY-331] - assembly descriptor doesn't seem to property
> substitute properties
> * [MASSEMBLY-340] - Filtering doesn't work for multimodule
> assembly builds
> * [MASSEMBLY-341] - Fat JAR assemblies may result in JARs with
> duplicate files
> * [MASSEMBLY-342] - NPE when filtering fileSet
> * [MASSEMBLY-345] - a"ppxml attribute is required" error when
> making ears with the assembly plugin
> * [MASSEMBLY-351] - ${project.xxxx} is not interpolated in the
> descriptor
> * [MASSEMBLY-354] - useTransitiveFiltering does NOT include
> artifacts whose dependency trail matches one of the include patterns
> when it has wildcards
> * [MASSEMBLY-355] - I get duplicate files in my "-jar-with-
> dependencies.jar"
> * [MASSEMBLY-375] - Leading slash in Windows when including one
> file in archive.
>
> ** Improvement
> * [MASSEMBLY-76] - [assembly plugin] improve or clarify
> inheriting/reusing descriptors
> * [MASSEMBLY-159] - Add FAQ about building multi-module
> assemblies from the top using Maven 2.0
> * [MASSEMBLY-216] - archive element in assembly descriptor
> * [MASSEMBLY-239] - In format dir, be able to create a dir
> without the suffix .dir
> * [MASSEMBLY-366] - DependencySet info message should be changed
> to debug level
>
>
>
> Enjoy,
>
> -The Maven team
Would be better next time to have a jira issue associated with commits
like this one, especially since you're changing something visible to
the user. Didn't you open a jira issue already when you made those
changes to DefaultDocumentAccessBridge earlier on?
BTW shouldn't this be i18ned? Are we doing that for other save messages?
Thanks
-Vincent
On Jan 7, 2009, at 7:28 AM, asiri (SVN) wrote:
> Author: asiri
> Date: 2009-01-07 07:28:11 +0100 (Wed, 07 Jan 2009)
> New Revision: 15118
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java
> Log:
> Addressing review comments.
>
> * Improced javadoc comemnts.
> * Added an editComments when changing document syntaxId
> * Prevented re-saving the XWikiDocument after calling
> doc.saveAttachmentContent()
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/DefaultDocumentAccessBridge.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-06 23:15:02 UTC (rev 15117)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> DefaultDocumentAccessBridge.java 2009-01-07 06:28:11 UTC (rev 15118)
> @@ -116,8 +116,10 @@
> {
> XWikiContext xcontext = getContext();
> XWikiDocument doc =
> xcontext.getWiki().getDocument(documentName, xcontext);
> + String oldSyntaxId = doc.getSyntaxId();
> doc.setSyntaxId(syntaxId);
> - xcontext.getWiki().saveDocument(doc, xcontext);
> + xcontext.getWiki().saveDocument(doc,
> + String.format("Changed document syntax from [%s] to
> [%s].", oldSyntaxId, syntaxId), xcontext);
> }
>
> /**
> @@ -241,8 +243,6 @@
> attachment.setAuthor(xcontext.getUser());
> attachment.setDoc(doc);
> doc.saveAttachmentContent(attachment, xcontext);
> - xcontext.getWiki().saveDocument(doc,
> - String.format("Added attachment [%s].",
> AttachmentName), xcontext);
> }
>
> /**
> @@ -326,6 +326,8 @@
> }
>
> /**
> + * Utility method for checking access rights of the current
> user on a target document.
> + *
> * @param documentName The name of the document.
> * @param right Access right requested.
> * @return True if the current user has the given access right,
> false otherwise.
Hi there,
I've just noticed that we have the following in distribution-test/
pom.xml:
<!-- Used only in xml-rpc tests -->
<property>
<name>pathToXWikiXar</name>
<value>com/xpn/xwiki/products/xwiki-enterprise-wiki/$
{pom.version}/xwiki-enterprise-wiki-${pom.version}.xar</value>
</property>
I don't think this is in the right place. It should be in the the
XMLRPC test's pom.xml file.
Fabio could you look into this?
Thanks
-Vincent
On Jan 6, 2009, at 5:05 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2009-01-06 17:05:57 +0100 (Tue, 06 Jan 2009)
> New Revision: 15098
>
> Modified:
> platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/xpn/
> xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> Log:
> XWIKI-3068 : Builtin firefox table features (add row, add col)
> messes up tables in the WYSIWYG
>
> Fixed by disabling builtin firefox table features. Merged from trunk.
>
>
>
> Modified: platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/
> com/xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java
> ===================================================================
> --- platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:02:23 UTC (rev 15097)
> +++ platform/web/branches/xwiki-web-1.7/wysiwyg/src/main/java/com/
> xpn/xwiki/wysiwyg/client/plugin/table/TablePlugin.java 2009-01-06
> 16:05:57 UTC (rev 15098)
> @@ -85,6 +85,10 @@
> addFeature(rta, new InsertColAfter(this));
> addFeature(rta, new DeleteCol(this));
> addFeature(rta, new DeleteTable(this));
> +
> + // Disable the standard table editing features of Firefox.
> + // See XWIKI-3068 for more info.
I don't think we should put JIRA references in our code and not for
describing a solution. Rationale: we can move to another issue tracker
in the future, the issue can be moved/deleted/replace, etc.
It's better to have all the information in the source file IMO.
>
> + rta.getDocument().execCommand("enableInlineTableEditing",
> "false");
>
> getUIExtensionList().add(toolBarExtension);
> }
Thanks
-Vincent
http://xwiki.comhttp://massol.nethttp://xwiki.org
Hi Fabio
On Jan 6, 2009, at 1:46 AM, fmancinelli (SVN) wrote:
> Author: fmancinelli
> Date: 2009-01-06 01:46:26 +0100 (Tue, 06 Jan 2009)
> New Revision: 15087
>
> Added:
> sandbox/xwiki-core-rest/src/main/java/components/
> sandbox/xwiki-core-rest/src/main/java/components/org/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> SpacesResource.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResource.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResourceFinder.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiResourceRepresenter.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiRestApplication.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> XWikiRestletServlet.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/PlainTextSpacesRepresenter.java
> sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/
> internal/XmlTextSpacesRepresenter.java
> Modified:
> sandbox/xwiki-core-rest/src/main/resources/META-INF/plexus/
> components.xml
> Log:
> Added a fully componentized version of the REST infrastructure.
>
> Now resources and "representers" (i.e., objects that are in charge
> for representing a given resource for a given media type) are
> declared through components.xml and automatically registered:
>
> 1) At the application level routes are created for all the
> components declaring the org.xwiki.rest.XWikiResource role. The role
> hint defines the uri template.
>
> 2) Representers components are associated to resource components by
> looking at the role hint (which should reflect the resource a given
> representer is associated to)
[snip]
> + restApplication = (XWikiRestApplication)
> componentManager.lookup(applicationClass);
> +
> +
> restApplication.setName(getServletConfig().getServletName());
> + restApplication.setContext(new
> ServletContextAdapter(this, context));
> +
> restApplication
> .getContext().setLogger(restApplication.getClass().getName());
Looks good in general.
Just making sure: is createApplication() and hence the code above
executed only once?
All components you've created are singletons so you need to be careful
that they don't hold state or if they do (as above) then this needs to
be a state that is common for all threads and thus only initialized
once for the entire app lifetime.
[snip]
Thanks
-Vincent
Howdy,
I've checked out the source code HEAD revision from:
http://svn.xwiki.org/svnroot/xwiki/platform/trunks
I've installed Maven, setup my .../.m2/settings.xml, and am running "mvn
-Pwindows install".
The build seems to proceed part way, then one of the tests fails:
Running com.xpn.xwiki.tool.xar.XarMojoTest
[info] Using the existing package.xml descriptor at
[C:\temp\xwiki\tools\xwiki-x
ar-plugin\target\test-classes\malformedXml\src\main\resources\package.xml]
[error] The existing package.xml is invalid.
java.lang.Exception: The supplied document contains no document list
at
com.xpn.xwiki.tool.xar.XarMojo.getDocumentNamesFromXML(XarMojo.java:2
72)
at
com.xpn.xwiki.tool.xar.XarMojo.addFilesToArchive(XarMojo.java:321)
at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:124)
at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:76)
Any ideas?
--
View this message in context: http://n2.nabble.com/Build-error-of-fresh-checkout-on-Windows-Vista-tp21117…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
I've made a mockup for the macro dialog in the WYSIWYG editor :
http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog…
I've assumed that using a tree to browse macros was :
- Scalable.
- Consistent with link dialogs.
Shout if you think about another way of displaying them.
Note that the second dialog is generated dynamically and will vary a
lot according to macros needs (see 2 bis), its layout must remain as
simple as possible.
Here's my +1.
JV.