[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Virgo P2 repository
|
This seems reasonable to me. The only concern I have is that build.eclipse.org may not be a suitable place to host a p2 repository if it is likely to be used by the broader Virgo community and not just Virgo developers.
Glyn
On 2 Aug 2010, at 08:56, Iliev, Hristo wrote:
> Hi,
>
> The long paths can really be an issue on Windows - Sun JVM had 256 characters limitation due to use of old/compatible APIs ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403166 ) and most of the archiver and file manager UIs on Windows can't cope with long paths as well.
>
> The P2 repository however will not only help by providing an installer (already present in Eclipse community), but also will give Virgo additional abilities - it will be consumable in consistent and modular manner by all P2 users (Eclipse, Nexus, installers:).
>
> Installer would be responsible for deploying set of features (bundles/scripts/content) and later adding or removing stuff.
>
> Consistency is ensured not only by the same mechanism (p2) for all Eclipse provisioning tools but also by the dependencies between different parts - if additional bundles or scripts are required they will be fetched from the repository.
>
> The modularity depends on the way the repository is structured - the community can decide to have only web and kernel or can split Virgo on more parts (kernel & user space, Spring....).
>
> We do not want however to change Virgo provisioning or to integrate P2 with Virgo. The target here is to make separate P2 repository from which Virgo can be consumed (installed/updated/embedded).
>
> Regards,
> Hristo Iliev
>
>
>
>
>
> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Pete Carapetyan
> Sent: Friday, July 30, 2010 8:47 PM
> To: Virgo Project
> Subject: Re: [virgo-dev] Virgo P2 repository
>
> 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> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |CLOSED
> CC| |gnormington@xxxxxxxxxx
> Resolution| |WONTFIX
>
> --- Comment #1 from Glyn Normington <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> 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>> 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 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>
>
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
>
>
> --
> Chris Frost
> SpringSource <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
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
