Re: [cross-project-issues-dev] Kepler SR1 RC1 staging (maintenance) repo is complete

[Ed Willink]

  
  
Hi

On 22/08/2013 02:16, David M Williams
  wrote:

2. Check the repo
reports for any surprises:
  
  
  http://build.eclipse.org/simrel/kepler/reporeports/
  

75% of bundles do not use Eclipse-SourceReferences, so I
guess that many releng's are as confused as I am by the lack of
Buckminster documentation.

Thanks to ECF for some clues. It's really easy. Just add
-DgenerateSourceReferences=true

on the Buckminster/Java command line or

generateSourceReferences=true

in the Buckmnister build.properties

	Regards

		Ed Willink

  

___
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] Status and Outlook for Luna M1 -- please continue ...

[David M Williams]

We actually have gotten some green builds, and there is a "staging repo" 
at 

http://download.eclipse.org/releases/staging/

But it is only about half complete. 

503 features and 2611 bundles (compared to Kepler, which has 946 features, 
and 4870 bundles). 

There are still 25 project files with disabled contributions ... and more 
than that, if you count disabled feature or repositories. 

While the deadline was today, at 5:00, here is plan B: We'll extend the 
deadline another day, to see if we can get a more complete aggregation 
repository. 
If so, there might be some possibility Markus would have "enough pieces" 
to build  at least some EPP packages by late Friday (but, not sure that 
leaves enough time to call them tested). 
If not ... if we do not get enough contributions ... we will just count M1 
as "failed to deliver" and move on to M2.. 

So, point is, if you are not yet enabled for Luna M1, please do so. If any 
of your "pre-req projects" are blocking you from making progress ... 
please let them know. 

Thanks, 
___
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] Kepler SR1 RC1 staging (maintenance) repo is complete

[David M Williams]

I'm assuming the EPP packages will be ready early "tomorrow" depending on 
your time zone. But, as far as the sim. release repo ... 

1. Check the maintenance aggregated repo to be sure it has what you expect 
it to have (but, as the "warm-up RC" we do not consider it a true "Release 
Candidate", so no need for extensive adopter testing or similar and little 
need of a "respin" ... unless something is truly data damaging). 
 
http://download.eclipse.org/releases/maintenance/ 

2. Check the repo reports for any surprises:

http://build.eclipse.org/simrel/kepler/reporeports/

3. Since the next 3 RCs will soon be coming "fast and furious", now is a 
good time to brush-up on "how to test" the repositories: 
http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_way_to_test_with_the_staging_repository.3F

I have disabled the "simrel.kepler.runaggregator" job  for now, to avoid 
confusion, but will re-enable it on Friday, after the EPP packages are 
complete and declared. 

Remember, there is no "promotion" of the maintenance repo to someplace 
else ... until we actually get to the "Release of SR1". Test early and 
test often is never truer than in a maintenance release. 

Thanks all for making this first RC the best it could be and thanks for 
your contributions to Eclipse.
___
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

[Doug Schaefer]

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] 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

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Konstantin Komissarchik]

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 
>> 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

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Doug Schaefer]

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
>> 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
>> ). This would simplify finding all these p2
>> repositories

[cross-project-issues-dev] Re : Re: Status and outlook for Luna M1

[Grégoire Dupé]

Hello,

I'm waiting for Acceleo to deliver MoDisco in Luna.

By the way, I get the following error :

Missing requirement: MoDisco Java Server Pages Discoverer (Incubation) 
0.12.0.201308191929 (org.eclipse.modisco.jee.jsp.discoverer 
0.12.0.201308191929) requires 'bundle org.antlr.runtime [3.0.0,3.1.0)' but it 
could not be found

Bundle(org.antlr.runtime [3.0.0,3.1.0)) is required by:
  ValidationSet(main)
Contribution(MoDisco)
  
MappedRepository(http://download.eclipse.org/modeling/mdt/modisco/updates/integration/0.12.0/I201308191929/)
Feature(org.eclipse.modisco.sdk.feature.feature.group 0.12.0)
  InstallableUnit(org.eclipse.modisco.jee.feature.feature.group 
0.12.0.201308191929)
InstallableUnit(org.eclipse.modisco.jee.jsp.discoverer 
0.12.0.201308191929)

For Kepler, I haven't provided antlr in the MoDisco updates site. Must I for 
Luna ?

If I must add antlr in the MoDisco update site, I won't be able to deliver 
MoDisco before tommorrow morning (Europe time).

Regrads,
Grégoire

- Mail d'origine -
De: Greg Watson 
À: Cross project issues 
Envoyé: Wed, 21 Aug 2013 21:48:44 +0200 (CEST)
Objet: Re: [cross-project-issues-dev] Status and outlook for Luna M1

Thanks!

On Aug 21, 2013, at 3:39 PM, David Dykstal  wrote:

> It exists now. 
> http://download.eclipse.org/tm/updates/3.6milestones/ 
> 
> -- David Dykstal,  Architect - Rational Developer for i 
> 
> 
> 
> From:Greg Watson  
> To:Cross project issues , 
> Date:08/21/2013 01:45 PM 
> Subject:Re: [cross-project-issues-dev] Status and outlook for Luna M1 
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> 
> 
> 
> Does TM have a luna repo somewhere? I can't seem to find one.
> 
> Thanks,
> Greg
> 
> On Aug 21, 2013, at 1:14 PM, David Dykstal  wrote:
> 
> > I have enabled TM.
> > 
> > Doug Schaefer wrote:
> >> Sigh. RSE isn't enabled so CDT fails.
> >> 
> > ___
> > 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

[Konstantin Komissarchik]

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 
>> 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 
>> ). 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
> http

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Igor Fedorenko]

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
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
). 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

[Konstantin Komissarchik]

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 
> 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 
> ). 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

[Konstantin Komissarchik]

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 
> 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 
> ). 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

[Igor Fedorenko]

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 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
). 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

[Doug Schaefer]

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 mailto:matthias.s...@gmail.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, 21 August, 2013 3:47 PM
To: Cross project issues 
mailto: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 
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). 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] Status and outlook for Luna M1

[Greg Watson]

Thanks!

On Aug 21, 2013, at 3:39 PM, David Dykstal  wrote:

> It exists now. 
> http://download.eclipse.org/tm/updates/3.6milestones/ 
> 
> -- David Dykstal,  Architect - Rational Developer for i 
> 
> 
> 
> From:Greg Watson  
> To:Cross project issues , 
> Date:08/21/2013 01:45 PM 
> Subject:Re: [cross-project-issues-dev] Status and outlook for Luna M1 
> Sent by:cross-project-issues-dev-boun...@eclipse.org 
> 
> 
> 
> Does TM have a luna repo somewhere? I can't seem to find one.
> 
> Thanks,
> Greg
> 
> On Aug 21, 2013, at 1:14 PM, David Dykstal  wrote:
> 
> > I have enabled TM.
> > 
> > Doug Schaefer wrote:
> >> Sigh. RSE isn't enabled so CDT fails.
> >> 
> > ___
> > 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

