Hey,
On 2011-07-12, at 7:29 PM, Borislav Kapukaranov wrote:
> Hi,
>
> The code still has a reduced set of "interestingKeys" in
> BundlesAction:411-426 (toManifestString() method).
>
> It seems this change is fairly old. Is it possible that tycho uses older
> p2.publisher version?
> Or indeed this is configurable somehow and the touchpoint data is modified at
> a later point?
From memory Tycho has not yet been updated to use p2 3.7.
What you've seen in BundlesAction is everything when it comes to
generate an IU from a bundle. There is no flag to keep on including a complete
manifest in the IU.
> I'm curious about that because when integrating Virgo with p2 it became clear
> that the manifest of some artifacts or at least parts of it needs to be
> published as well in order to transfer the "uses" package data it contains
> and extract it later when deploying but prior executing the provisioning plan
> to feed it in an Equinox resolver.
To be sure, do you intend to do this resolution before downloading the
bundles?
If you don't, I have an easy answer, if you do, it is another story :)
Stepping back on why we stopped including the complete manifest in 3.7, this
was mostly done to improve the memory consumption when loading large repos.
Given that other changes have been done, it would worth checking what would be
the cost of reintroducing the manifests. Aside from this I can think of several
solutions:
1) adding a flag to the publisher for the IUs to always include the
manifests, but this could cause an issue for the consumer since some IUs in the
dependency chain of the one he wants to consume may not have the required
manifest information.
2) adding back the manifest in every IU, but improve the parsing code
to skip over the attribute and only load it on demand
3) enhancing the p2 requirement model to include the uses flag (so you
would have the data in there and could continue on what I assume is inferring
the manifest from the IU requirements) and having it be ignored by the p2
resolver for now.
4) change the code in BundlesAction to include the complete manifest if
it has a uses clause.
At this point, I think that 2 and 4 are the most viable. 3 would work, but is
heavier to coordinate since it will require a metadata change unless we decide
to play some trick with how the uses clause is expressed (e.g. we could have it
be a provided capability instead of a requirement but this is really ugly :) ).
Now two questions on the virgo aspect:
- How often does the resolution fail when the app is actually deployed?
- How will you handle the regions while invoking the resolver?
HTH
PaScaL
>
> So if there is a standard way to configure publishing the whole manifest it
> would be helpful to understand how its done.
> If there isn't then what do you think is the best way to transfer extra
> manifest data from publishing to the resolution phase?
> An idea can be to publish properties to the IUs containing just the "uses"
> data or maybe a new "uses" xml element. Obviously reverting to publish the
> whole manifest again is a step backwards.
>
> Thanks,
> Borislav
>
> 2011/7/12 Борислав Капукаранов <[email protected]>
> Hi,
>
> While browsing Eclipse's hudson server I stumbled upon some maven/tycho build
> jobs that publish p2 repositories with units containing the whole artifact
> manifest.
> For example check out the content.xml here:
> https://hudson.eclipse.org/hudson/job/gemini-management/ws/gemini.mgmt.repository/target/site/
> The pom.xml used to build this site is here:
> https://hudson.eclipse.org/hudson/job/gemini-management/ws/gemini.mgmt.repository/pom.xml
>
> Another example is this jetty repo:
> https://hudson.eclipse.org/hudson/view/Jetty-RT/job/jetty-wtp/ws/org.eclipse.jst.server.jetty.site/target/packed/repository/
>
> I thought publishing the whole manifest is removed from p2 due to performance
> issues. I'm pretty sure I saw it in the code too.
> Is it still possible to activate it somehow, considering these repositories I
> found?
>
> Thanks
> Borislav
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
