Hi!
I have a big problem with my blog-function in my Wiki. I've delete all
example posts over the wiki function and the blank categories over my
SQL. My problem now is, that I cannot make new posts in the standard
categories. If I click on "Create Blog Post", I can set the posttitle
Name. That is normal... But then I click on "Create": I get the error
message "This is not an article".
What should I do? I really need the blog. I hope you can help me...
Thanks for your help!
Torben
Hi,
Now that we're starting to have several products (XE, XEM, Watch,
Curriki, etc) we need to agree on a strategy for their dependencies
on the Platform Core.
Need
=====
Here's a real use case on which we can base our discussion:
* XEM needs to be released ASAP. More specifically there's a need to
release 1.0M1 on 17th of Sept. and 1.0M2 on 1st of October.
* Platform Core 1.2 in trunk is not stable yet and will only be
released at end of November (if we agree on the schedule I sent this
morning)
* XEM needs to use a stable Core
* XEM needs some features in core that are not in Core 1.1 (For
example: the new Right Management UI which needs to change templates
and possibly some code too)
To summarize, Products may require a stable version of the core but
with modifications.
How do we solve this?
Solutions
========
Short term solution:
* We put whatever is required in point releases. For example, for
XEM, we put the Rights Management changes in 1.1.x
* We decide on the 1.1.x release dates based on the aggregated needs
of the different Products
* Once the Core trunk is released then the Products are modified to
depend on it.
* Of course each Product should try its maximum to internalize
required changes inside its own code rather while waiting for the
Core the released. To do this, JIRA issues with patches should be
submitted to the Core to be applied.
The other short term solution is to have a specific branch of Core
for each product but I feel this is going to be a nightmare to
maintain and merge so I'd much rather have a single 1.1.x branch
which we can release as fast as we want.
Medium/Long term solution:
* Make the Core more and more modular with components so that a
Product can keep all the core except for a specific component for
which it can have its own implementation for some time till that
makes it inside the core.
* Reduce Core release lifecycles. Right now it's 3 months. We could
probably reduce that to 1.5 month right now.
* In order to reduce that even further, have more automated
functional tests in the Core so that we can release a stable release
of the core every 2-3 weeks. Once we reach that stage, I think there
won't be any need to have branches for products. However this
requires a change of mind for XWiki core developers since developers
would need to write tests as they commit code instead of committing
stuff and then fixing them later on, in further betas or RCs. This is
our Graal.
Conclusion
=========
Are we all ok to agree that the 1.1.x releases will thus contain
changes/improvements (i.e. each change must be reviewed carefully so
that it's not risky and does not endanger the stability of the branch)?
Thanks
-Vincent
The XWiki development team team is pleased to announce the
availability of the 1.1 RC 2 release of XWiki Enterprise
Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download
This is a bug fix release and is meant to be the last RC. If no major
bugs are found for 2-3 days it'll be promoted as the 1.1 final release.
Please help us in testing it.
Release notes: http://www.xwiki.org/xwiki/bin/view/Main/
ReleaseNotesXWikiEnterprise11RC2
Enjoy
-The XWiki development team
Hi all,
I've just joined the XWiki dev community today and this is my first post.
As Vincent told you, from now on I'll be working on the new GWT-based
WYSIWYG editor. I'll do my best, but I need your help on this. In the next
few days I'll be reading the documentation for the new architecture,
including WikiModel and GWT. After that, I'll post my ideas so you can
make comments.
Thanks everyone,
-Marius
(resending - I sent it on the 6th to the wrong OW dev list...)
> If we don't increase version then how is it going to appear in the
> history view. Namely, how would you see that a comment has been added?
>
> Of course we would still need to send notifications even when
> comments are added.
>
> This is a general question about objects attached to a document. As
> of now I'm not sure we should treat some objects differently than
> others.
>
> Just to step back and play the devil, why is it bad that document
> version is increased when comments are added?
>
> Thanks
> -Vincent
>
> On Aug 24, 2007, at 4:44 PM, Sergiu Dumitriu wrote:
>
>> Hi,
>>
>> This is more a matter of opinions. Should a comment increase the
>> version of a document? I'd say yes, but the view of simple users is
>> that a comment should not affect the document, as it is something
>> describing the document, not belonging to the document. So we should
>> have a parameter that configures this.
>>
>> WDYT?
>> Sergiu
>> --
>> http://purl.org/net/sergiu
Hi,
I've created a 1.1.1 version in JIRA. The idea is to have only
important bug fixes in that release and to release it before we
release 1.2M1.
The main reason why we need that 1.1.1 instead of going straight to
1.2M1 is because we have introduced important core changes in 1.2M1
and we probably need a bit of time to stabilize it and ensure it
works seamlessly.
Ludovic, I've moved the issue you had created for 1.1 to 1.1.1 since
1.1 is just a marker and right now the 1.1RC2 release is meant to be
promoted as the final 1.1. If we make a change we'll then need a
1.1RC3 which I'd rather not have at this stage.
Last I've proposed a date of 24th of September for the 1.1.1 release
(in 2 weeks time).
Let me know if this is ok for everyone.
Thanks
-Vincent
Hi everyone,
I've released XWiki Enterprise 1.1RC2 on our Maven remote repository
and I need some help in testing it before we officially release it on
OjwectWeb's Forge and announce it on xwiki.org.
It would be nice if I could get at least 2-3 tester saying that the
distribution is ok.
Here are the files to test:
* Platform WAR: http://maven.xwiki.org/releases/com/xpn/xwiki/
platform/xwiki-web-standard/1.1-rc-2/xwiki-web-standard-1.1-rc-2-
hsqldb.war
* Standalone zip: http://maven.xwiki.org/releases/com/xpn/xwiki/
products/xwiki-enterprise/1.1-rc-2/xwiki-enterprise-1.1-rc-2-hsqldb.zip
* XE XAR: http://maven.xwiki.org/releases/com/xpn/xwiki/products/
xwiki-enterprise-wiki/1.1-rc-2/xwiki-enterprise-wiki-1.1-rc-2.xar
* Generic installer for XE: http://maven.xwiki.org/releases/com/xpn/
xwiki/products/xwiki-enterprise-installer-generic/1.1-rc-2/xwiki-
enterprise-installer-generic-1.1-rc-2.jar
* Windows installer for XE: http://maven.xwiki.org/releases/com/xpn/
xwiki/products/xwiki-enterprise-installer-windows/1.1-rc-2/xwiki-
enterprise-installer-windows-1.1-rc-2.exe
Thanks a lot for your help!
-Vincent
This may be silly, but would it be clearer if the XEclipse versioning
contained some indication of the XWiki base required? To me, XEclipse
v1.0 somehow suggests to me that it should be able to run on XWiki
1.0... which of course is not true. Might be good to have the prereq
explicit in the versioning.. maybe?
--
'Waste of a good apple' -Samwise Gamgee
Hi Vincent,
On 9/8/07, Vincent Massol <vincent(a)massol.net> wrote:
[snip]
>
> I think the model classes should reflect more XWiki's concepts since
> it's meant to abstract the implementation (swizzle).
>
> For example the following don't look right to me: Blog*, Comment,
> Label, Rss*. In XWiki they are all Objects. So I'd rather see an
> Object class in the interface and possibly some verification on the
> object type in the swizzle implementation to map them to swizzle
> concepts.
>
I think that what you suggest here is not even possible to implement
on top of the Confluence API. I suggest you have a look at the code.
Catalin
> This is very important and we need to agree on that before we can
> release 1.2M1 since when we release it then this api is in the wild
> and it'll be harder to change it.
>
> What do others think?
>
> Thanks
> -Vincent
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>