On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote:

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

Yes it's a huge change, that's why it's a vote.

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

Thanks -Vincent

On May 16, 2013, at 4:14 PM, Thomas Mortagne <[email protected]> wrote:

...

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.

We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged...

As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size.

So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules.

Here is an example:

xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars)

would become

core/rendering/transformations/macro (36 chars)

So WDYT ?

Here is my +1

I also find it nicer when navigating using cd and tab in a unix shell anyway.

Planning to do it in 5.1 if everyone agree.

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On 05/16/2013 10:54 AM, Vincent Massol wrote:

On May 16, 2013, at 4:47 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

Yes it's a huge change, that's why it's a vote.

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this. It's not a good move to veto the will of the community. Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

-- Sergiu Dumitriu http://purl.org/net/sergiu

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> wrote:

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

Yes it's a huge change, that's why it's a vote.

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one? * that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files? ** others?

** what happens to the JIRA links to commits in the Commits tab? Will they still work? Thanks -Vincent

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

-- Sergiu Dumitriu

Hi, I'm not (yet ;)) a XWiki developper but concerning this issue with windows, I'd like to propose an other way of adressing it. Several developpers in my company work on windows + eclipse and encounter the same issue with bonita engine. They found a solution by closing all projects they don't work on, using the corresponding packages from a maven repository. It seems a bit painful at the beginning but with good practices, it's ok (by the way, working with eclipse with all projects open should not be simple). As far as I remember, when I was working on windows and idea, I never had the issue. Do you know if the issue is only with eclipse or append also when using maven in command line or using an other IDE ? Back to the main idea, instead of doing this huge refactoring which will impact all XWIki developpers, the alternative may be for one guy to try developping on windows with different IDEs and then provide a way of working on each environment. The cost of such work may be a few hours to find a solution and write some guidelines/good practices. The result for new developpers would be more or less as learning new coding rules. WDYT ? 2013/5/16 Vincent Massol <[email protected]>

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> wrote:

...

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <

[email protected]> wrote:

...

...

...

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]>

wrote:

...

...

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

...

2) It's a *huge* change and it should definitely not be done

lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

...

Yes it's a huge change, that's why it's a vote.

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one? * that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files? ** others?

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Thanks -Vincent

...

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

-- Sergiu Dumitriu

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Frédéric Bouquet Twitter/Github : bouquetf http://www.espacedefouille.org/

On 05/16/2013 01:11 PM, Sergiu Dumitriu wrote:

On 05/16/2013 12:36 PM, Frédéric Bouquet wrote:

...

Hi,

I'm not (yet ;)) a XWiki developper but concerning this issue with windows, I'd like to propose an other way of adressing it.

Several developpers in my company work on windows + eclipse and encounter the same issue with bonita engine. They found a solution by closing all projects they don't work on, using the corresponding packages from a maven repository. It seems a bit painful at the beginning but with good practices, it's ok (by the way, working with eclipse with all projects open should not be simple). As far as I remember, when I was working on windows and idea, I never had the issue. Do you know if the issue is only with eclipse or append also when using maven in command line or using an other IDE ?

Back to the main idea, instead of doing this huge refactoring which will impact all XWIki developpers, the alternative may be for one guy to try developping on windows with different IDEs and then provide a way of working on each environment. The cost of such work may be a few hours to find a solution and write some guidelines/good practices. The result for new developpers would be more or less as learning new coding rules.

WDYT ?

The problem isn't IDE-related at all, it's about the filesystem. Windows doesn't allow creating files with a path longer than 255 characters, so it will fail at attempting to fetch the sources from GitHub.

And that's not actually true, the filesystem itself does allow long path names, it's the Windows API that is broken. There are alternative APIs that allow longer path names (32k chars), but it seems that very few developers use those instead of the default ones (not even the official Windows applications seem to use those), so most applications are broken.

This is why using cygwin works, because it correctly uses the modern APIs. And maybe in time other tools will work as well, but we can't say that "your tool is broken, use something else" when the tool works for 99.9% of all the other software packages.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%2...

A good quote from http://www.codinghorror.com/blog/2006/11/filesystem-paths-how-long-is-too-lo... I think 260 characters of path is more than enough rope to hang ourselves with. If you're running into path length limitations, the real problem isn't the operating system, or even the computers. The problem is the deep, dark pit of hierarchies the human beings have dug themselves into. -- Sergiu Dumitriu http://purl.org/net/sergiu

The problem isn't IDE-related at all, it's about the filesystem. Windows doesn't allow creating files with a path longer than 255 characters, so it will fail at attempting to fetch the sources from GitHub.

And that's not actually true, the filesystem itself does allow long path names, it's the Windows API that is broken. There are alternative APIs that allow longer path names (32k chars), but it seems that very few developers use those instead of the default ones (not even the official Windows applications seem to use those), so most applications are broken.

This is why using cygwin works, because it correctly uses the modern APIs. And maybe in time other tools will work as well, but we can't say that "your tool is broken, use something else" when the tool works for 99.9% of all the other software packages.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%2...

Ok, I see the problem. I though the problem was only when compiling the whole project, not only while a user try to checkout. -- Frédéric Bouquet Twitter/Github : bouquetf http://www.espacedefouille.org/

On 05/16/2013 12:16 PM, Vincent Massol wrote:

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> wrote:

...

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

Yes it's a huge change, that's why it's a vote.

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

This is not just about Windows. The committers that vote +1 vote for their own environment, not just to fix a problem for hypothetical contributors. And it's not about improving something for existing contributors, but removing a blocker standing in the way of future contributors. The easier it is for a new potential community member to join, the more of these tentative users will actually stick around. And XWiki isn't overwhelmed by the number of contributors to afford to voluntarily keep out those not motivated enough to actually try to find out why the checkout fails and what needs to be done to actually have a working environment and go through all the painful process of installing cygwin and the the command line tools that work with cygwin.

...

* that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files?

Not really. In some cases we might have to add --find-copies-harder to some commands, but it should work out of the box for most files. Viewing the commits that affect a file on GitHub might not list pre-move commits, but the history will s

...

** others?

* The move will break uncommitted local changes, so all devs should try to commit their local changes, at least in a separate local branch if not on github. But devs shouldn't keep uncommitted changes anyway, right? * Depending on how they're configured, our IDEs might freak out when pulling for the first time, since everything will be moved around. * Existing pull request should still work, but Jira patches will break; they're probably broken already anyway, since we didn't really allow new patches to be put there for a while, and most of the paths have changed since 1-2 years ago. * Does anything on Jenkins depend on paths? I hope not, configurations use module names, and they will continue to point to the right POM. * I guess this still counts as xwiki.org changes, but we should make sure the pages that work with remote files, like the syntax documentation and syntax completion report, will also need to be updated. * Existing links in emails (and other places with answers like stackoverlow) will be broken, but that already happens whenever we move a module, for example to make room for api+ui+test submodules, and this happened a lot recently, so it's not a new problem. * Most annoying: forgetting our own reflex of typing x+tab when changing the path :-)

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Yes, the existing commits will not change.

Thanks -Vincent

...

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

-- Sergiu Dumitriu

-- Sergiu Dumitriu http://purl.org/net/sergiu

Hi, I hit the issue recently to contribute a fix on the packager plugin. I was surprised, as xwiki is java and multi platform oriented, seemed straightforward to be able to c/o and build on Windows ... To me, even if you don't target all dev envs, it's part of the commonly shared good practices to avoid problems, like "no spaces in folders names".

From the rename, I would suspect some possible build issues having folder names different than artifact names.

Br, Jeremie Le 17 mai 2013 00:28, "Denis Gervalle" <[email protected]> a écrit :

On Thu, May 16, 2013 at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 12:16 PM, Vincent Massol wrote:

...

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]>

wrote:

...

...

...

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <

[email protected]> wrote:

...

...

...

> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <

[email protected]> wrote:

...

>> I'm rather -0 ATM and very close to -1 because: >> >> 1) I haven't heard from a windows dev for a long time, I don't think that happens that often > > And it's surely not going to improve... > >> >> 2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall) >> > > Yes it's a huge change, that's why it's a vote. > >> 3) Windows devs have a simple solution which is to use cygwin so it's not a blocker > > It's not as trivial as you seems to think and it also mean that you > simply can't use the standard git tools in the Windows world like the > Github application or Tortoisegit without speaking or any EDI git > integration... so not it really can't be seen as some obvious > solution. And it's not like using Cygwin was some king of standard for > Windows dev. "use cyggwin" is easy to say but the reality is that a > dev will try to clone XWiki repository with the git tool he is used to > and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

This is not just about Windows. The committers that vote +1 vote for their own environment, not just to fix a problem for hypothetical contributors.

And it's not about improving something for existing contributors, but removing a blocker standing in the way of future contributors. The easier it is for a new potential community member to join, the more of these tentative users will actually stick around. And XWiki isn't overwhelmed by the number of contributors to afford to voluntarily keep out those not motivated enough to actually try to find out why the checkout fails and what needs to be done to actually have a working environment and go through all the painful process of installing cygwin and the the command line tools that work with cygwin.

...

...

* that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files?

Not really. In some cases we might have to add --find-copies-harder to some commands, but it should work out of the box for most files.

I usually use my IDE for exploring history, not the command line, so this is not that simple IMO. You say it will work for most files, it is just a guess... we should check that for real.

...

Viewing the commits that affect a file on GitHub might not list pre-move commits, but the history will s

...

...

** others?

* The move will break uncommitted local changes, so all devs should try to commit their local changes, at least in a separate local branch if not on github. But devs shouldn't keep uncommitted changes anyway,

right?

...

Are you thinking about non-commiters ?

