[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] [discuss] tycho repository layout and metadata format
- From: "Sievers, Jan" <jan.sievers@xxxxxxx>
- Date: Tue, 31 May 2011 10:54:23 +0200
- Accept-language: en-US, de-DE
- Acceptlanguage: en-US, de-DE
- Delivered-to: email@example.com
- Thread-index: AcwciYCf8DDQ3bwdQXm9mYtQI3/j4gC3qt9w
- Thread-topic: [tycho-dev] [discuss] tycho repository layout and metadata format
>* focus on artifact deploy and dependency resolution during the build.
> To help us manage scope of this work, I want to explicitly exclude
> IU categories and other user-facing features from the scope.
We do support anything that is published by tycho in p2artifacts.xml/p2content.xml though?
I am thinking e.g. about feature root files or source bundles.
If we want to exclude other features, we have to make this very explicit as people will expect the repo to behave just like any plain p2 repo.
So effectively are we saying this is a repo format for tycho and at build time only, it's not something you can paste into the p2 update UI and install/update from it?
Another requirement that's important to us to ensure build reproducibility is good support for dependency management, i.e. exact control over which IUs are in the search scope of a build and which are not.
With Import-Package and repositories the size 200K+ IUs, requirements are bound to become ambiguous.
Also, there is widespread use of dependency ranges but there is often an implicit assumption that this dependency is resolved against a certain eclipse release train repo.
What we need IMHO is a concept of restricted "view" on the repository. In contrast to maven POM dependency management, for a build against released versions I would like to have a "white list" or "bill of materials" of IU versions that define the resolution scope.
Don't know whether dependency management should be done on client or server side or maybe both.
If it's on the server side, I could imagine e.g. "helios" and "indigo" views on the same repo. Each view would have a distinct URL similar to nexus repo groups.
If dependency management is done on the client side, we don't want everybody to define their own or copy-paste the target definition. So we would need a concept for reusing and composability of the target definition.
>* long term metadata compatibility strategy, i.e. artifacts deployed
> with tycho 1.0 should be consumable by tycho 2.3.1
For this we need to be clear whether we reuse the p2 metadata format or we define our own.
Since we use the p2 publishers, we have a dependency on the p2 metadata format.
AFAIK the p2 metadata format is not API.
From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor Fedorenko
Sent: Freitag, 27. Mai 2011 18:17
Subject: [tycho-dev] [discuss] tycho repository layout and metadata format
I think I am finally ready to give TYCHO-335  another try. For
uninitiated, this is about being able to share artifacts and
corresponding p2 metadata via a repository.Before I do anything I'd like
us to discuss and agree on high-level requirements for this
* synchronous or near-synchronous metadata update after deploy.
So if one Hudson (or cli) build deploys artifacts, the next build
is expected to be able to consume the artifacts
* efficiently support both deploy-only (i.e. RELEASE) and deploy-remove
(i.e. SNAPSHOT) repositories.
Although desirable, it is not a hard requirement to support both usage
patterns with single format, we can define two formats if needed.
* scale to 200K+ artifacts/installable units.
To put this in conext,
- there are ~160K artifacts in maven central 
- indigo M7 repo had ~11K IUs and was ~4.6M in size when jarred
- assuming comparable compression level, 200K IUs will be >65M jarred
* long term metadata compatibility strategy, i.e. artifacts deployed
with tycho 1.0 should be consumable by tycho 2.3.1
* focus on artifact deploy and dependency resolution during the build.
To help us manage scope of this work, I want to explicitly exclude
IU categories and other user-facing features from the scope.
* providing "simple" or "composite" p2 repository layouts is explicitly
NOT a requirement. likewise, using Maven2 repository layout is NOT
a requirement. Lets keep our options open
For bonus points
* allow efficient caching-proxy and aggregating repositories
* allow efficient implementation of fine-grained access control
* possibility to interact with maven-bundle-plugin and other maven
Did I miss anything? Comments, ideas?
tycho-dev mailing list