Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [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.

Regards
Jan



-----Original Message-----
From: tycho-dev-bounces@xxxxxxxxxxx [mailto:tycho-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor Fedorenko
Sent: Freitag, 27. Mai 2011 18:17
To: tycho-dev@xxxxxxxxxxx
Subject: [tycho-dev] [discuss] tycho repository layout and metadata format

I think I am finally ready to give TYCHO-335 [1] 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 [2]
   - 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
   OSGi tools


Did I miss anything? Comments, ideas?


[1] https://issues.sonatype.org/browse/TYCHO-335
[2] http://search.maven.org/#stats

--
Regards,
Igor
_______________________________________________
tycho-dev mailing list
tycho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-dev

Back to the top