* Depending on how they're configured, our IDEs might freak out when

...

pulling for the first time, since everything will be moved around.

* Existing pull request should still work, but Jira patches will break; they're probably broken already anyway, since we didn't really allow new patches to be put there for a while, and most of the paths have changed since 1-2 years ago.

And any patches maintained by potential existing users for their own use.

...

* Does anything on Jenkins depend on paths? I hope not, configurations use module names, and they will continue to point to the right POM.

* I guess this still counts as xwiki.org changes, but we should make sure the pages that work with remote files, like the syntax documentation and syntax completion report, will also need to be

updated.

...

* Existing links in emails (and other places with answers like stackoverlow) will be broken, but that already happens whenever we move a module, for example to make room for api+ui+test submodules, and this happened a lot recently, so it's not a new problem.

* Most annoying: forgetting our own reflex of typing x+tab when changing the path :-)

...

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Yes, the existing commits will not change.

...

Thanks -Vincent

...

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned

roadmap

...

...

...

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that

migration completely and I'm really worried about the toll it'll have on our releases...

...

...

...

Thanks -Vincent

PS: With the same group effort we could release a first version of

the new model for example ;)

...

-- Sergiu Dumitriu

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

FTR Thomas and I have discussed this a bit and one thing Thomas has started checking is the longest path we currently have. One that we have found is: /Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/xwiki-platform-ircbot-test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar That's 375 characters With the new rule that would be: /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar That's still 301 characters. Thomas has done an extensive search and he'll be able to give more details on other long paths. Also note that we have an issue at runtime with too long paths: [2/11/13 1:22:10 PM] Ionut Maxim: ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt … ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: Cannot create xwiki-enterprise-jetty-hsqldb-4.5-rc-1\data\extension\repository\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui\4.5-rc-1\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-4.5-rc-1.xed Total path and file name length must not exceed 260 characters What we could do to solve both problems would be to reduce the path length used by the EM to store metadata. For example: /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/artifact.xar which gives 236 chars. Still pretty close so another solution would be to use some random directory names (since the names are not used by the EM): /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/dfdsf4fszz3lmbf567/artifact.xar which would be around 200 chars. Now what would be interesting would be to give indications to xwiki builders and xwiki users as to what is the max path prefix they're allowed to use for xwiki to build/work. In my example below I'm using "/Users/vmassol/dev/xwiki/git" chars (i.e. 28 chars). Thanks -Vincent On May 16, 2013, at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote:

On 05/16/2013 12:16 PM, Vincent Massol wrote:

...

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> wrote:

...

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote: > I'm rather -0 ATM and very close to -1 because: > > 1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

> > 2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall) >

Yes it's a huge change, that's why it's a vote.

> 3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

This is not just about Windows. The committers that vote +1 vote for their own environment, not just to fix a problem for hypothetical contributors.

And it's not about improving something for existing contributors, but removing a blocker standing in the way of future contributors. The easier it is for a new potential community member to join, the more of these tentative users will actually stick around. And XWiki isn't overwhelmed by the number of contributors to afford to voluntarily keep out those not motivated enough to actually try to find out why the checkout fails and what needs to be done to actually have a working environment and go through all the painful process of installing cygwin and the the command line tools that work with cygwin.

...

...

* that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files?

Not really. In some cases we might have to add --find-copies-harder to some commands, but it should work out of the box for most files.

Viewing the commits that affect a file on GitHub might not list pre-move commits, but the history will s

...

...

** others?

* The move will break uncommitted local changes, so all devs should try to commit their local changes, at least in a separate local branch if not on github. But devs shouldn't keep uncommitted changes anyway, right?

* Depending on how they're configured, our IDEs might freak out when pulling for the first time, since everything will be moved around.

* Existing pull request should still work, but Jira patches will break; they're probably broken already anyway, since we didn't really allow new patches to be put there for a while, and most of the paths have changed since 1-2 years ago.

* Does anything on Jenkins depend on paths? I hope not, configurations use module names, and they will continue to point to the right POM.

* I guess this still counts as xwiki.org changes, but we should make sure the pages that work with remote files, like the syntax documentation and syntax completion report, will also need to be updated.

* Existing links in emails (and other places with answers like stackoverlow) will be broken, but that already happens whenever we move a module, for example to make room for api+ui+test submodules, and this happened a lot recently, so it's not a new problem.

* Most annoying: forgetting our own reflex of typing x+tab when changing the path :-)

...

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Yes, the existing commits will not change.

...

Thanks -Vincent

...

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

Linking the issue in case someone will work on this in the future http://jira.xwiki.org/browse/XWIKI-8275 Thanks, Caty On Wed, May 22, 2013 at 1:55 PM, Thomas Mortagne <[email protected]>wrote:

So here are the winners on platform/XE master:

xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-test/xwiki-platform-administration-test-tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif (270)

xwiki-enterprise-installers/xwiki-enterprise-installer-generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed (296)

which gives after refactoring

core/administration/test/tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif (174)

installers/generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed (252)

On Tue, May 21, 2013 at 11:54 AM, Vincent Massol <[email protected]> wrote:

...

FTR Thomas and I have discussed this a bit and one thing Thomas has started checking is the longest path we currently have.

One that we have found is:

/Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/xwiki-platform-ircbot-test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar

...

Note that this kind of path does not exist, looks like you extracted a XE in your platform project for test purpose. The actual test data is extracted in /Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/wiki and /data/extension/repository is empty.

...

That's 375 characters

With the new rule that would be:

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar

...

That's still 301 characters.

Thomas has done an extensive search and he'll be able to give more

details on other long paths.

...

Also note that we have an issue at runtime with too long paths:

[2/11/13 1:22:10 PM] Ionut Maxim: !

C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt

...

! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt … ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: Cannot create xwiki-enterprise-jetty-hsqldb-4.5-rc-1\data\extension\repository\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui\4.5-rc-1\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-4.5-rc-1.xed Total path and file name length must not exceed 260 characters

What we could do to solve both problems would be to reduce the path length used by the EM to store metadata. For example:

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/artifact.xar

...

which gives 236 chars. Still pretty close so another solution would be

to use some random directory names (since the names are not used by the EM):

...

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/dfdsf4fszz3lmbf567/artifact.xar

...

which would be around 200 chars.

Now what would be interesting would be to give indications to xwiki

builders and xwiki users as to what is the max path prefix they're allowed to use for xwiki to build/work. In my example below I'm using "/Users/vmassol/dev/xwiki/git" chars (i.e. 28 chars).

...

Thanks -Vincent

On May 16, 2013, at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 12:16 PM, Vincent Massol wrote:

...

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]>

wrote:

...

...

...

...

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

...

On 05/16/2013 10:54 AM, Vincent Massol wrote: > > On May 16, 2013, at 4:47 PM, Thomas Mortagne <

[email protected]> wrote:

...

...

> >> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol < [email protected]> wrote: >>> I'm rather -0 ATM and very close to -1 because: >>> >>> 1) I haven't heard from a windows dev for a long time, I don't think that happens that often >> >> And it's surely not going to improve... >> >>> >>> 2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall) >>> >> >> Yes it's a huge change, that's why it's a vote. >> >>> 3) Windows devs have a simple solution which is to use cygwin so it's not a blocker >> >> It's not as trivial as you seems to think and it also mean that you >> simply can't use the standard git tools in the Windows world like the >> Github application or Tortoisegit without speaking or any EDI git >> integration... so not it really can't be seen as some obvious >> solution. And it's not like using Cygwin was some king of standard for >> Windows dev. "use cyggwin" is easy to say but the reality is that a >> dev will try to clone XWiki repository with the git tool he is used to >> and will simply can't, period. > > What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

This is not just about Windows. The committers that vote +1 vote for their own environment, not just to fix a problem for hypothetical contributors.

And it's not about improving something for existing contributors, but removing a blocker standing in the way of future contributors. The easier it is for a new potential community member to join, the more of these tentative users will actually stick around. And XWiki isn't overwhelmed by the number of contributors to afford to voluntarily keep out those not motivated enough to actually try to find out why the checkout fails and what needs to be done to actually have a working environment and go through all the painful process of installing cygwin and the the command line tools that work with cygwin.

...

...

* that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code ** git history, will we loose ability to see history of files?

Not really. In some cases we might have to add --find-copies-harder to some commands, but it should work out of the box for most files.

Viewing the commits that affect a file on GitHub might not list pre-move commits, but the history will s

...

...

** others?

* The move will break uncommitted local changes, so all devs should try to commit their local changes, at least in a separate local branch if not on github. But devs shouldn't keep uncommitted changes anyway, right?

* Depending on how they're configured, our IDEs might freak out when pulling for the first time, since everything will be moved around.

* Existing pull request should still work, but Jira patches will break; they're probably broken already anyway, since we didn't really allow new patches to be put there for a while, and most of the paths have changed since 1-2 years ago.

* Does anything on Jenkins depend on paths? I hope not, configurations use module names, and they will continue to point to the right POM.

* I guess this still counts as xwiki.org changes, but we should make sure the pages that work with remote files, like the syntax documentation and syntax completion report, will also need to be updated.

* Existing links in emails (and other places with answers like stackoverlow) will be broken, but that already happens whenever we move a module, for example to make room for api+ui+test submodules, and this happened a lot recently, so it's not a new problem.

* Most annoying: forgetting our own reflex of typing x+tab when changing the path :-)

...

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Yes, the existing commits will not change.

...

Thanks -Vincent

...

* to list who is ok to participate actively in the move * that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

> We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases... > > Thanks > -Vincent > > PS: With the same group effort we could release a first version of the new model for example ;) >

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

I confirm that you git 1.9 for windows now support long path name. Note that you have to enable it with: git config core.longpaths true for a single repository or git config --global core.longpaths true globally. On Thu, Mar 20, 2014 at 4:25 PM, Thomas Mortagne <[email protected]> wrote:

Note that long path issue on Windows is supposedly fixed in git 1.9.

On Thu, Jun 20, 2013 at 9:42 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

Linking the issue in case someone will work on this in the future http://jira.xwiki.org/browse/XWIKI-8275

Thanks, Caty

On Wed, May 22, 2013 at 1:55 PM, Thomas Mortagne <[email protected]>wrote:

...

So here are the winners on platform/XE master:

xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-test/xwiki-platform-administration-test-tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif (270)

xwiki-enterprise-installers/xwiki-enterprise-installer-generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed (296)

which gives after refactoring

core/administration/test/tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif (174)

installers/generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed (252)

On Tue, May 21, 2013 at 11:54 AM, Vincent Massol <[email protected]> wrote:

...

FTR Thomas and I have discussed this a bit and one thing Thomas has started checking is the longest path we currently have.

One that we have found is:

/Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/xwiki-platform-ircbot-test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar

...

Note that this kind of path does not exist, looks like you extracted a XE in your platform project for test purpose. The actual test data is extracted in /Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/wiki and /data/extension/repository is empty.

...

That's 375 characters

With the new rule that would be:

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar

...

That's still 301 characters.

Thomas has done an extensive search and he'll be able to give more

details on other long paths.

...

Also note that we have an issue at runtime with too long paths:

[2/11/13 1:22:10 PM] Ionut Maxim: !

C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt

...

! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The archive is corrupt ... ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: Cannot create xwiki-enterprise-jetty-hsqldb-4.5-rc-1\data\extension\repository\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui\4.5-rc-1\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-4.5-rc-1.xed Total path and file name length must not exceed 260 characters

What we could do to solve both problems would be to reduce the path length used by the EM to store metadata. For example:

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/artifact.xar

...

which gives 236 chars. Still pretty close so another solution would be

to use some random directory names (since the names are not used by the EM):

...

/Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/dfdsf4fszz3lmbf567/artifact.xar

...

which would be around 200 chars.

Now what would be interesting would be to give indications to xwiki

builders and xwiki users as to what is the max path prefix they're allowed to use for xwiki to build/work. In my example below I'm using "/Users/vmassol/dev/xwiki/git" chars (i.e. 28 chars).

...

Thanks -Vincent

On May 16, 2013, at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 12:16 PM, Vincent Massol wrote:

...

On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]>

wrote:

...

...

...

> > On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

> >> On 05/16/2013 10:54 AM, Vincent Massol wrote: >>> >>> On May 16, 2013, at 4:47 PM, Thomas Mortagne < [email protected]> wrote: >>> >>>> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol < [email protected]> wrote: >>>>> I'm rather -0 ATM and very close to -1 because: >>>>> >>>>> 1) I haven't heard from a windows dev for a long time, I don't think that happens that often >>>> >>>> And it's surely not going to improve... >>>> >>>>> >>>>> 2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall) >>>>> >>>> >>>> Yes it's a huge change, that's why it's a vote. >>>> >>>>> 3) Windows devs have a simple solution which is to use cygwin so it's not a blocker >>>> >>>> It's not as trivial as you seems to think and it also mean that you >>>> simply can't use the standard git tools in the Windows world like the >>>> Github application or Tortoisegit without speaking or any EDI git >>>> integration... so not it really can't be seen as some obvious >>>> solution. And it's not like using Cygwin was some king of standard for >>>> Windows dev. "use cyggwin" is easy to say but the reality is that a >>>> dev will try to clone XWiki repository with the git tool he is used to >>>> and will simply can't, period. >>> >>> What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project... >> >> But this is why we have a democracy and not a dictatorship. If the >> community considers it is worth the effort, and at least some devs are >> willing to work on this, then I think it's their right to do this. > > 1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision. > > 2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work. > > BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care). > >> It's not a good move to veto the will of the community. > > Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style... > > We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful... > >> Anyway, there are other reasons to make the change, not just Windows >> compatibility. It saves about 2 seconds each time a dev wants to go to a >> directory from the command line. Going into one subdirectory means >> having to press "x tab <right prefix of the submodule> tab". The first >> two keys are superfluous since they're the same all the time. The deeper >> the hierarchy, the longer the time it takes to go there. It adds up to >> more than an hour wasted per year per dev, and I don't think it will >> really take a whole month of every dev to do the migration. If everybody >> contributes and we do a systematic effort, it could be done in an hour >> with the right planning. > > So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: > * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

This is not just about Windows. The committers that vote +1 vote for their own environment, not just to fix a problem for hypothetical contributors.

And it's not about improving something for existing contributors, but removing a blocker standing in the way of future contributors. The easier it is for a new potential community member to join, the more of these tentative users will actually stick around. And XWiki isn't overwhelmed by the number of contributors to afford to voluntarily keep out those not motivated enough to actually try to find out why the checkout fails and what needs to be done to actually have a working environment and go through all the painful process of installing cygwin and the the command line tools that work with cygwin.

...

> * that we list what needs to be done precisely. I've identified some so far: > ** the git path changes > ** modify all the xwiki.org pages linking to code > ** git history, will we loose ability to see history of files?

Not really. In some cases we might have to add --find-copies-harder to some commands, but it should work out of the box for most files.

Viewing the commits that affect a file on GitHub might not list pre-move commits, but the history will s

...

> ** others?

* The move will break uncommitted local changes, so all devs should try to commit their local changes, at least in a separate local branch if not on github. But devs shouldn't keep uncommitted changes anyway, right?

* Depending on how they're configured, our IDEs might freak out when pulling for the first time, since everything will be moved around.

* Existing pull request should still work, but Jira patches will break; they're probably broken already anyway, since we didn't really allow new patches to be put there for a while, and most of the paths have changed since 1-2 years ago.

* Does anything on Jenkins depend on paths? I hope not, configurations use module names, and they will continue to point to the right POM.

* I guess this still counts as xwiki.org changes, but we should make sure the pages that work with remote files, like the syntax documentation and syntax completion report, will also need to be updated.

* Existing links in emails (and other places with answers like stackoverlow) will be broken, but that already happens whenever we move a module, for example to make room for api+ui+test submodules, and this happened a lot recently, so it's not a new problem.

* Most annoying: forgetting our own reflex of typing x+tab when changing the path :-)

...

** what happens to the JIRA links to commits in the Commits tab? Will they still work?

Yes, the existing commits will not change.

...

Thanks -Vincent

> * to list who is ok to participate actively in the move > * that we agree on a date so that it doesn't impact our planned roadmap > > Thanks > -Vincent > >>> We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases... >>> >>> Thanks >>> -Vincent >>> >>> PS: With the same group effort we could release a first version of the new model for example ;) >>>

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

-- Thomas Mortagne

On Thu, May 16, 2013 at 6:09 PM, Vincent Massol <[email protected]> wrote:

On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:54 AM, Vincent Massol wrote:

...

On May 16, 2013, at 4:47 PM, Thomas Mortagne <[email protected]> wrote:

...

On Thu, May 16, 2013 at 4:25 PM, Vincent Massol <[email protected]> wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

And it's surely not going to improve...

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

Yes it's a huge change, that's why it's a vote.

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

It's not as trivial as you seems to think and it also mean that you simply can't use the standard git tools in the Windows world like the Github application or Tortoisegit without speaking or any EDI git integration... so not it really can't be seen as some obvious solution. And it's not like using Cygwin was some king of standard for Windows dev. "use cyggwin" is easy to say but the reality is that a dev will try to clone XWiki repository with the git tool he is used to and will simply can't, period.

What I'm saying is that I don't think it's worth the effort. By worth I mean the ratio between the effort and problems it'll require from us vs the # of windows dev not using cygwin that'll want to develop for the xwiki project…

But this is why we have a democracy and not a dictatorship. If the community considers it is worth the effort, and at least some devs are willing to work on this, then I think it's their right to do this.

1) You should re-read the governance. It's a meritocracy, i.e we vote important changes and devs need to be ok. So if one or a few devs want to do this but some other don't for some valid reason then it's not going to happen until we reach a decision.

2) It's all the devs that will bear the cost of maintaining the new environment, no just the dev who's willing to do the initial work.

BTW none of us work on a windows environment and I think it's a bad idea to implement support for something that we never use. It can only lead to something that gets broken frequently. To overcome this we'd need some windows agent and this means supporting that agent and making sure it works all the time (we tried in the past and failed for a very simple reason: none of the devs use windows and thus we don't care).

We are supposed to do automated tests on IE and that require being able to clone it. Since we offcially support IE this is just a new reason to start working on fixing our build on our Windows agents. So yes we do have an easy way to check that it's not broken.

...

It's not a good move to veto the will of the community.

Again (in case you didn't understand) I'm ok on the principle of doing this move but doing cowboy-coding without thinking about the consequences and letting other fix your stuff by only doing half of the work isn't my preferred style…

We've had enough bad examples of the dev environment being broken for week(s not so long ago that it's normal to want to be careful...

...

Anyway, there are other reasons to make the change, not just Windows compatibility. It saves about 2 seconds each time a dev wants to go to a directory from the command line. Going into one subdirectory means having to press "x tab <right prefix of the submodule> tab". The first two keys are superfluous since they're the same all the time. The deeper the hierarchy, the longer the time it takes to go there. It adds up to more than an hour wasted per year per dev, and I don't think it will really take a whole month of every dev to do the migration. If everybody contributes and we do a systematic effort, it could be done in an hour with the right planning.

So to reiterate and to be constructive, before we start any actual work on this I'd like that we do more evaluation. This means: * see a list of windows coders who have expressed a need (apart from Florin who I know already) and who have a real will to participate after the move. Do we have at least one?

I really don't think that's relevant. This is taking the thing the wrong way for me, you are never going to have anybody expressing a string will to participate when he can't even clone the source.

* that we list what needs to be done precisely. I've identified some so far: ** the git path changes ** modify all the xwiki.org pages linking to code

We can do retro compatibility for all the links that use scm macro.

** git history, will we loose ability to see history of files?

git log --follow

** others? * to list who is ok to participate actively in the move

Me of course.

* that we agree on a date so that it doesn't impact our planned roadmap

Thanks -Vincent

...

...

We're going to loose at least a month before we've finished that migration completely and I'm really worried about the toll it'll have on our releases...

Thanks -Vincent

PS: With the same group effort we could release a first version of the new model for example ;)

-- Sergiu Dumitriu

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On 05/16/2013 10:25 AM, Vincent Massol wrote:

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

Maybe they weren't motivated enough to search for a solution, and just gave up?

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

So postponing it will solve what?

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

Enforcing a special environment is something we try to avoid as much as possible. If the checkout doesn't work out of the box with the user's favorite tool, will they have the motivation to search for an explanation, read our documentation, set up the "right" tool, and learn to use a new environment that's not (perceived to be) as good as what they already know and are efficient with? This is not a "simple" solution, IMHO. XWiki Development should be environment-independent.

Thanks -Vincent

On May 16, 2013, at 4:14 PM, Thomas Mortagne <[email protected]> wrote:

...

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.

We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged...

As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size.

So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules.

Here is an example:

xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars)

would become

core/rendering/transformations/macro (36 chars)

So WDYT ?

Here is my +1

Big +1 from me.

...

I also find it nicer when navigating using cd and tab in a unix shell anyway.

Planning to do it in 5.1 if everyone agree.

-- Sergiu Dumitriu http://purl.org/net/sergiu

I'm no big developer, but one of the reasons I changed from Windows to Mac was using the cygwin (the other was testing the UI, but for me Mac was just an over expensive thing). Actually after we migrated to git, I remember to have many problems trying to commit something and I was really relieved to change my OS, but kind of reluctant since we had then many users on Windows (and in my mind I had somehow to share their environment needs). I would be +1 in order for us to be as accessible as we can regarding developers environments and also because it's shorter and easier to read. I don't know how much work there is, if this is a priority and all the things it will break. It will be very nice to hear some thoughts from other members of our community (I would be very interested also in the opinion of our GSOC students for example, or any other beginner contributor, not necessarily Java and also worldwide). Thanks, Caty On Thu, May 16, 2013 at 6:44 PM, Vincent Massol <[email protected]> wrote:

On May 16, 2013, at 5:10 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:25 AM, Vincent Massol wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

Maybe they weren't motivated enough to search for a solution, and just gave up?

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

So postponing it will solve what?

No

...

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

Enforcing a special environment is something we try to avoid as much as possible.

Agreed

...

If the checkout doesn't work out of the box with the user's favorite tool, will they have the motivation to search for an explanation, read our documentation, set up the "right" tool, and learn to use a new environment that's not (perceived to be) as good as what they already know and are efficient with?

This is not a "simple" solution, IMHO. XWiki Development should be environment-independent.

Sure but not at all cost.

For example there are tons of dev environments we don't support. It's not because they exist that we need to support them.

We need to remember that these dev envs must be first and foremost to make the life of those who code a lot for xwiki simpler.

Supporting more env means more work. It's the same as supporting N databases or N browsers…

Right now if we do the sam exercise as we did for the databases and the browsers we would never support the windows dev environment based on how many potential devs using windows we have or that we'll get…

It's a nice to have but far from critical. Again, the only person I know who asked about this was Florin. And that was in 7 years….

Thanks -Vincent

...

...

Thanks -Vincent

On May 16, 2013, at 4:14 PM, Thomas Mortagne <[email protected]> wrote:

...

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.

We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged...

As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size.

So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules.

Here is an example:

xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro

...

(131 chars)

would become

core/rendering/transformations/macro (36 chars)

So WDYT ?

Here is my +1

Big +1 from me.

...

...

I also find it nicer when navigating using cd and tab in a unix shell anyway.

Planning to do it in 5.1 if everyone agree.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On May 16, 2013, at 6:21 PM, Vincent Massol <[email protected]> wrote:

On May 16, 2013, at 6:14 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

I'm no big developer, but one of the reasons I changed from Windows to Mac was using the cygwin (the other was testing the UI, but for me Mac was just an over expensive thing). Actually after we migrated to git, I remember to have many problems trying to commit something and I was really relieved to change my OS, but kind of reluctant since we had then many users on Windows (and in my mind I had somehow to share their environment needs).

Yes this is a good point. We broke runtime support on Windows not long ago (is it still broken?) because the extension manager (or job module, I don't remember which) is/was generating too long paths in the xwiki data dir, depending on where you locate that data dir… I remember that the issue was with the version of xwiki (which is part of the path) and it was working fine on let's day "5.0" but failing on "5.0-milestone-1" which was several characters more (and repeated several times in full path)…

BTW the real problem is that we'll never fully fix the windows issue because it'll always depend on where the user or developer starts its root path. If it's already longish he'll quickly reach the 255 chars… Just keep in mind that we're just pushing the limit a little bit but not fixing the real issue… Thanks -Vincent

Supporting dev on windows and xwiki running on windows are 2 different matters. We really need to have some windows agents to verify that xwiki execute fine on windows (through our functional tests).

Thanks -Vincent

...

I would be +1 in order for us to be as accessible as we can regarding developers environments and also because it's shorter and easier to read.

I don't know how much work there is, if this is a priority and all the things it will break. It will be very nice to hear some thoughts from other members of our community (I would be very interested also in the opinion of our GSOC students for example, or any other beginner contributor, not necessarily Java and also worldwide).

Thanks, Caty

On Thu, May 16, 2013 at 6:44 PM, Vincent Massol <[email protected]> wrote:

...

On May 16, 2013, at 5:10 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 05/16/2013 10:25 AM, Vincent Massol wrote:

...

I'm rather -0 ATM and very close to -1 because:

1) I haven't heard from a windows dev for a long time, I don't think that happens that often

Maybe they weren't motivated enough to search for a solution, and just gave up?

...

2) It's a *huge* change and it should definitely not be done lightly. We would need to plan a period like 2 full days, all devs would need to stop working on what they do and help out. For example all pages on xwiki.org having some github links are going to be broken and will need to be updated (that's probably around hunded of pages overall)

So postponing it will solve what?

No

...

...

3) Windows devs have a simple solution which is to use cygwin so it's not a blocker

Enforcing a special environment is something we try to avoid as much as possible.

Agreed

...

If the checkout doesn't work out of the box with the user's favorite tool, will they have the motivation to search for an explanation, read our documentation, set up the "right" tool, and learn to use a new environment that's not (perceived to be) as good as what they already know and are efficient with?

This is not a "simple" solution, IMHO. XWiki Development should be environment-independent.

Sure but not at all cost.

For example there are tons of dev environments we don't support. It's not because they exist that we need to support them.

We need to remember that these dev envs must be first and foremost to make the life of those who code a lot for xwiki simpler.

Supporting more env means more work. It's the same as supporting N databases or N browsers…

Right now if we do the sam exercise as we did for the databases and the browsers we would never support the windows dev environment based on how many potential devs using windows we have or that we'll get…

It's a nice to have but far from critical. Again, the only person I know who asked about this was Florin. And that was in 7 years….

Thanks -Vincent

...

...

Thanks -Vincent

On May 16, 2013, at 4:14 PM, Thomas Mortagne <[email protected]> wrote:

...

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.

We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged...

As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size.

So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules.

Here is an example:

xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro

...

(131 chars)

would become

core/rendering/transformations/macro (36 chars)

So WDYT ?

Here is my +1

Big +1 from me.

...

...

I also find it nicer when navigating using cd and tab in a unix shell anyway.

Planning to do it in 5.1 if everyone agree.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Fri, May 17, 2013 at 3:56 PM, Flavius Olaru <[email protected]> wrote:

Hi guys,

Coming from an XWiki developer using Windows 7 as developing platform, fixing the path issue now won't fix the older existing tags. When you checkout an older tag with windows path issue it will be the same as it is.

I found myself using cygwin on windows or the github application.

The problem with path too long in git client application comes from msysgit which uses an deprecated windows api, (Win32).

github application really works ? it's supposed to use msysgit too and last time I tried it I would not clone platform (but it was a long time ago).

Thank you, Flavius

On Thu, May 16, 2013 at 5:14 PM, Thomas Mortagne <[email protected]>wrote:

...

Reviving http://markmail.org/message/hlnqke3igkbec332 for as an official vote.

We have waited way too long and I think we really need to find a solution even if none of the committers use Windows since a long time. Every time a Windows dev even think of contributing he is very quickly discouraged...

As a reminder the issue is that working on XWiki source code is a pain for MS Windows developers because of the (impossible to understand I agree) limitation on path size.

So the idea is to find a new logical rule to drastically shorten our paths and Sergiu proposed the following: remove duplicated information from our paths to maven modules.

Here is an example:

xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-transformations/xwiki-platform-rendering-transformation-macro (131 chars)

would become

core/rendering/transformations/macro (36 chars)

So WDYT ?

Here is my +1

I also find it nicer when navigating using cd and tab in a unix shell anyway.

Planning to do it in 5.1 if everyone agree.

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Flavius Olaru _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne