p2, 10 common pitfalls and how to avoid them

p2, 10 common pitfalls and how to avoid them

On Tuesday, Pascal and I presented “p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2” where we talked about the 10 most common pitfalls developers face when using p2. More importantly, we talked about how you can avoid them.

For those of you who attended the talk, thank-you.  I hope you learned something.  For those of you who could not attend, I’ve attached the slides here.

  • Thomas Hallgren
    Posted at 14:26, 2011-03-24

    Regarding #4, I would argue that leaving old stuff behind in your release repository, having it grow from being one single snappy repository to a big sluggish composite is a felony. Sure, there are cases when some users need old stuff,and for those users there need to be a composite of “everything” somewhere, but it should definitely not be the repository that everyone points to for their day to day work.

    The way many Eclipse repositories are made available today, as composites with more and more data in them, leads to slow installs and slow builds. I find myself cursing this approach every time I set something up. Very annoying.

  • Ian Bull
    Posted at 19:27, 2011-03-24


    The point we made in that slide was ‘have a retention policy’. It’s fine to remove old things, but don’t remove it simply because you release bad bits. You can’t assume you know what your users are doing with your repositories. As we do with the Eclipse Platform, we leave the IBuilds for the duration of the milestone… if we have some bad milestones, we don’t remove them until the milestone ships…

    Pascal can probably talk more about this, but I know it steams from peoples desire to remove things from central and the experience they had with the fallout from that.

  • Thomas Hallgren
    Posted at 14:28, 2011-03-26

    The way I see it, one thing doesn’t exclude the other. When you use an SCM, you normally use one single branch (or HEAD) and it would be really bad if you saw them all at once. You would then always needed to sort out which one to use, just like the planner must do now. I’d like to see an approach where the default would be to always use the latest and then have a chance to see (and be burdened with) older stuff only when you really need it. The occasions when that happens should be very rare.

  • Thomas Hallgren
    Posted at 10:10, 2011-03-29

    I’m referring to your slides in bugzilla:


    It’s interesting that some very large projects till make zips intended to be unzipped on top of your eclipse available for download.

  • Meh
    Posted at 15:43, 2011-10-28

    p2 is easy. You just need to learn about the differences between bundles, plug-ins, fragments, features, products, update sites, metadata, artifacts, contents, categories, installable units, p2.inf, site.xml, etc…
    Right.. so how to do it?
    Yeah just choose between the IDE wizard, p2.publisher, tycho, PDEbuild, Buckminster, ant tasks, Pluginbuilder, b3, Athena. So easy.
    Want to peek inside some existing update site so you know if you’re on the right track?
    Well since Eclipse is so clever it will just disallow your browser since the request wasn’t coming from p2.. Thanks a lot!
    oh well you just need to clone that repo using the command line p2.blabla.metadata.mirrorApplication. oh don’t forget to clone the artifacts as well. oh wait it seems that there is a new mirrorapplication that does both??

    oh yeah if p2 is slow this is *your* fault because you didn’t configure your repo properly.
    even though your archive is 0.5 MB it’s reasonable this takes 4 minutes to install.
    p2.director gives no indication of what’s taking so long time… no -verbose switch. thanks! 🙂

    here are some pages that do what you don’t recommend:
    i guess that’s official documentation.

    i am sorry about the rant, but it seems that p2 is just broken/so slow at times.
    i haven’t had many problems with .deb/ubuntu or easy_install in python. why should eclipse be so hard?