Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Windows path lengths [was: Re: [virgo-dev] Virgo P2 repository] 
I'm breaking out a separate thread to highlight and focus on this important issue (and to keep the other thread focussed on p2). The community can help us make some progress.

Bug 319270 was closed as WONTFIX simply because there aren't sufficient resources to investigate this thoroughly and provide point fixes. (There doesn't seem to be a clean, architected way to solve the problem.)

That said, we're open to someone doing the necessary investigation and proposing point fixes. If anyone does want to investigate this, please note that static path lengths are not the only issue. Virgo builds relatively deep directory structures when deploying artifacts, especially scoped plans and PARs, so these may contribute to the problem. I suspect this is what was observed in step 3 of the description of bug 319270, but the bug did not provide details, so the first step would be to recreate the problem and capture the actual failure.

Also, we'd be interested to hear from anyone else who ran into this issue on Virgo or dm Server and what they did to work around it. This issue has only surfaced a small number of times in the past and most users seemed comfortable with installing at or near the root of a drive. Perhaps the usage patterns are starting to change and so anyone else who cares about this issue should chime in.

Glyn
On 30 Jul 2010, at 18:47, Pete Carapetyan wrote:

Christopher:

FYI I've managed a much larger project than Virgo which had this exact same problem and we fixed the bug by simply refactoring the offending classes. Out of the 70k .java files and almost 300 bundles within the dependency tree, only about 10 or so java classes were the problem, and that number was small enough for us to do a simple refactoring in the IDE of the offending .java classes. Wasn't really so bad.

Can't say that this would be true of virgo's situation because I never downloaded the code. I had a simple routine somewhere that went through every class and calculated the path length, but of course I can't find that now. I'd write it again but sounded more like a religious issue when the bug was closed, so I didn't bother offering.

But in answer to your question, here is the bug, and also why you can't find it. It was removed. I assume that Glyn has more important issues to worry about than pesky windoze desktops users.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=319270
Product/Component: Virgo / core

Glyn Normington <gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
            Status|NEW                         |CLOSED
                CC|                            |gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>
        Resolution|                            |WONTFIX

--- Comment #1 from Glyn Normington <gnormington@xxxxxxxxxx<mailto:gnormington@xxxxxxxxxx>> 2010-07-09 04:33:44 EDT ---
I'm afraid there isn't a good solution as this is basically a Windows
limitation. We have always recommended unzipping dm Server/Virgo into C:\ to
avoid such problems. The only thing you can do is to ensure that your customers
install similarly, although I realise that this may be tricky to achieve if you
are packaging Virgo inside some kind of installer.

On Fri, Jul 30, 2010 at 9:12 AM, Christopher Frost <frostc@xxxxxxxxxx<mailto:frostc@xxxxxxxxxx>> wrote:
Hi,

Pete, do you still have a reference to the bug you raised, we can't find
it and want to have a look. Unfortunately the path length problem is a
known issue between Java and the operating system (not just limited to
Windows). As such we cannot fix it. We haven't seen it in quite a while
though so we would like to know the specifics if it is causing problems
again.

Hristo, we have looked at the P2 integration. From the build
perspective, do you know what ant/ivy targets you would use. We've had
difficulty using the ones from Eclipse as they have to be used from a
running Eclipse instance. Alternatives could include switching wholesale
to something like Tycho (which someone is looking at) but for now that
is a whole lot of work we don't have the time to bite off. If you have
any suggestions it would be great to hear them, your not the first to
ask about P2 and it's still something we want to do.

I've not looked in to the runtime side of things so much, thank you for
listing some benefits. Again we would need a cut down P2 client to embed
it in Virgo, we wouldn't be happy doing it the other way round. We would
have a provisioning system several times larger than the rest of Virgo.
I suspect we will do some more serious investigations in the future and
would welcome any input in the mean time.

Thanks,
Chris.



On 29/07/2010 16:46, Pete Carapetyan wrote:
Hristo:

This is a heads up that if you use it as an application platform, it has
to be installed at or near root on windows or you'll get errors due to
long path names. I filed it as a bug but it got immediately marked as
wont-fix.

This iced Virgo as a desktop platform for me, because I can't control
where users install it.

I will be very interested in following this thread, because my desires
still remain to use Virgo.

On Thu, Jul 29, 2010 at 7:57 AM, Iliev, Hristo <hristo.iliev@xxxxxxx<mailto:hristo.iliev@xxxxxxx>
<mailto:hristo.iliev@xxxxxxx<mailto:hristo.iliev@xxxxxxx>>> wrote:

   Hi,

   We want to use Virgo (kernel) as application platform. Since we are
   using Nexus repository manager we want to have P2 repository with
   Virgo inside and consume Virgo binaries from it.

   Besides the usual benefits from such approach ("own repositories to
   ensure stability within your organization") having a P2 repository
   means that Virgo can be:
           * installed with the standard Eclipse P2 installer
           * installed based on the OS/platform (only the relevant
   scripts/bundles/native parts)
           * put in one repository - Kernel & Web can be a features
   inside, so one can install Web on top of Kernel
           * updated/installed from external agent (based on P2 API or
   Eclipse P2 Installer tool)
           * provided to Eclipse developers as embedded application
   platform (or via dependency for eclipse plugins)

   We want this P2 repository to be a part of the Virgo build. The
   result can be provided on http://build.eclipse.org<http://build.eclipse.org/> as a start. The
   benefits from this approach (compared to having a proprietary P2
   repo) are that the repo will be:
           * modifiable, controlled and supported by the Virgo community
           * as close to the source as possible - this will allow the
   P2 repo to reflect the latest changes in Virgo

   The steps for creating a P2 repository will be:
           * upload equinox P2 bundles in s3 repository
           * modify the build to invoke P2 publishing (ant java task)

   Seems like P2 repo is a goal that can be achieved relatively easy
   but I'd like to hear also your opinion on this. Is someone already
   trying to do this or tried it in the past?

   Regards,
   Hristo Iliev

   _______________________________________________
   virgo-dev mailing list
   virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx> <mailto:virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>>

   https://dev.eclipse.org/mailman/listinfo/virgo-dev




--
Chris Frost
SpringSource <http://www.springsource.org<http://www.springsource.org/>>, a division of VMware
<http://www.vmware.com/>

Virgo Website <http://www.eclipse.org/virgo>, Wiki
<http://wiki.eclipse.org/Virgo> and Forum
<http://www.eclipse.org/forums/index.php?t=thread&frm_id=159>


_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx<mailto:virgo-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/virgo-dev

<ATT00001..txt>

Back to the top