16 May
2013
16 May
'13
6:23 p.m.
On May 16, 2013, at 6:21 PM, Vincent Massol <vincent(a)massol.net> wrote:
On May 16, 2013, at 6:14 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com> wrote:
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
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)… 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 <vincent(a)massol.net> wrote:
On May 16, 2013, at 5:10 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <thomas.mortagne(a)xwiki.com>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs