Re: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib

[Vincent Massol]

> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar 
>  wrote:
> 
> +1
> 
> I spend some time about nitpicking the "the recommended development practices 
> to follow are those found on dev.xwiki.org", because it is not exactly 
> obvious which parts on dev.xwiki.org are development practices and this apply 
> and which ones are not
> (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not 
> apply, but e.g.Code style probably does, and then some parts of 
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply, and 
> some not - e.g "Release Manager" is explicitly about XWiki core, but the 
> general infra structure and coding advice applies …

Actually the goal is to make it all apply in the future by rephrasing the 
places that currently only make sense for the xwiki github org. Note that 
http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a project 
on xwiki-contrib also has some web pages on xwiki.org) :) 

> ... but then I decided to forget about it because a bit of common sense 
> allows this to sort out by itself; the important thing is be nice, and a bit 
> lore lenient and relaxed no new contributors, so they feel welcome :)

Yup :)

Thanks
-Vincent

> Clemens
> 
> - Ursprüngliche Nachricht -
> Von: Vincent Massol
> Am:  Tuesday, 15.03.2016, 13:12
> An: Xwiki Developers
> Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
> 
> 
>> Hi all,
>> 
>> This mail is about trying to improve how we work in xwiki-contrib and it 
>> supersedes the proposal I sent at 
>> http://markmail.org/message/qzc7ipiu6lazwbwr
>> 
>> Issues with current way of working in xwiki-contrib:
>> 
>> * Each project has a lead but this lead is MIA for a lot of extensions and 
>> it's a pain to maintain (I'm trying to do it but it's a pain)
>> * It doesn't make much sense to have a lead for an extension but then 
>> allowing anyone to commit on it without the lead's approval, nor allowing 
>> anyone to release new versions of that project without the lead 
>> participating to the discussion.
>> * Right now a committer can release a project using maven but doesn't have 
>> permissions to release it in jira nor creating a new version, causing 
>> synchronization issues
>> * The XWiki core committers are going to move a lot of non-core extensions 
>> to xwiki-contrib but there's no clear lead for a lot of those extensions 
>> since they were developed collaboratively and there's no notion of lead in 
>> the xwiki github organization. In practice the person from the XWiki core 
>> devs to work on a given extension varies over time (that’s how those 
>> extensions were built). It's not possible (and not a good idea) to give a 
>> long-time leadership to a single person.
>> 
>> Proposal:
>> =
>> 
>> * XWiki Contrib is a community where extensions for XWiki can be developed 
>> and maintained together. It's a place that is of interest for people who 
>> want to share their sources and work collaboratively with others on them. If 
>> the intent is only to make an extension available to users of XWiki then 
>> it's enough to publish the binaries on extensions.xwiki.org (and put the 
>> souces anywhere they wish, including on the e.x.o page or on their github 
>> account if they have one).
>> 
>> * XWiki Contrib is defined by the xwiki-contrib github organization
>> 
>> * Anyone can request to join this community. This is the main difference 
>> with the xwiki github organization where you need to be voted in to become a 
>> committer. The main rationale is that making a mistake in the core has more 
>> impact than doing this in an extension. The second rationale is that this is 
>> an experiment to see if we can have a more vibrant community as a result of 
>> being more open, without loosing too much quality. 
>> 
>> * Once someone joins, he/she has commit access to all repositories in 
>> xwiki-contrib (and he/she's also added to a group on jira allowing him to 
>> create versions and releasing them.). The goal is to favor 
>> cross-pollination. In case this causes problem in the future, we can 
>> collaboratively decide to have stricter rules but it's a good 
>> experiment/principle to start as open as possible and close only if need be 
>> (the wiki principle ;)). So far, after several years of operations, there 
>> have been no incident in this way of working for xwiki-contrib that would 
>> have required restricting permissions.
>> 
>> * In order to simplify participating to any project in xwiki-contrib, the 
>> recommended development practices to follow are those found on 
>> dev.xwiki.org, i.e. the same as for the xwiki github organization. This 
>> prevents the issue that someone who wants to participate to more than 1 
>> project needs to learn several dev practices; they're all the same. Now, 
>> these practices are best practices and the intent is that committers try to 
>> follow them as much as they can, in 

Re: [xwiki-devs] about redevelopment "version control"

[Jack]

Hi vmassol,
Thanks for getting back to so quickly . 
I have another question:
I have a crm system(Object Relational Mapping also is hibernate),I plan to
import the xwiki-platform-oldcore.jar to my system.Then redevelopment 
"version control".Is this really possible? I need another module?



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/about-redevelopment-version-control-tp7598558p7598579.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib

[Clemens Klein-Robbenhaar]

+1

 I spend some time about nitpicking the "the recommended development practices 
to follow are those found on dev.xwiki.org", because it is not exactly obvious 
which parts on dev.xwiki.org are development practices and this apply and which 
ones are not
(e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not apply, 
but e.g.Code style probably does, and then some parts of 
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply, and 
some not - e.g "Release Manager" is explicitly about XWiki core, but the 
general infra structure and coding advice applies ...

 ... but then I decided to forget about it because a bit of common sense allows 
this to sort out by itself; the important thing is be nice, and a bit lore 
lenient and relaxed no new contributors, so they feel welcome :)

Clemens

- Ursprüngliche Nachricht -
Von: Vincent Massol
Am:  Tuesday, 15.03.2016, 13:12
An: Xwiki Developers
Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib


> Hi all,
> 
> This mail is about trying to improve how we work in xwiki-contrib and it 
> supersedes the proposal I sent at http://markmail.org/message/qzc7ipiu6lazwbwr
> 
> Issues with current way of working in xwiki-contrib:
> 
> * Each project has a lead but this lead is MIA for a lot of extensions and 
> it's a pain to maintain (I'm trying to do it but it's a pain)
> * It doesn't make much sense to have a lead for an extension but then 
> allowing anyone to commit on it without the lead's approval, nor allowing 
> anyone to release new versions of that project without the lead participating 
> to the discussion.
> * Right now a committer can release a project using maven but doesn't have 
> permissions to release it in jira nor creating a new version, causing 
> synchronization issues
> * The XWiki core committers are going to move a lot of non-core extensions to 
> xwiki-contrib but there's no clear lead for a lot of those extensions since 
> they were developed collaboratively and there's no notion of lead in the 
> xwiki github organization. In practice the person from the XWiki core devs to 
> work on a given extension varies over time (that’s how those extensions were 
> built). It's not possible (and not a good idea) to give a long-time 
> leadership to a single person.
> 
> Proposal:
> =
> 
> * XWiki Contrib is a community where extensions for XWiki can be developed 
> and maintained together. It's a place that is of interest for people who want 
> to share their sources and work collaboratively with others on them. If the 
> intent is only to make an extension available to users of XWiki then it's 
> enough to publish the binaries on extensions.xwiki.org (and put the souces 
> anywhere they wish, including on the e.x.o page or on their github account if 
> they have one).
> 
> * XWiki Contrib is defined by the xwiki-contrib github organization
> 
> * Anyone can request to join this community. This is the main difference with 
> the xwiki github organization where you need to be voted in to become a 
> committer. The main rationale is that making a mistake in the core has more 
> impact than doing this in an extension. The second rationale is that this is 
> an experiment to see if we can have a more vibrant community as a result of 
> being more open, without loosing too much quality. 
> 
> * Once someone joins, he/she has commit access to all repositories in 
> xwiki-contrib (and he/she's also added to a group on jira allowing him to 
> create versions and releasing them.). The goal is to favor cross-pollination. 
> In case this causes problem in the future, we can collaboratively decide to 
> have stricter rules but it's a good experiment/principle to start as open as 
> possible and close only if need be (the wiki principle ;)). So far, after 
> several years of operations, there have been no incident in this way of 
> working for xwiki-contrib that would have required restricting permissions.
> 
> * In order to simplify participating to any project in xwiki-contrib, the 
> recommended development practices to follow are those found on dev.xwiki.org, 
> i.e. the same as for the xwiki github organization. This prevents the issue 
> that someone who wants to participate to more than 1 project needs to learn 
> several dev practices; they're all the same. Now, these practices are best 
> practices and the intent is that committers try to follow them as much as 
> they can, in their capacity. Other committers reviewing code should be 
> lenient in their comments and sentences like "You must do xxx" should be 
> avoided and instead sentences like "When you have the time, it would be nice 
> if you could...". OTOH, when a committer joins xwiki-contrib, he/she should 
> understand that these best practices exist (and possibly spend some time 
> reading them), and agree about following them as much as he/she can. 
> Obviously anyone is free to discuss an existing rule and propose changing 

Re: [xwiki-devs] How to run custom code on xwiki start in java code?

[Thomas Mortagne]

On Fri, Mar 18, 2016 at 4:14 PM, abtv  wrote:
> 1. I'm implementing custom xwiki plugin installations without user
> interaction in java (I planned to do it with REST API, but after testing I
> have found it's not so convenient as java code). I use the following:
>
> ExtensionManagerScriptService manager =
> (ExtensionManagerScriptService)Utils.getComponent(ScriptService.class,
> "extension");
> InstalledExtensionScriptService installed =
> (InstalledExtensionScriptService)Utils.getComponent(ScriptService.class,
> "extension.installed");
>
> The problem is that I do it in my custom auth module when user logins into
> system. I do this check only once but it smells for 2 reasons:

> Utils.getComponent method is deprecated

Yes Utils.getComponent is indeed deprecated and should only be used in
places where you really don't ave any choice which is old style non
component based stuff... like authenticators unfortunately. Now since
your code is about initializing stuff only once it would probably be
better to move that in a listener called at startup. See below.

> and I think there is an entry point
> which I can override to run my code on xwiki start. Could you propose any
> solution for this? I have also concern about xwiki start: I use Jetty and
> every time I start xwiki I see a message "xwiki is loading..." and percent
> counter.

> It seems that xwiki loads only for the first request. Is it true?

Yes and no. You do have a lots of stuff initialized during application
startup (extensions, listeners, etc.) but you also have important
things for XWiki initialized only during the first request which are
mostly the database and stuff that need to access the database.

If you don't need the database (or you don't need something that needs
the database) you should listen to
org.xwiki.observation.event.ApplicationStartedEvent event (from module
xwiki-commons-observation-api). If you need the database, you can
listen to org.xwiki.bridge.event.ApplicationReadyEvent event (from
module xwiki-platform-bridge)

See 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Observation+Module+Local
for more about listeners.

> Can I change the behaviour?
>
>
>
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/How-to-run-custom-code-on-xwiki-start-in-java-code-tp7598537.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Moving FAQ app to contrib

[Vincent Massol]

Hi devs,

I’ve moved the IRC Bot app last week as a proof of concept and even though it 
was tedious and long, it worked fine.

FYI, I’m now going to perform the move of the FAQ app to contrib, as agreed.

Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to setup 'Prevent unregistered users from viewing pages' in config or programmatically?

[Sergiu Dumitriu]

Oh, and the value must be 1 to enable.

On 03/21/2016 08:29 AM, Sergiu Dumitriu wrote:
> That's an object property, so you can use a normal page REST call to set it.
> 
> page: XWiki.XWikiPreferences
> object: XWiki.XWikiPreferences[0]
> property: authenticate_view / authenticate_edit
> 
> On 03/21/2016 08:07 AM, abtv wrote:
>> I would like to deny seen pages for unregistered users. I can do it via the
>> following:
>>
>> Choose `Administration` -> `Users & Groups` -> `Rights` then select 
>> `Prevent unregistered users from viewing pages, regardless of the page or
>> space rights` and 
>> `Prevent unregistered users from editing pages, regardless of the page or
>> space rights`.
>>
>> But I would like to automate it while deploying xwiki. It means no user
>> interactions with UI. Is there any way to do it? Maybe, config file or via
>> java extension?
>>
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [GSoC] Reminder: Submit student applications early. New projects available.

[Eduard Moraru]

Hello to interested GSoC students,

I would like to remind you to submit your applications early and not wait
for the deadline. Submitting early allows you to receive feedback on your
proposals and gives you time to improve them before the deadline arrives.

It would be a good idea to use this review process at your advantage!

Also, in case you`ve missed it, 3 new project proposals were added last
week that you might also be interested in:

* RedPen Integration
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/RedPenIntegration
* Presentation Application Overhaul
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/PresentationApplicationOverhaul
* Chart.js Integration
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ChartjsIntegration

We now have a total of 16 projects to choose from and 8 available mentors.

Good luck in drafting your proposals, don`t remember about the Pull Request
and don`t hesitate to ask questions!

Thanks,
Eduard
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] How to setup 'Prevent unregistered users from viewing pages' in config or programmatically?

[abtv]

I would like to deny seen pages for unregistered users. I can do it via the
following:

Choose `Administration` -> `Users & Groups` -> `Rights` then select 
`Prevent unregistered users from viewing pages, regardless of the page or
space rights` and 
`Prevent unregistered users from editing pages, regardless of the page or
space rights`.

But I would like to automate it while deploying xwiki. It means no user
interactions with UI. Is there any way to do it? Maybe, config file or via
java extension?



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/How-to-setup-Prevent-unregistered-users-from-viewing-pages-in-config-or-programmatically-tp7598565.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Contrib] Need an account on Nexus in order to Release xwiki-tooltip-macro

[Zoubir]

Ok, Thanks Thomas



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Contrib-Need-an-account-on-Nexus-in-order-to-Release-xwiki-tooltip-macro-tp7598561p7598564.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Contrib] Need an account on Nexus in order to Release xwiki-tooltip-macro

[Thomas Mortagne]

I just created user zmedjdoub for you (easier to use the same naming
convention than the others), you should have received a mail.

On Mon, Mar 21, 2016 at 11:49 AM, Zoubir  wrote:
> Hi XWikiers,
>
> I'm working on xwiki-tooltip-macro , and I'd like to release it.
> I need an account on  Nexus :
> username : zoubir
>
> Thanks,
> Zoubir
>
>
>
> --
> View this message in context: 
> http://xwiki.475771.n2.nabble.com/Contrib-Need-an-account-on-Nexus-in-order-to-Release-xwiki-tooltip-macro-tp7598561.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] [Contrib] Need an account on Nexus in order to Release xwiki-tooltip-macro

[Zoubir]

Hi XWikiers,

I'm working on xwiki-tooltip-macro , and I'd like to release it. 
I need an account on  Nexus :
username : zoubir

Thanks,
Zoubir



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Contrib-Need-an-account-on-Nexus-in-order-to-Release-xwiki-tooltip-macro-tp7598561.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] about redevelopment "version control"

[Vincent Massol]

Hi Jack,

> On 21 Mar 2016, at 10:13, Jack  wrote:
> 
> I want to redevelopment  xwiki's feature:"version control" .
> now i have two problem:
> 1、"version control" related project or module in the github

Version control is implemented using JRCS in XWiki. This is located in the 
xwiki-platform-oldcore module.

> 2、I see the document
> "http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI; ,but i
> can not found "version control" all related RESTfulAPI,Are there any other
> documents about this RESTfulAPI?

The REST API is independent of the version control implementation.

Thanks
-Vincent

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] about redevelopment "version control"

[Jack]

I want to redevelopment  xwiki's feature:"version control" .
now i have two problem:
1、"version control" related project or module in the github
2、I see the document
"http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI; ,but i
can not found "version control" all related RESTfulAPI,Are there any other
documents about this RESTfulAPI?



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/about-redevelopment-version-control-tp7598558.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs