Just thinking out loud... We already have information about what individual repositories go into a given simrel aggregation build. What if the build produced a report listing the input repositories? From there, it's a relatively small step to have the portal show the project's contributed URLs for various simrel releases.
Of course, that will expose another problem, that many projects contribute a mutable repository to aggregation... - Konstantin -----Original Message----- From: Konstantin Komissarchik [mailto:konstantin.komissarc...@oracle.com] Sent: Wednesday, August 21, 2013 1:04 PM To: 'Cross project issues' Subject: RE: [cross-project-issues-dev] Pre-M1 Aggregation Repository A single repo that has everyone's builds, milestones and releases would make the situation worse rather than better. Whether you use an uber p2 repo with links or Maven. The issue is how do you control that you are building against a particular build of your dependency. Instead of having to manage the URL of the build, you have to manage the version of each feature from that build that your build is consuming. After all, you don't want to just pickup the random newest version. That's a lot more work. - Konstantin -----Original Message----- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Igor Fedorenko Sent: Wednesday, August 21, 2013 12:55 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Nexus does not support mutable p2 repositories similar to maven, so we will have to deploy separate p2 repository per build per project. I am not sure what advantages this will have compared to existing download area, and we will still have no easy way to tell what repositories should be used for what yearly release. -- Regards, Igor On 2013-08-21 3:47 PM, Matthias Sohn wrote: > On Wed, Aug 21, 2013 at 7:45 PM, Igor Fedorenko > <ifedore...@sonatype.com <mailto:ifedore...@sonatype.com>> wrote: > > Again, I am not arguing against building with individual dependency > repositories. All I am saying there is currently no convenient way to do > this and I don't have the time&resources to maintain such fine-grained > dependency configuration. I am particularly concerned about two > problems. > > First, I need to find location of proper dependency versions to build > for luna, kepler and juno (we have N-1 compatibility policy). Second, I > need a way to know if these dependency repositories go stale and need to > be updated. > > One way to address these is to require each participating project > provide separate repository URL they recommend for use as build target > for each yearly release and make list of these URLs documented > somewhere. > > > maybe it would help if we would ask all projects to deploy their > snapshots/milestones/releases into Nexus (repo.eclipse.org > <http://repo.eclipse.org>). This would simplify finding all these p2 > repositories in a central place. > > -- > Matthias > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
