Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
If we decide to go though route, I recommend using .target file shared via a maven repository, not a parent pom. -- Regards, Igor On 2013-08-21 5:48 PM, Doug Schaefer wrote: Not really. It's all in the timing. This gives you the chance to build against newer bit from those projects, the same bits they'll be contributing to the next simrel build. And you don't need a pre-existing simrel build which is what started this thread. Sent from my BlackBerry 10 smartphone on the Rogers network. *From: *Konstantin Komissarchik *Sent: *Wednesday, August 21, 2013 5:16 PM *To: *'Cross project issues' *Reply To: *Cross project issues *Subject: *Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository That sounds identical in effect to building against simrel repo, with all the same issues. *From:*cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Doug Schaefer *Sent:* Wednesday, August 21, 2013 2:14 PM *To:* cross-project-issues-dev@eclipse.org; 'Cross project issues' *Subject:* Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Another option would be to create a top level pom that has all the dependent repos that feed into the aggregate and you can use that for your builds. Sent from my BlackBerry 10 smartphone on the Rogers network. *From: *Konstantin Komissarchik *Sent: *Wednesday, August 21, 2013 4:33 PM *To: *'Cross project issues' *Reply To: *Cross project issues *Subject: *Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository There are different issues at play... 1. Reproducible builds. This can be accomplished by either referencing a numbered build URL from a dependency or a numbered build URL from the aggregation (if such thing was available). 2. Controlling the scope of components that project build sees. Building against simrel repo risks accidentally taking a dependency on a project you didn't intend to take a dependency on. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org mailto: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 1:26 PM To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Is this really better than using single simrel repo as build target platform? I mean, all these repositories get aggregated into simrel repo on regular basis, so if we ignore reasonable short lag from the moment new stuff becomes available in individual repositories and when the aggregated repository is created, both individual repositories and the aggregate should include the same versions. There is one major difference. Aggregate repository will likely have less features than individual repositories, so it will be much easier to have successful build that will not be possible to aggregate. -- Regards, Igor On 2013-08-21 4:11 PM, Konstantin Komissarchik wrote: 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 [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 mailto: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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Yes, has been discussed before, and I said bad idea, because anyone building for the Luna repository, should not be building against the Luna repository. From: Eike Stepper step...@esc-net.de To: cross-project-issues-dev@eclipse.org, Date: 08/21/2013 03:49 AM Subject:[cross-project-issues-dev] Pre-M1 Aggregation Repository Sent by:cross-project-issues-dev-boun...@eclipse.org Hi, I noticed that an empty Luna repository had been created some time after the release of Kepler. An empty repository is not really useful as a source for build dependencies and I wondered if it would make sense in the future to seed the new repository with the old content. Would it? Has it been discussed already? Cheers /Eike http://www.esc-net.de http://thegordian.blogspot.com http://twitter.com/eikestepper ___ 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
I did the same, too. I simply don't have the time needed to maintain list of project-level repositories and will build against kepler until I can switch to luna simrel repo. -- Regards, Igor On 2013-08-21 4:05 AM, Marcel Bruch wrote: Maybe it would help if project could publish a (stable) URL of their latest Luna artifacts on a common wiki page? I had trouble to find all dependencies and features to set up our target platform accordingly two weeks ago. So decided to build the software against Kepler instead. Best, Marcel On Aug 21, 2013, at 9:57 AM, David M Williams david_willi...@us.ibm.com mailto:david_willi...@us.ibm.com wrote: Yes, has been discussed before, and I said bad idea, because anyone building for the Luna repository, should not be building against the Luna repository. From: Eike Stepper step...@esc-net.de mailto:step...@esc-net.de To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 08/21/2013 03:49 AM Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org Hi, I noticed that an empty Luna repository had been created some time after the release of Kepler. An empty repository is not really useful as a source for build dependencies and I wondered if it would make sense in the future to seed the new repository with the old content. Would it? Has it been discussed already? Cheers /Eike http://www.esc-net.de http://www.esc-net.de/ http://thegordian.blogspot.com http://thegordian.blogspot.com/ http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto: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 mailto: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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Theoretically, yes, it does open possibility for bad things to happen. In practice, however, this worked for us for last three releases. If there was an easy way to consume current simrel dependencies from the build, I'd certainly do it, but I am not willing to spend any time on this when building against previous simrel repo works good enough. -- Regards, Igor On 2013-08-21 10:08 AM, Doug Schaefer wrote: I'm with David on this one. The simrel repo is supposed to be the aggregation of all the project builds. If you are building against an old simrel repo, chances are you aren't building against the bits that will appear with your bits in this round's simrel repo. Doesn't that open up the potential for bad things? Doug. On 13-08-21 7:29 AM, Igor Fedorenko ifedore...@sonatype.com wrote: I did the same, too. I simply don't have the time needed to maintain list of project-level repositories and will build against kepler until I can switch to luna simrel repo. -- Regards, Igor On 2013-08-21 4:05 AM, Marcel Bruch wrote: Maybe it would help if project could publish a (stable) URL of their latest Luna artifacts on a common wiki page? I had trouble to find all dependencies and features to set up our target platform accordingly two weeks ago. So decided to build the software against Kepler instead. Best, Marcel On Aug 21, 2013, at 9:57 AM, David M Williams david_willi...@us.ibm.com mailto:david_willi...@us.ibm.com wrote: Yes, has been discussed before, and I said bad idea, because anyone building for the Luna repository, should not be building against the Luna repository. From: Eike Stepper step...@esc-net.de mailto:step...@esc-net.de To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 08/21/2013 03:49 AM Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org Hi, I noticed that an empty Luna repository had been created some time after the release of Kepler. An empty repository is not really useful as a source for build dependencies and I wondered if it would make sense in the future to seed the new repository with the old content. Would it? Has it been discussed already? Cheers /Eike http://www.esc-net.de http://www.esc-net.de/ http://thegordian.blogspot.com http://thegordian.blogspot.com/ http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto: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 mailto: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 ___ 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Hi You must be very lucky and grateful that the rest of us are doing your work for you. I find it essential to build against the nightly repositories of my dependencies in order to be able to react to their more 'innovative' changes. Regards Ed Willink On 21/08/2013 16:35, Igor Fedorenko wrote: Theoretically, yes, it does open possibility for bad things to happen. In practice, however, this worked for us for last three releases. If there was an easy way to consume current simrel dependencies from the build, I'd certainly do it, but I am not willing to spend any time on this when building against previous simrel repo works good enough. -- Regards, Igor On 2013-08-21 10:08 AM, Doug Schaefer wrote: I'm with David on this one. The simrel repo is supposed to be the aggregation of all the project builds. If you are building against an old simrel repo, chances are you aren't building against the bits that will appear with your bits in this round's simrel repo. Doesn't that open up the potential for bad things? Doug. On 13-08-21 7:29 AM, Igor Fedorenko ifedore...@sonatype.com wrote: I did the same, too. I simply don't have the time needed to maintain list of project-level repositories and will build against kepler until I can switch to luna simrel repo. -- Regards, Igor On 2013-08-21 4:05 AM, Marcel Bruch wrote: Maybe it would help if project could publish a (stable) URL of their latest Luna artifacts on a common wiki page? I had trouble to find all dependencies and features to set up our target platform accordingly two weeks ago. So decided to build the software against Kepler instead. Best, Marcel On Aug 21, 2013, at 9:57 AM, David M Williams david_willi...@us.ibm.com mailto:david_willi...@us.ibm.com wrote: Yes, has been discussed before, and I said bad idea, because anyone building for the Luna repository, should not be building against the Luna repository. From: Eike Stepper step...@esc-net.de mailto:step...@esc-net.de To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 08/21/2013 03:49 AM Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org Hi, I noticed that an empty Luna repository had been created some time after the release of Kepler. An empty repository is not really useful as a source for build dependencies and I wondered if it would make sense in the future to seed the new repository with the old content. Would it? Has it been discussed already? Cheers /Eike http://www.esc-net.de http://www.esc-net.de/ http://thegordian.blogspot.com http://thegordian.blogspot.com/ http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto: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 mailto: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 ___ 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3211/6594 - Release Date: 08/20/13 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
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 timeresources 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. This still does not solve the problem of reproducible builds, but I don't it's possible to have reproducible builds and build against latest versions of dependencies at the same time, i.e. these two requirements are mutually exclusive. -- Regards, Igor On 2013-08-21 12:51 PM, Konstantin Komissarchik wrote: Note that due to Equinox changes in Luna M1, this is a particularly dangerous time to not be building with Luna components when contributing to Luna. One of the primary reasons that it is bad to build against Luna simrel repo as opposed to particular builds of all dependencies is that an in-progress simrel repo is a moving target. This breaks a fundamental releng tenet by making builds not reproducible and requires the project team to remember to manually trigger a build just before contributing or risk contributing something built with stale dependencies. Note that these issue can be fixed quite easily by producing versioned simrel repos that are never modified... Doing this will not address all issues with using simrel repo as a build target, but it will make such strategy less fraught with problems. - 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 8:36 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Theoretically, yes, it does open possibility for bad things to happen. In practice, however, this worked for us for last three releases. If there was an easy way to consume current simrel dependencies from the build, I'd certainly do it, but I am not willing to spend any time on this when building against previous simrel repo works good enough. -- Regards, Igor On 2013-08-21 10:08 AM, Doug Schaefer wrote: I'm with David on this one. The simrel repo is supposed to be the aggregation of all the project builds. If you are building against an old simrel repo, chances are you aren't building against the bits that will appear with your bits in this round's simrel repo. Doesn't that open up the potential for bad things? Doug. On 13-08-21 7:29 AM, Igor Fedorenko ifedore...@sonatype.com wrote: I did the same, too. I simply don't have the time needed to maintain list of project-level repositories and will build against kepler until I can switch to luna simrel repo. -- Regards, Igor On 2013-08-21 4:05 AM, Marcel Bruch wrote: Maybe it would help if project could publish a (stable) URL of their latest Luna artifacts on a common wiki page? I had trouble to find all dependencies and features to set up our target platform accordingly two weeks ago. So decided to build the software against Kepler instead. Best, Marcel On Aug 21, 2013, at 9:57 AM, David M Williams david_willi...@us.ibm.com mailto:david_willi...@us.ibm.com wrote: Yes, has been discussed before, and I said bad idea, because anyone building for the Luna repository, should not be building against the Luna repository. From: Eike Stepper step...@esc-net.de mailto:step...@esc-net.de To: cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org, Date: 08/21/2013 03:49 AM Subject: [cross-project-issues-dev] Pre-M1 Aggregation Repository Sent by: cross-project-issues-dev-boun...@eclipse.org mailto:cross-project-issues-dev-boun...@eclipse.org --- - Hi, I noticed that an empty Luna repository had been created some time after the release of Kepler. An empty repository is not really useful as a source for build dependencies and I wondered if it would make sense in the future to seed the new repository with the old content. Would it? Has it been discussed already? Cheers /Eike http://www.esc-net.de http://www.esc-net.de/ http://thegordian.blogspot.com http://thegordian.blogspot.com/ http://twitter.com/eikestepper ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org mailto:cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
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. It's actually not that difficult once you get setup doing this. For Sapphire, we are currently building against 12 different targets (Indigo through Luna, including all SR levels and separately for 3.8 and 4.2 variants of Juno). Once a target definition references released binaries, you don't have to ever touch it again, so for instance, now I am only updating Kepler SR1 and Luna targets. This still does not solve the problem of reproducible builds, but I don't it's possible to have reproducible builds and build against latest versions of dependencies at the same time, i.e. these two requirements are mutually exclusive. Not mutually exclusive at all, but you do have to take explicit steps to move up to newer builds of your dependencies. For Sapphire, the first step in producing the milestone contribution is to update the target to milestone contributions of the dependencies. That triggers a build and we test that build. Thanks, - 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 10:46 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository 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 timeresources 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. This still does not solve the problem of reproducible builds, but I don't it's possible to have reproducible builds and build against latest versions of dependencies at the same time, i.e. these two requirements are mutually exclusive. -- Regards, Igor On 2013-08-21 12:51 PM, Konstantin Komissarchik wrote: Note that due to Equinox changes in Luna M1, this is a particularly dangerous time to not be building with Luna components when contributing to Luna. One of the primary reasons that it is bad to build against Luna simrel repo as opposed to particular builds of all dependencies is that an in-progress simrel repo is a moving target. This breaks a fundamental releng tenet by making builds not reproducible and requires the project team to remember to manually trigger a build just before contributing or risk contributing something built with stale dependencies. Note that these issue can be fixed quite easily by producing versioned simrel repos that are never modified... Doing this will not address all issues with using simrel repo as a build target, but it will make such strategy less fraught with problems. - 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 8:36 AM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Theoretically, yes, it does open possibility for bad things to happen. In practice, however, this worked for us for last three releases. If there was an easy way to consume current simrel dependencies from the build, I'd certainly do it, but I am not willing to spend any time on this when building against previous simrel repo works good enough. -- Regards, Igor On 2013-08-21 10:08 AM, Doug Schaefer wrote: I'm with David on this one. The simrel repo is supposed to be the aggregation of all the project builds. If you are building against an old simrel repo, chances are you aren't building against the bits that will appear with your bits in this round's simrel repo. Doesn't that open up the potential for bad things? Doug. On 13-08-21 7:29 AM, Igor Fedorenko ifedore...@sonatype.com wrote: I did the same, too. I simply don't have the time needed to maintain list of project-level repositories and will build against kepler until I can switch to luna simrel repo. -- Regards, Igor On 2013-08-21 4:05 AM, Marcel Bruch wrote: Maybe it would help if project could publish a (stable) URL of their latest Luna artifacts on a common wiki page? I had trouble to find all dependencies and features to set up our target platform
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
On Wed, Aug 21, 2013 at 7:45 PM, Igor Fedorenko ifedore...@sonatype.comwrote: 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 timeresources 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). 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
BTW, as I work through my maven/tycho prototype for the aggregator, it doesn't seem that far fetched that would could have nightly aggregator builds. Not sure why we couldn't have that now mind you. BTW2, I fear the Nexus. But that's probably just me and my lack of education on it. I know how to manage my p2 repos. Doug. From: Matthias Sohn matthias.s...@gmail.commailto:matthias.s...@gmail.com Reply-To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Date: Wednesday, 21 August, 2013 3:47 PM To: Cross project issues cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository On Wed, Aug 21, 2013 at 7:45 PM, Igor Fedorenko ifedore...@sonatype.commailto: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 timeresources 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.orghttp://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
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 timeresources 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
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 timeresources 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
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 timeresources 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Is this really better than using single simrel repo as build target platform? I mean, all these repositories get aggregated into simrel repo on regular basis, so if we ignore reasonable short lag from the moment new stuff becomes available in individual repositories and when the aggregated repository is created, both individual repositories and the aggregate should include the same versions. There is one major difference. Aggregate repository will likely have less features than individual repositories, so it will be much easier to have successful build that will not be possible to aggregate. -- Regards, Igor On 2013-08-21 4:11 PM, Konstantin Komissarchik wrote: 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 timeresources 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 ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
There are different issues at play... 1. Reproducible builds. This can be accomplished by either referencing a numbered build URL from a dependency or a numbered build URL from the aggregation (if such thing was available). 2. Controlling the scope of components that project build sees. Building against simrel repo risks accidentally taking a dependency on a project you didn't intend to take a dependency on. - 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 1:26 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Is this really better than using single simrel repo as build target platform? I mean, all these repositories get aggregated into simrel repo on regular basis, so if we ignore reasonable short lag from the moment new stuff becomes available in individual repositories and when the aggregated repository is created, both individual repositories and the aggregate should include the same versions. There is one major difference. Aggregate repository will likely have less features than individual repositories, so it will be much easier to have successful build that will not be possible to aggregate. -- Regards, Igor On 2013-08-21 4:11 PM, Konstantin Komissarchik wrote: 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 timeresources 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
Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
That sounds identical in effect to building against simrel repo, with all the same issues. From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Doug Schaefer Sent: Wednesday, August 21, 2013 2:14 PM To: cross-project-issues-dev@eclipse.org; 'Cross project issues' Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Another option would be to create a top level pom that has all the dependent repos that feed into the aggregate and you can use that for your builds. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Konstantin Komissarchik Sent: Wednesday, August 21, 2013 4:33 PM To: 'Cross project issues' Reply To: Cross project issues Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository There are different issues at play... 1. Reproducible builds. This can be accomplished by either referencing a numbered build URL from a dependency or a numbered build URL from the aggregation (if such thing was available). 2. Controlling the scope of components that project build sees. Building against simrel repo risks accidentally taking a dependency on a project you didn't intend to take a dependency on. - 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 1:26 PM To: cross-project-issues-dev@eclipse.org Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository Is this really better than using single simrel repo as build target platform? I mean, all these repositories get aggregated into simrel repo on regular basis, so if we ignore reasonable short lag from the moment new stuff becomes available in individual repositories and when the aggregated repository is created, both individual repositories and the aggregate should include the same versions. There is one major difference. Aggregate repository will likely have less features than individual repositories, so it will be much easier to have successful build that will not be possible to aggregate. -- Regards, Igor On 2013-08-21 4:11 PM, Konstantin Komissarchik wrote: 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 timeresources 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
