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-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] *On Behalf Of
*Doug Schaefer
*Sent:* Wednesday, August 21, 2013 2:14 PM
*To:* cross-project-issues-dev@xxxxxxxxxxx; '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-bounces@xxxxxxxxxxx
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor
Fedorenko
Sent: Wednesday, August 21, 2013 1:26 PM
To: cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
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.komissarchik@xxxxxxxxxx]
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-bounces@xxxxxxxxxxx
<mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx>
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of
Igor Fedorenko
Sent: Wednesday, August 21, 2013 12:55 PM
To:cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
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
<ifedorenko@xxxxxxxxxxxx <mailto:ifedorenko@xxxxxxxxxxxx>> 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@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
<mailto:cross-project-issues-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