[Matthias Sohn]

On Wed, Aug 21, 2013 at 7:45 PM, Igor Fedorenko 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). 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] Status and outlook for Luna M1

[David Dykstal]

It exists now.
http://download.eclipse.org/tm/updates/3.6milestones/

-- David Dykstal,  Architect - Rational Developer for i



From:   Greg Watson 
To: Cross project issues , 
Date:   08/21/2013 01:45 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for Luna 
M1
Sent by:cross-project-issues-dev-boun...@eclipse.org



Does TM have a luna repo somewhere? I can't seem to find one.

Thanks,
Greg

On Aug 21, 2013, at 1:14 PM, David Dykstal  
wrote:

> I have enabled TM.
> 
> Doug Schaefer wrote:
>> Sigh. RSE isn't enabled so CDT fails.
>> 
> ___
> 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] Status and outlook for Luna M1

[Doug Schaefer]

Not to join would be a disservice to the community. Glad you allow us in. :)

Sent from my BlackBerry 10 smartphone on the Rogers network.
From: David M Williams
Sent: Wednesday, August 21, 2013 2:54 PM
To: Cross project issues
Reply To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1


I've enabled most of WTP (and yes, Carl asked me specifically to cover for him 
:) ... I enabled all the pieces that do not depend on DTP (e.g. JPA) ... so 
that should get us a little further. My local "validation" worked in editor and 
we'll see how the Hudson aggregation goes.

Unfortunately -- from the poking around I've done -- DTP (and BIRT) likely 
won't be enabled/updated until 7 or 8 Eastern time  at the earliest ... due to 
timezone differences ... so a) don't worry about getting lots of failures the 
rest of the day ... I know all the email "build break reminders" drives people 
crazy. But, b) we will still try to have a relatively complete repo for M1 but 
not sure there will be time to do EPP packages ... but ... I am forever 
optimistic -- believe it or not.

We are currently down to 27 (from yesterday's 50) projects that have not 
enabled their contribution. (List below) Unfortunately many of those (like DTP) 
are depended on by many others so I remind you "low level" projects you are 
holding up others!

@Igor, and others, the advantage to enabling contribution even if you leave 
repo disabled due to missing pre-reqs is just a matter of helping me (and 
others) track the current state and likelihood of making the goal. If, by 
Thursday morning, there are still, say 20, who have not even bothered to enable 
contribution, I'd be prone to conclude "no way". Whereas if all contributions 
were enabled, and just some features were not yet "fitting together", I might 
be more optimistic it could be worked out by end of Thursday. [Since you asked 
"why bother".]

@Doug, and others ... no problem at all for me to set enabled="false" ... and, 
you know, I can never tell about CDT -- if they'll be the release or not ... 
glad you decided to join!  :)

= = = = =

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build







From:"Konstantin Komissarchik" 
To:"'Cross project issues'" ,
Date:08/21/2013 02:29 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for Luna M1
Sent by:cross-project-issues-dev-boun...@eclipse.org




Sapphire contribution is waiting on WTP contribution, which is waiting on DTP 
contribution. Disabling higher-level contributions until all the dependencies 
have been contributed is one option, but creates a lot of churn and forces a 
linear contribution path that guarantees that M1 repo is going to be quite 
thin. If WTP is still not contributed by the end of the day, I will disable 
Sapphire, but I am not sure how many EPP packages can be created from a 
repository in such a state…

- Konstantin


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber, 
Martin
Sent: Wednesday, August 21, 2013 10:36 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

I have “declared intent” for tcf-1.2 by enabling the contribution … but will 
keep the repo disabled until the build is green.

The build has been failing since 11.01am server time today so I’m not sure if 
it’s a good idea adding more contributions before it is green … in the end, 
someone (David?) would need to disable culprits.

FWIW, when running the “validate aggregation” in the b3 model editor I get this 
error right now:

Cannot complete the install because one or more required items could not be 
found.
Missing requirement: Sapphire XML Editor Suppor

Re: [cross-project-issues-dev] Status and Outlook for Kepler SR1 RC1

[Gunnar Wagenknecht]

Am 21.08.2013 um 21:07 schrieb David M Williams :
> But, more important, one of the ones listed was 
> org.eclipse.gemini.jpa_1.1.0.RELEASE.jar 


That has been reported during the Kepler builds and fixed for the next release. 
However, I don't think that will go into Kepler but maybe Luna.

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org





___
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] Status and Outlook for Kepler SR1 RC1

[David M Williams]

Looks like everyone is enabled now (except for that one feature in DLTK, 
see bug 415535). 

And contributions are still being updated. 

I will remind everyone to check the "repo reports" though ... 
http://build.eclipse.org/simrel/kepler/reporeports/

Not all has to be fixed for RC1, but, glancing at the "required files" 
one, 
http://build.eclipse.org/simrel/kepler/reporeports/reports/layoutCheck.txt
showed 19 missing about.html files ... and I wonder ... how that can 
happen so easily? 

But, more important, one of the ones listed was 
org.eclipse.gemini.jpa_1.1.0.RELEASE.jar

That looks like a qualifier that could cause problems? (Not that I know 
for sure ... just saying ... ). 

Which reminds me, did that "nebula grid" released-or-not problem ever get 
solved? Not sure I'm looking at correct bug, but still see this one open:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411867

Thanks, 

___
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] Status and outlook for Luna M1

[Carsten Reckord]

Make that 26, I've enabled MPC now. Sorry to be this late to the party.

On 21.08.2013 20:53, David M Williams wrote:
> We are currently down to 27 (from yesterday's 50) projects that have not 
> enabled their contribution. (List below) Unfortunately many of those (like 
> DTP) are depended on by many others so I remind you "low level" projects 
> you are holding up others!

___
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] Status and outlook for Luna M1

[David M Williams]

I've enabled most of WTP (and yes, Carl asked me specifically to cover for 
him :) ... I enabled all the pieces that do not depend on DTP (e.g. JPA) 
... so that should get us a little further. My local "validation" worked 
in editor and we'll see how the Hudson aggregation goes. 

Unfortunately -- from the poking around I've done -- DTP (and BIRT) likely 
won't be enabled/updated until 7 or 8 Eastern time  at the earliest ... 
due to timezone differences ... so a) don't worry about getting lots of 
failures the rest of the day ... I know all the email "build break 
reminders" drives people crazy. But, b) we will still try to have a 
relatively complete repo for M1 but not sure there will be time to do EPP 
packages ... but ... I am forever optimistic -- believe it or not. 

We are currently down to 27 (from yesterday's 50) projects that have not 
enabled their contribution. (List below) Unfortunately many of those (like 
DTP) are depended on by many others so I remind you "low level" projects 
you are holding up others!

@Igor, and others, the advantage to enabling contribution even if you 
leave repo disabled due to missing pre-reqs is just a matter of helping me 
(and others) track the current state and likelihood of making the goal. 
If, by Thursday morning, there are still, say 20, who have not even 
bothered to enable contribution, I'd be prone to conclude "no way". 
Whereas if all contributions were enabled, and just some features were not 
yet "fitting together", I might be more optimistic it could be worked out 
by end of Thursday. [Since you asked "why bother".]

@Doug, and others ... no problem at all for me to set enabled="false" ... 
and, you know, I can never tell about CDT -- if they'll be the release or 
not ... glad you decided to join!  :) 

= = = = =

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build







From:   "Konstantin Komissarchik" 
To: "'Cross project issues'" , 
Date:   08/21/2013 02:29 PM
Subject:Re: [cross-project-issues-dev] Status and outlook for Luna 
M1
Sent by:cross-project-issues-dev-boun...@eclipse.org



Sapphire contribution is waiting on WTP contribution, which is waiting on 
DTP contribution. Disabling higher-level contributions until all the 
dependencies have been contributed is one option, but creates a lot of 
churn and forces a linear contribution path that guarantees that M1 repo 
is going to be quite thin. If WTP is still not contributed by the end of 
the day, I will disable Sapphire, but I am not sure how many EPP packages 
can be created from a repository in such a state…
 
- Konstantin
 
 
From: cross-project-issues-dev-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of 
Oberhuber, Martin
Sent: Wednesday, August 21, 2013 10:36 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1
 
I have “declared intent” for tcf-1.2 by enabling the contribution … but 
will keep the repo disabled until the build is green.
 
The build has been failing since 11.01am server time today so I’m not sure 
if it’s a good idea adding more contributions before it is green … in the 
end, someone (David?) would need to disable culprits.
 
FWIW, when running the “validate aggregation” in the b3 model editor I get 
this error right now:
 
Cannot complete the install because one or more required items could not 
be found.
Missing requirement: Sapphire XML Editor Support (Incubation) 
0.7.0.201308211148 (org.eclipse.sapphire.ui.swt.xml.editor 
0.7.0.201308211148) requires 'bundle org.eclipse.wst.sse.core 
[1.1.600,2.0.0)' but it could not be found
 
Bundle(org.eclipse.wst.sse.core [1.1.600,2.0.0)) is required by:
  ValidationSet(main)
Contribution(Sapphire)
  MappedRepository(
http://download.eclipse.org/sapphire/0.7.0.2

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Greg Watson]

Does TM have a luna repo somewhere? I can't seem to find one.

Thanks,
Greg

On Aug 21, 2013, at 1:14 PM, David Dykstal  wrote:

> I have enabled TM.
> 
> Doug Schaefer wrote:
>> Sigh. RSE isn't enabled so CDT fails.
>> 
> ___
> 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] Status and outlook for Luna M1

[Konstantin Komissarchik]

Sapphire contribution is waiting on WTP contribution, which is waiting on
DTP contribution. Disabling higher-level contributions until all the
dependencies have been contributed is one option, but creates a lot of churn
and forces a linear contribution path that guarantees that M1 repo is going
to be quite thin. If WTP is still not contributed by the end of the day, I
will disable Sapphire, but I am not sure how many EPP packages can be
created from a repository in such a state.

 

- Konstantin

 

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of
Oberhuber, Martin
Sent: Wednesday, August 21, 2013 10:36 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

 

I have "declared intent" for tcf-1.2 by enabling the contribution . but will
keep the repo disabled until the build is green.

 

The build has been failing since 11.01am server time today so I'm not sure
if it's a good idea adding more contributions before it is green . in the
end, someone (David?) would need to disable culprits.

 

FWIW, when running the "validate aggregation" in the b3 model editor I get
this error right now:

 

Cannot complete the install because one or more required items could not be
found.

Missing requirement: Sapphire XML Editor Support (Incubation)
0.7.0.201308211148 (org.eclipse.sapphire.ui.swt.xml.editor
0.7.0.201308211148) requires 'bundle org.eclipse.wst.sse.core
[1.1.600,2.0.0)' but it could not be found

 

Bundle(org.eclipse.wst.sse.core [1.1.600,2.0.0)) is required by:

  ValidationSet(main)

Contribution(Sapphire)

 
MappedRepository(http://download.eclipse.org/sapphire/0.7.0.201308211148/rep
ository)

Feature(org.eclipse.sapphire.ui.swt.xml.editor.feature.group 0.7.0)

  InstallableUnit(org.eclipse.sapphire.ui.swt.xml.editor
0.7.0.201308211148)

 

Thanks,

Martin

--

Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River

direct +43.662.457915.85  fax +43.662.457915.6

 

From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M
Williams
Sent: Wednesday, August 21, 2013 6:01 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and outlook for Luna M1

 

Doesn't look good. I'll admit there is one day left, but so far 50 projects
have not even enabled their "contribution" to Luna (pasted below). 

Thank you to the 20 of you who have. 

Remember, enable your contribution if you plan to participate (remove the
"enabled="false"), but disable your repository if you are simply waiting for
pre-reqs to get enabled or fixed (disable by adding enabled="false" to your
repository element(s)). 

Please ask if questions. (Or, please say if you have explicitly decided not
to participate in Luna). 

Thanks, 

= = = = = 

This list are those that have not yet enabled contribution: 

actf.b3aggrcon - org.eclipse.simrel.build 
amalgam.b3aggrcon - org.eclipse.simrel.build 
amp.b3aggrcon - org.eclipse.simrel.build 
birt.b3aggrcon - org.eclipse.simrel.build 
cdt.b3aggrcon - org.eclipse.simrel.build 
dltk.b3aggrcon - org.eclipse.simrel.build 
dtp.b3aggrcon - org.eclipse.simrel.build 
ecf.b3aggrcon - org.eclipse.simrel.build 
egit.b3aggrcon - org.eclipse.simrel.build 
emf-cdo.b3aggrcon - org.eclipse.simrel.build 
emf-compare.b3aggrcon - org.eclipse.simrel.build 
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build 
emf-query.b3aggrcon - org.eclipse.simrel.build 
emf-transaction.b3aggrcon - org.eclipse.simrel.build 
emf-validation.b3aggrcon - org.eclipse.simrel.build 
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build 
emft-eef.b3aggrcon - org.eclipse.simrel.build 
emft-egf.b3aggrcon - org.eclipse.simrel.build 
emft-emffacet.b3aggrcon - org.eclipse.simrel.build 
epp-mpc.b3aggrcon - org.eclipse.simrel.build 
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build 
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build 
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build 
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build 
jubula.b3aggrcon - org.eclipse.simrel.build 
jwt.b3aggrcon - org.eclipse.simrel.build 
koneki.b3aggrcon - org.eclipse.simrel.build 
linuxtools.b3aggrcon - org.eclipse.simrel.build 
m2e-wtp.b3aggrcon - org.eclipse.simrel.build 
m2e.b3aggrcon - org.eclipse.simrel.build 
m2m-atl.b3aggrcon - org.eclipse.simrel.build 
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build 
mat.b3aggrcon - org.eclipse.simrel.build 
mdt-modisco.b3aggrcon - org.eclipse.simrel.build 
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build 
mft.b3aggrcon - org.eclipse.simrel.build 
mmt-qvto.b3aggrcon - org.eclipse.simrel.build 
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build 
mylyn.b3aggrcon - org.eclipse.simrel.build 
objectteams.b3aggrcon - org.eclipse.simrel.build 
pdt.b3aggrcon - org.eclipse.simrel.build 
ptp.b3aggrcon - org.eclipse.simrel.build 
sapphire.b3aggrcon - org.eclipse.simrel.build 
sco

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Konstantin Komissarchik]

> 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 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.

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"  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 t

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Greg Watson]

I've enabled PTP now that CDT is enabled.
Regards,
Greg

On Aug 21, 2013, at 12:00 AM, David M Williams  
wrote:

> Doesn't look good. I'll admit there is one day left, but so far 50 projects 
> have not even enabled their "contribution" to Luna (pasted below). 
> 
> Thank you to the 20 of you who have. 
> 
> Remember, enable your contribution if you plan to participate (remove the 
> "enabled="false"), but disable your repository if you are simply waiting for 
> pre-reqs to get enabled or fixed (disable by adding enabled="false" to your 
> repository element(s)). 
> 
> Please ask if questions. (Or, please say if you have explicitly decided not 
> to participate in Luna). 
> 
> Thanks, 
> 
> = = = = = 
> 
> This list are those that have not yet enabled contribution: 
> 
> actf.b3aggrcon - org.eclipse.simrel.build 
> amalgam.b3aggrcon - org.eclipse.simrel.build 
> amp.b3aggrcon - org.eclipse.simrel.build 
> birt.b3aggrcon - org.eclipse.simrel.build 
> cdt.b3aggrcon - org.eclipse.simrel.build 
> dltk.b3aggrcon - org.eclipse.simrel.build 
> dtp.b3aggrcon - org.eclipse.simrel.build 
> ecf.b3aggrcon - org.eclipse.simrel.build 
> egit.b3aggrcon - org.eclipse.simrel.build 
> emf-cdo.b3aggrcon - org.eclipse.simrel.build 
> emf-compare.b3aggrcon - org.eclipse.simrel.build 
> emf-diffmerge.b3aggrcon - org.eclipse.simrel.build 
> emf-query.b3aggrcon - org.eclipse.simrel.build 
> emf-transaction.b3aggrcon - org.eclipse.simrel.build 
> emf-validation.b3aggrcon - org.eclipse.simrel.build 
> emft-ecoretools.b3aggrcon - org.eclipse.simrel.build 
> emft-eef.b3aggrcon - org.eclipse.simrel.build 
> emft-egf.b3aggrcon - org.eclipse.simrel.build 
> emft-emffacet.b3aggrcon - org.eclipse.simrel.build 
> epp-mpc.b3aggrcon - org.eclipse.simrel.build 
> gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build 
> gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build 
> gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build 
> gmp-graphiti.b3aggrcon - org.eclipse.simrel.build 
> jubula.b3aggrcon - org.eclipse.simrel.build 
> jwt.b3aggrcon - org.eclipse.simrel.build 
> koneki.b3aggrcon - org.eclipse.simrel.build 
> linuxtools.b3aggrcon - org.eclipse.simrel.build 
> m2e-wtp.b3aggrcon - org.eclipse.simrel.build 
> m2e.b3aggrcon - org.eclipse.simrel.build 
> m2m-atl.b3aggrcon - org.eclipse.simrel.build 
> m2t-acceleo.b3aggrcon - org.eclipse.simrel.build 
> mat.b3aggrcon - org.eclipse.simrel.build 
> mdt-modisco.b3aggrcon - org.eclipse.simrel.build 
> mdt-papyrus.b3aggrcon - org.eclipse.simrel.build 
> mft.b3aggrcon - org.eclipse.simrel.build 
> mmt-qvto.b3aggrcon - org.eclipse.simrel.build 
> mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build 
> mylyn.b3aggrcon - org.eclipse.simrel.build 
> objectteams.b3aggrcon - org.eclipse.simrel.build 
> pdt.b3aggrcon - org.eclipse.simrel.build 
> ptp.b3aggrcon - org.eclipse.simrel.build 
> sapphire.b3aggrcon - org.eclipse.simrel.build 
> scout-rap.b3aggrcon - org.eclipse.simrel.build 
> scout.b3aggrcon - org.eclipse.simrel.build 
> soa-bpel.b3aggrcon - org.eclipse.simrel.build 
> soa-sca.b3aggrcon - org.eclipse.simrel.build 
> tcf.b3aggrcon - org.eclipse.simrel.build 
> tm.b3aggrcon - org.eclipse.simrel.build 
> windowbuilder.b3aggrcon - org.eclipse.simrel.build 
> 
> ___
> 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

[Igor Fedorenko]

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.

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"  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
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 mailto: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@eclip

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Oberhuber, Martin]

I have "declared intent" for tcf-1.2 by enabling the contribution ... but will 
keep the repo disabled until the build is green.

The build has been failing since 11.01am server time today so I'm not sure if 
it's a good idea adding more contributions before it is green ... in the end, 
someone (David?) would need to disable culprits.

FWIW, when running the "validate aggregation" in the b3 model editor I get this 
error right now:

Cannot complete the install because one or more required items could not be 
found.
Missing requirement: Sapphire XML Editor Support (Incubation) 
0.7.0.201308211148 (org.eclipse.sapphire.ui.swt.xml.editor 0.7.0.201308211148) 
requires 'bundle org.eclipse.wst.sse.core [1.1.600,2.0.0)' but it could not be 
found

Bundle(org.eclipse.wst.sse.core [1.1.600,2.0.0)) is required by:
  ValidationSet(main)
Contribution(Sapphire)
  
MappedRepository(http://download.eclipse.org/sapphire/0.7.0.201308211148/repository)
Feature(org.eclipse.sapphire.ui.swt.xml.editor.feature.group 0.7.0)
  InstallableUnit(org.eclipse.sapphire.ui.swt.xml.editor 
0.7.0.201308211148)

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Wednesday, August 21, 2013 6:01 AM
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and outlook for Luna M1

Doesn't look good. I'll admit there is one day left, but so far 50 projects 
have not even enabled their "contribution" to Luna (pasted below).

Thank you to the 20 of you who have.

Remember, enable your contribution if you plan to participate (remove the 
"enabled="false"), but disable your repository if you are simply waiting for 
pre-reqs to get enabled or fixed (disable by adding enabled="false" to your 
repository element(s)).

Please ask if questions. (Or, please say if you have explicitly decided not to 
participate in Luna).

Thanks,

= = = = =

This list are those that have not yet enabled contribution:

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
emf-cdo.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
emf-query.b3aggrcon - org.eclipse.simrel.build
emf-transaction.b3aggrcon - org.eclipse.simrel.build
emf-validation.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jubula.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
linuxtools.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mmt-qvto.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
mylyn.b3aggrcon - org.eclipse.simrel.build
objectteams.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
ptp.b3aggrcon - org.eclipse.simrel.build
sapphire.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build
___
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] Status and outlook for Luna M1

[David Dykstal]

I have enabled TM.

Doug Schaefer wrote:

Sigh. RSE isn't enabled so CDT fails.


___
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

[Konstantin Komissarchik]

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"  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 
>>> 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 mailto: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
>>>
>>>
>>>
>>> ___
>>> 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/lis

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Fred Bricon]

I believe m2e-wtp fails because the webtools contribution is disabled.


On Wed, Aug 21, 2013 at 6:29 PM, Jeff Johnston  wrote:

>  With CDT enabled, I have enabled Linux Tools.
>
>
> On 08/21/2013 10:49 AM, Doug Schaefer wrote:
>
> I've re-enabled CDT. Sorry for wasting the time of the person who put
> enabled="false" into our file.
>
>  Doug.
>
>   From: Sergey Boyko 
> Reply-To: Cross project issues 
> Date: Wednesday, 21 August, 2013 10:18 AM
> To: Cross project issues 
> Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1
>
>   QVTo was re-enabled for Luna.
>
> Cheers...
>  Sergey
>
>
> On Wed, Aug 21, 2013 at 8:00 AM, David M Williams <
> david_willi...@us.ibm.com> wrote:
>
>> Doesn't look good. I'll admit there is one day left, but so far 50
>> projects have not even enabled their "contribution" to Luna (pasted below).
>>
>>
>
> ___
> cross-project-issues-dev mailing 
> listcross-project-issues-dev@eclipse.orghttps://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
>
>


-- 
"Have you tried turning it off and on again" - The IT Crowd
___
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] Status and outlook for Luna M1

[Jeff Johnston]

With CDT enabled, I have enabled Linux Tools.

On 08/21/2013 10:49 AM, Doug Schaefer wrote:
I've re-enabled CDT. Sorry for wasting the time of the person who put 
enabled="false" into our file.


Doug.

From: Sergey Boyko >
Reply-To: Cross project issues >

Date: Wednesday, 21 August, 2013 10:18 AM
To: Cross project issues >

Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

QVTo was re-enabled for Luna.

Cheers...
 Sergey


On Wed, Aug 21, 2013 at 8:00 AM, David M Williams 
mailto:david_willi...@us.ibm.com>> wrote:


Doesn't look good. I'll admit there is one day left, but so far 50
projects have not even enabled their "contribution" to Luna
(pasted below).



___
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] Disk usage report for Hudson/Build

[genie]

Compiled 2013-08-21T12:07

 build.eclipse.org 
-> Usage exceeding 1GB for: Hudson master jobs and workspace (2013-08-21T10:00)
  32.9G ep4-unit-lin64
   4.9G emf-emfclient-integration
   2.4G emf-emfclient-maintenance
   2.3G emf-core-maintenance
   2.2G emf-cdo-integration
   2.1G papyrus-trunk-nightly
   2.0G stardust-kepler
   2.0G scout-release
   1.9G stardust-7-nightly
   1.9G gef4-master
   1.9G platform-sonar
   1.7G scout-head-nightly
   1.5G papyrus-0.9-maintenance-nightly
   1.5G ptp-nightly-repo
   1.4G amp-integration
   1.4G jgit
   1.4G ptp-release-repo
   1.3G emf-emfstore-fuzzytests-explorer
   1.3G webtools-vjet-juno
   1.2G tycho-gmp.gmf.tooling
   1.2G Xtext-nightly-HEAD
   1.2G buckminster-voicetools-targetplatform
   1.2G mylyn-release
   1.2G mdt-sphinx-0.7-juno
   1.1G m2t-acceleo-master
   1.1G emf-core-head
   1.1G rap-head-runtime
   1.1G buckminster-egf-juno
   1.0G nattable-snapshot
   1.0G buckminster-egf-helios
-> Usage exceeding 1GB for: /shared (1000G capacity) (2013-08-21T10:00)
 151.9G technology
 139.5G jobs
 132.1G eclipse
  80.5G rt
  24.1G webtools
  20.1G SLES
  10.1G tools
   8.0G common
   7.1G cbi-ng
   5.8G simrel
   5.3G modeling
   3.8G hipp
   3.6G orbit
   1.6G mylyn
   1.4G soa
   1.3G cbi
-> Usage exceeding 1GB for: /shared/modeling
   3.1G build
-> Usage exceeding 1GB for: /shared/tools
   4.6G tm
   1.4G mtj
   1.3G objectteams
   1.3G windowbuilder
   1.1G aspectj
-> Usage exceeding 1GB for: /shared/technology
 130.6G epp
   6.9G sapphire
   4.8G stem
   3.8G babel
   2.4G cosmos
   1.1G m2e
 END: build.eclipse.org 


 hudson-slave1.eclipse.org 
/dev/xvda1158G  108G   50G  69% /
-> Usage exceeding 1GB for: Hudson workspace on hudson-slave1 (50G capacity) 
(2013-08-20T21:00)
   8.2G ptp-release-repo
   6.0G ptp-release-packages
   4.9G ptp-nightly-packages
   3.8G scout-release-legacy
   2.8G koneki-ldt
   2.6G koneki-ldt-maintenance
   2.3G mihini-nightly
   1.9G tycho-mat-nightly
   1.8G linuxtools-kepler
   1.8G cdt-nightly
   1.8G papyrus-0.8-EYY-maintenance
   1.7G tycho-its-linux-nightly
   1.7G scout-head-nightly
   1.5G cdt-maint
   1.5G cdt-legacy
   1.4G Xtext-nightly-Maintenance
   1.2G gef-master
   1.2G matt_linuxtools-test
   1.2G Xtext-nightly-HEAD
   1.2G emft-texo-nightly
   1.1G papyrus-trunk-extra-nightly-tests
   1.0G Xtext-integration-test
   1.0G cdt-nightly-3.8
 END: hudson-slave1.eclipse.org 


 hudson-slave2.eclipse.org 
-> Usage exceeding 1GB for: 
 END: hudson-slave2.eclipse.org 


 hudson-slave3.eclipse.org 
/dev/xvda1 55G   34G   22G  61% /
-> Usage exceeding 1GB for: Hudson workspace on hudson-slave3 (50G capacity) 
(2013-08-20T18:00)
   1.7G scout-stable-nightly
 END: hudson-slave3.eclipse.org 

___
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

[Ed Willink]

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"  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 

> 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 mailto: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




___
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

[Igor Fedorenko]

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"  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 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 mailto: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




___
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] Status and outlook for Luna M1

[Doug Schaefer]

Sigh. RSE isn't enabled so CDT fails.

From: Doug Schaefer mailto:dschae...@qnx.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, 21 August, 2013 10:49 AM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

I've re-enabled CDT. Sorry for wasting the time of the person who put 
enabled="false" into our file.

Doug.

From: Sergey Boyko mailto:serg.boyko2...@gmail.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, 21 August, 2013 10:18 AM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

QVTo was re-enabled for Luna.

Cheers...
 Sergey


On Wed, Aug 21, 2013 at 8:00 AM, David M Williams 
mailto:david_willi...@us.ibm.com>> wrote:
Doesn't look good. I'll admit there is one day left, but so far 50 projects 
have not even enabled their "contribution" to Luna (pasted below).

___
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] Status and outlook for Luna M1

[Doug Schaefer]

I've re-enabled CDT. Sorry for wasting the time of the person who put 
enabled="false" into our file.

Doug.

From: Sergey Boyko mailto:serg.boyko2...@gmail.com>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Wednesday, 21 August, 2013 10:18 AM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Status and outlook for Luna M1

QVTo was re-enabled for Luna.

Cheers...
 Sergey


On Wed, Aug 21, 2013 at 8:00 AM, David M Williams 
mailto:david_willi...@us.ibm.com>> wrote:
Doesn't look good. I'll admit there is one day left, but so far 50 projects 
have not even enabled their "contribution" to Luna (pasted below).

___
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] Status and outlook for Luna M1

[Sergey Boyko]

QVTo was re-enabled for Luna.

Cheers...
 Sergey


On Wed, Aug 21, 2013 at 8:00 AM, David M Williams  wrote:

> Doesn't look good. I'll admit there is one day left, but so far 50
> projects have not even enabled their "contribution" to Luna (pasted below).
>
>
___
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] Status and outlook for Luna M1

[Grégoire Dupé]

> EMF Validation was re-enabled this morning EST. 

Thanks !

I've delivered EMF Facet.

Regards,
Grégoire
___
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

[Doug Schaefer]

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"  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 > > 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 mailto: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
>>
>>
>>
>> ___
>> 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] Status and outlook for Luna M1

[Anthony Hunter]

EMF Validation was re-enabled this morning EST.

Cheers...
Anthony




From:   Grégoire Dupé 
To: Cross project issues 
Date:   2013/08/21 09:27 AM
Subject:Re: [cross-project-issues-dev] Status and outlook for Luna 
M1
Sent by:cross-project-issues-dev-boun...@eclipse.org



Hello,

I’m still not able to deliver EMF Facet and MoDisco because some 
dependences have not be re-enabled (at least org.eclipse.emf.validation).

Regards,
Grégoire
___
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] Status and outlook for Luna M1

[Tsvetkov, Krum]

Memory Analyzer is now also enabled.
We disabled our charts feature, as it depends on BIRT, which is not yet enabled.

I had troubles pushing (couldn't get through our corporate proxy).
Thanks to Matthias who made the changes instead of me.


From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Mittwoch, 21. August 2013 06:01
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and outlook for Luna M1

Doesn't look good. I'll admit there is one day left, but so far 50 projects 
have not even enabled their "contribution" to Luna (pasted below).

Thank you to the 20 of you who have.

Remember, enable your contribution if you plan to participate (remove the 
"enabled="false"), but disable your repository if you are simply waiting for 
pre-reqs to get enabled or fixed (disable by adding enabled="false" to your 
repository element(s)).

Please ask if questions. (Or, please say if you have explicitly decided not to 
participate in Luna).

Thanks,

= = = = =

This list are those that have not yet enabled contribution:

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
emf-cdo.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
emf-query.b3aggrcon - org.eclipse.simrel.build
emf-transaction.b3aggrcon - org.eclipse.simrel.build
emf-validation.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jubula.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
linuxtools.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mmt-qvto.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
mylyn.b3aggrcon - org.eclipse.simrel.build
objectteams.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
ptp.b3aggrcon - org.eclipse.simrel.build
sapphire.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build
___
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] Status and outlook for Luna M1

[Grégoire Dupé]

Hello,

I’m still not able to deliver EMF Facet and MoDisco because some dependences 
have not be re-enabled (at least org.eclipse.emf.validation).

Regards,
Grégoire
___
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] Status and outlook for Luna M1

[Matthias Sohn]

On Wed, Aug 21, 2013 at 9:52 AM, Steffen Pingel
wrote:

> I have enabled Mylyn now. It should be in the latest build which took only
> 8 minutes to complete (!).
>
> Steffen
>
> thanks, I reenabled the EGit features which are depending on Mylyn

--
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] how to state intent joining Luna SimRelease?

[Igor Vinnykov]

Hi all,

 

The "State intent early (M4)" chapter of the
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements page refers
to using the "Simultaneous Release Flag" in the project's Portal meta-data.
It seems to be out-of-date, because now there is no meta-data in Portal. It
will be great if somebody who know how to "state intent" can update Wiki
page to help persons like me who is lost in all these new settings. Thanks!

 

Best regards,

Igor Vinnykov

 

 

___
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

[Igor Fedorenko]

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 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 mailto: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




___
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] Status and outlook for Luna M1

[Igor Fedorenko]

On 2013-08-21 12:00 AM, David M Williams wrote:

Remember, enable your contribution if you plan to participate (remove
the "enabled="false"), but disable your repository if you are simply
waiting for pre-reqs to get enabled or fixed (disable by adding
enabled="false" to your repository element(s)).


What's the point of this? I still need to manually check aggregator to
see if my dependencies got enabled, so this appears to be an extra
(admittedly tiny) bit of work I need to do that does not add much/any
additional information.

--
Regards,
Igor
___
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] Status and outlook for Luna M1

[Stephan Herrmann]

Object Teams cannot be installed in M1 due to https://bugs.eclipse.org/253244
(which hits us after the rewrite of the equinox framework).
I will enable our contribution just for one aggregation run to see we're
able to contribute and disable it immediately after.

I'm hopeful that the bug can be settled with the p2 team in time for M2.

best,
Stephan


On 08/21/2013 06:00 AM, David M Williams wrote:

Doesn't look good. I'll admit there is one day left, but so far 50 projects have not even 
enabled their "contribution" to Luna
(pasted below).

Thank you to the 20 of you who have.

Remember, enable your contribution if you plan to participate (remove the 
"enabled="false"), but disable your repository if you are
simply waiting for pre-reqs to get enabled or fixed (disable by adding 
enabled="false" to your repository element(s)).

Please ask if questions. (Or, please say if you have explicitly decided not to 
participate in Luna).

Thanks,

= = = = =

This list are those that have not yet enabled contribution:

actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
birt.b3aggrcon - org.eclipse.simrel.build
cdt.b3aggrcon - org.eclipse.simrel.build
dltk.b3aggrcon - org.eclipse.simrel.build
dtp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
emf-cdo.b3aggrcon - org.eclipse.simrel.build
emf-compare.b3aggrcon - org.eclipse.simrel.build
emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
emf-query.b3aggrcon - org.eclipse.simrel.build
emf-transaction.b3aggrcon - org.eclipse.simrel.build
emf-validation.b3aggrcon - org.eclipse.simrel.build
emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
emft-emffacet.b3aggrcon - org.eclipse.simrel.build
epp-mpc.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
jubula.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
linuxtools.b3aggrcon - org.eclipse.simrel.build
m2e-wtp.b3aggrcon - org.eclipse.simrel.build
m2e.b3aggrcon - org.eclipse.simrel.build
m2m-atl.b3aggrcon - org.eclipse.simrel.build
m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
mdt-modisco.b3aggrcon - org.eclipse.simrel.build
mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
mmt-qvto.b3aggrcon - org.eclipse.simrel.build
mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
mylyn.b3aggrcon - org.eclipse.simrel.build
objectteams.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
ptp.b3aggrcon - org.eclipse.simrel.build
sapphire.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
scout.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build
tcf.b3aggrcon - org.eclipse.simrel.build
tm.b3aggrcon - org.eclipse.simrel.build
windowbuilder.b3aggrcon - org.eclipse.simrel.build



___
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] Pack200 Terror

[Eike Stepper]

Hi,

The Kepler aggregator keeps complaining like:

org.eclipse.osgi.signedcontent.InvalidContentException: The file "Xyz.class" in the jar 
"/tmp/signatureFile8275609294440704505.jar" has been tampered!


I've tried everything to fix it, e.g.:

1) Flattened the single nested jar
2) Retained the unconditioned jars in addition to the pack.gz files 
(-Dsite.retain.unpacked=true)
3) Used a JDK1.6 jarprocessor as recommended by David 
(-Dorg.eclipse.update.jarprocessor.pack200=/shared/common/jdk1.6.0-latest/bin)

4) Disabled conditioning in Buckminster altogether (-Dsite.pack200=false)

The status quo is that I have no nested jars and no pack.gz files. The aggregator still complains. Even about two jars 
that I've taken from Orbit (i.e. not built myself).


I've herad that some other projects have similar problems. Could this be caused by changes in the aggregator 
configuration? Or by changes in the signing process?


Need help!!!

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

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Eike Stepper]

Am 21.08.2013 10:19, schrieb David M Williams:

Really? Honestly? Or is it just too late at night for me to enjoy such jokes. 
Maybe I'll appreciate it in the morning. :)


I've just counted that our build consumes dependencies from 26 projects, with at least 26 different quality/naming 
strategies. Believe me, these things make me everything but joking. In the worst case it can happen that I specify wrong 
repo URLs. In the best case I need to change these URLs before and after each milestone build. I'm looking for a way to 
make this easier...


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper







From: Eike Stepper 
To: cross-project-issues-dev@eclipse.org,
Date: 08/21/2013 04:16 AM
Subject: Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository
Sent by: cross-project-issues-dev-boun...@eclipse.org




Am 21.08.2013 09:57, schrieb David M Williams:

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.


I thought the aggregation produces a "staging" repo which is composed into the 
regular train repo after a milestone has
been declared successful. That means I wouldn't exactly build against and for 
the same repo, right?

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



___
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

[David M Williams]

Really? Honestly? Or is it just too late at night for me to enjoy such 
jokes. Maybe I'll appreciate it in the morning. :) 



From:   Eike Stepper 
To: cross-project-issues-dev@eclipse.org, 
Date:   08/21/2013 04:16 AM
Subject:Re: [cross-project-issues-dev] Pre-M1 Aggregation 
Repository
Sent by:cross-project-issues-dev-boun...@eclipse.org



Am 21.08.2013 09:57, schrieb David M Williams:
> 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.

I thought the aggregation produces a "staging" repo which is composed into 
the regular train repo after a milestone has 
been declared successful. That means I wouldn't exactly build against and 
for the same repo, right?

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

[Eike Stepper]

Am 21.08.2013 09:57, schrieb David M Williams:

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.


I thought the aggregation produces a "staging" repo which is composed into the regular train repo after a milestone has 
been declared successful. That means I wouldn't exactly build against and for the same repo, right?


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

Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

[Marcel Bruch]

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  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  
> 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

___
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

[David M Williams]

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 
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] Status and outlook for Luna M1

[Steffen Pingel]

I have enabled Mylyn now. It should be in the latest build which took only
8 minutes to complete (!).

Steffen


On Wed, Aug 21, 2013 at 9:13 AM, Matthias Sohn wrote:

> On Wed, Aug 21, 2013 at 6:00 AM, David M Williams <
> david_willi...@us.ibm.com> wrote:
>
>> Doesn't look good. I'll admit there is one day left, but so far 50
>> projects have not even enabled their "contribution" to Luna (pasted below).
>>
>> Thank you to the 20 of you who have.
>>
>> Remember, enable your contribution if you plan to participate (remove the
>> "enabled="false"), but disable your repository if you are simply waiting
>> for pre-reqs to get enabled or fixed (disable by adding enabled="false" to
>> your repository element(s)).
>>
>> Please ask if questions. (Or, please say if you have explicitly decided
>> not to participate in Luna).
>>
>> Thanks,
>>
>> = = = = =
>>
>> This list are those that have not yet enabled contribution:
>>
>> actf.b3aggrcon - org.eclipse.simrel.build
>> amalgam.b3aggrcon - org.eclipse.simrel.build
>> amp.b3aggrcon - org.eclipse.simrel.build
>> birt.b3aggrcon - org.eclipse.simrel.build
>> cdt.b3aggrcon - org.eclipse.simrel.build
>> dltk.b3aggrcon - org.eclipse.simrel.build
>> dtp.b3aggrcon - org.eclipse.simrel.build
>> ecf.b3aggrcon - org.eclipse.simrel.build
>> egit.b3aggrcon - org.eclipse.simrel.build
>> emf-cdo.b3aggrcon - org.eclipse.simrel.build
>> emf-compare.b3aggrcon - org.eclipse.simrel.build
>> emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
>> emf-query.b3aggrcon - org.eclipse.simrel.build
>> emf-transaction.b3aggrcon - org.eclipse.simrel.build
>> emf-validation.b3aggrcon - org.eclipse.simrel.build
>> emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
>> emft-eef.b3aggrcon - org.eclipse.simrel.build
>> emft-egf.b3aggrcon - org.eclipse.simrel.build
>> emft-emffacet.b3aggrcon - org.eclipse.simrel.build
>> epp-mpc.b3aggrcon - org.eclipse.simrel.build
>> gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
>> gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
>> gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
>> gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
>> jubula.b3aggrcon - org.eclipse.simrel.build
>> jwt.b3aggrcon - org.eclipse.simrel.build
>> koneki.b3aggrcon - org.eclipse.simrel.build
>> linuxtools.b3aggrcon - org.eclipse.simrel.build
>> m2e-wtp.b3aggrcon - org.eclipse.simrel.build
>> m2e.b3aggrcon - org.eclipse.simrel.build
>> m2m-atl.b3aggrcon - org.eclipse.simrel.build
>> m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
>> mat.b3aggrcon - org.eclipse.simrel.build
>> mdt-modisco.b3aggrcon - org.eclipse.simrel.build
>> mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
>> mft.b3aggrcon - org.eclipse.simrel.build
>> mmt-qvto.b3aggrcon - org.eclipse.simrel.build
>> mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
>> mylyn.b3aggrcon - org.eclipse.simrel.build
>> objectteams.b3aggrcon - org.eclipse.simrel.build
>> pdt.b3aggrcon - org.eclipse.simrel.build
>> ptp.b3aggrcon - org.eclipse.simrel.build
>> sapphire.b3aggrcon - org.eclipse.simrel.build
>> scout-rap.b3aggrcon - org.eclipse.simrel.build
>> scout.b3aggrcon - org.eclipse.simrel.build
>> soa-bpel.b3aggrcon - org.eclipse.simrel.build
>> soa-sca.b3aggrcon - org.eclipse.simrel.build
>> tcf.b3aggrcon - org.eclipse.simrel.build
>> tm.b3aggrcon - org.eclipse.simrel.build
>> windowbuilder.b3aggrcon - org.eclipse.simrel.build
>>
>
> I have enabled the EGit contribution though I had to disable the EGit
> Mylyn integration
> and the EGit GitHub connector contribution since Mylyn isn't yet in.
>
> --
> Matthias
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>


-- 
Steffen Pingel
Principal Software Engineer, Eclipse Mylyn
Mylyn Tasks Lead
http://tasktop.com
___
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] Pre-M1 Aggregation Repository

[Eike Stepper]

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

Re: [cross-project-issues-dev] Status and outlook for Luna M1

[Matthias Sohn]

On Wed, Aug 21, 2013 at 6:00 AM, David M Williams  wrote:

> Doesn't look good. I'll admit there is one day left, but so far 50
> projects have not even enabled their "contribution" to Luna (pasted below).
>
> Thank you to the 20 of you who have.
>
> Remember, enable your contribution if you plan to participate (remove the
> "enabled="false"), but disable your repository if you are simply waiting
> for pre-reqs to get enabled or fixed (disable by adding enabled="false" to
> your repository element(s)).
>
> Please ask if questions. (Or, please say if you have explicitly decided
> not to participate in Luna).
>
> Thanks,
>
> = = = = =
>
> This list are those that have not yet enabled contribution:
>
> actf.b3aggrcon - org.eclipse.simrel.build
> amalgam.b3aggrcon - org.eclipse.simrel.build
> amp.b3aggrcon - org.eclipse.simrel.build
> birt.b3aggrcon - org.eclipse.simrel.build
> cdt.b3aggrcon - org.eclipse.simrel.build
> dltk.b3aggrcon - org.eclipse.simrel.build
> dtp.b3aggrcon - org.eclipse.simrel.build
> ecf.b3aggrcon - org.eclipse.simrel.build
> egit.b3aggrcon - org.eclipse.simrel.build
> emf-cdo.b3aggrcon - org.eclipse.simrel.build
> emf-compare.b3aggrcon - org.eclipse.simrel.build
> emf-diffmerge.b3aggrcon - org.eclipse.simrel.build
> emf-query.b3aggrcon - org.eclipse.simrel.build
> emf-transaction.b3aggrcon - org.eclipse.simrel.build
> emf-validation.b3aggrcon - org.eclipse.simrel.build
> emft-ecoretools.b3aggrcon - org.eclipse.simrel.build
> emft-eef.b3aggrcon - org.eclipse.simrel.build
> emft-egf.b3aggrcon - org.eclipse.simrel.build
> emft-emffacet.b3aggrcon - org.eclipse.simrel.build
> epp-mpc.b3aggrcon - org.eclipse.simrel.build
> gmp-gmf-notation.b3aggrcon - org.eclipse.simrel.build
> gmp-gmf-runtime.b3aggrcon - org.eclipse.simrel.build
> gmp-gmf-tooling.b3aggrcon - org.eclipse.simrel.build
> gmp-graphiti.b3aggrcon - org.eclipse.simrel.build
> jubula.b3aggrcon - org.eclipse.simrel.build
> jwt.b3aggrcon - org.eclipse.simrel.build
> koneki.b3aggrcon - org.eclipse.simrel.build
> linuxtools.b3aggrcon - org.eclipse.simrel.build
> m2e-wtp.b3aggrcon - org.eclipse.simrel.build
> m2e.b3aggrcon - org.eclipse.simrel.build
> m2m-atl.b3aggrcon - org.eclipse.simrel.build
> m2t-acceleo.b3aggrcon - org.eclipse.simrel.build
> mat.b3aggrcon - org.eclipse.simrel.build
> mdt-modisco.b3aggrcon - org.eclipse.simrel.build
> mdt-papyrus.b3aggrcon - org.eclipse.simrel.build
> mft.b3aggrcon - org.eclipse.simrel.build
> mmt-qvto.b3aggrcon - org.eclipse.simrel.build
> mylyn-docs-intent.b3aggrcon - org.eclipse.simrel.build
> mylyn.b3aggrcon - org.eclipse.simrel.build
> objectteams.b3aggrcon - org.eclipse.simrel.build
> pdt.b3aggrcon - org.eclipse.simrel.build
> ptp.b3aggrcon - org.eclipse.simrel.build
> sapphire.b3aggrcon - org.eclipse.simrel.build
> scout-rap.b3aggrcon - org.eclipse.simrel.build
> scout.b3aggrcon - org.eclipse.simrel.build
> soa-bpel.b3aggrcon - org.eclipse.simrel.build
> soa-sca.b3aggrcon - org.eclipse.simrel.build
> tcf.b3aggrcon - org.eclipse.simrel.build
> tm.b3aggrcon - org.eclipse.simrel.build
> windowbuilder.b3aggrcon - org.eclipse.simrel.build
>

I have enabled the EGit contribution though I had to disable the EGit Mylyn
integration
and the EGit GitHub connector contribution since Mylyn isn't yet in.

--
Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev