[cross-project-issues-dev] Luna M1 Staging repo is complete

2013-08-22 Thread David M Williams 
I will re-enable the aggregation job on Friday afternoon. 

Thanks to those of you who are participating in a coordinated fashion. 




From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   08/22/2013 03:53 PM
Subject:[cross-project-issues-dev] Status and Outlook for Luna M1 
-- last call ...
Sent by:cross-project-issues-dev-boun...@eclipse.org



The "rate of contributions" appears to have crawled to a halt for Luna M1. 
All but 20 have enabled their contributions. Most of the other 50 are 
"fully enabled" (all but 8, which have some disabled feature or 
repository). 

I will wait until 5 PM Eastern to declare "staging repo done" if no one 
ask for more time. 

Not sure what magic Markus can do with EPP packages with what's enabled 
but, but I know at least "Eclipse Standard" should build :) 

Just wanted to let you know one last change to try to join in now before 
we close out M1. 

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

2013-08-22 Thread David M Williams 
The "rate of contributions" appears to have crawled to a halt for Luna M1. 
All but 20 have enabled their contributions. Most of the other 50 are 
"fully enabled" (all but 8, which have some disabled feature or 
repository). 

I will wait until 5 PM Eastern to declare "staging repo done" if no one 
ask for more time. 

Not sure what magic Markus can do with EPP packages with what's enabled 
but, but I know at least "Eclipse Standard" should build :) 

Just wanted to let you know one last change to try to join in now before 
we close out M1. 

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

2013-08-22 Thread Grégoire Dupé 
Hello

I'm still waiting for Acceleo and ATL (may be more) to deliver MoDisco.

It's quite late in Europe; I've to leave the office.

I assume that MoDisco will not be included in Luna M1 :-(

Regards,
Grégoire

- Original Message -
From: "David M Williams" 
To: cross-project-issues-dev@eclipse.org
Sent: Jeudi 22 Août 2013 10:13:05
Subject: [cross-project-issues-dev] Status and Outlook for Luna M1


Ok, it's Thursday morning :) 

Only a few more have been enabled, but that includes DTP and BIRT, so that 
should help Luna (Kepler RC1 repo is already considered done). 

That allowed me to enabled the "JPA" portions of WTP (since depends on 
DataTools) which, I noticed, some others depended on, 
but I had to leave WTPs "JPA Diagram Editor" disabled, since it depends on 
Graphiti, which is not enabled yet. 

Which brings me to my main point. Scanning the list of 22 disabled 
contributions, I'd guess about half are "leaf" components, so if you don't get 
enabled, it'd hurt no one but your self ... and maybe community and adopters? 
But, I'd guess, the other half such as "graphiti", "gmf"? a few emf ones? and 
DLTK are definitely "building blocks" that need to be enabled or else others 
downstream can not function or be enabled. If you are a "consuming" project and 
need some of those lower level ones enabled, I'd encourage a lot of 
"project-to-project" communication so they know how much you depend on them, 
and the effect they have by being "late" or incomplete, etc. 

So, I'm just asking everyone to be aware of your place in the eco system and 
plan accordingly. I suspect I'm just stating the obvious ... but not sure what 
else I can do to help. 

Thanks, 

= = = = = = = = = 


actf.b3aggrcon - org.eclipse.simrel.build 
amalgam.b3aggrcon - org.eclipse.simrel.build 
amp.b3aggrcon - org.eclipse.simrel.build 
dltk.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 
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 
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 

___
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

2013-08-22 Thread Matthias Sohn 
On Thu, Aug 22, 2013 at 10:13 AM, David M Williams <
david_willi...@us.ibm.com> wrote:

> Ok, it's Thursday morning :)
>
> Only a few more have been enabled, but that includes DTP and BIRT, so that
> should help Luna (Kepler RC1 repo is already considered done).
>
> That allowed me to enabled the "JPA" portions of WTP (since depends on
> DataTools) which, I noticed, some others depended on,
> but I had to leave WTPs "JPA Diagram Editor" disabled, since it depends on
> Graphiti, which is not enabled yet.


Michael Wenz (Graphiti lead) is in vacation until next Monday. I guess
that's the reason
why Graphiti isn't yet enabled.

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

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

2013-08-22 Thread Igor Fedorenko 

If we decide to go though route, I recommend using .target file shared
via a maven repository, not a parent pom.

--
Regards,
Igor

On 2013-08-21 5:48 PM, Doug Schaefer wrote:

Not really. It's all in the timing. This gives you the chance to build
against newer bit from those projects, the same bits they'll be
contributing to the next simrel build. And you don't need a pre-existing
simrel build which is what started this thread.

Sent from my BlackBerry 10 smartphone on the Rogers network.
*From: *Konstantin Komissarchik
*Sent: *Wednesday, August 21, 2013 5:16 PM
*To: *'Cross project issues'
*Reply To: *Cross project issues
*Subject: *Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository


That sounds identical in effect to building against simrel repo, with
all the same issues.

*From:*cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of
*Doug Schaefer
*Sent:* Wednesday, August 21, 2013 2:14 PM
*To:* cross-project-issues-dev@eclipse.org; 'Cross project issues'
*Subject:* Re: [cross-project-issues-dev] Pre-M1 Aggregation Repository

Another option would be to create a top level pom that has all the
dependent repos that feed into the aggregate and you can use that for
your builds.

Sent from my BlackBerry 10 smartphone on the Rogers network.

*From: *Konstantin Komissarchik

*Sent: *Wednesday, August 21, 2013 4:33 PM

*To: *'Cross project issues'

*Reply To: *Cross project issues

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

There are different issues at play...

1. Reproducible builds. This can be accomplished by either referencing a
numbered build URL from a dependency or a numbered build URL from the
aggregation (if such thing was available).

2. Controlling the scope of components that project build sees. Building
against simrel repo risks accidentally taking a dependency on a project you
didn't intend to take a dependency on.

- Konstantin


-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org

[mailto:cross-project-issues-dev-boun...@eclipse.org] 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

[cross-project-issues-dev] Status and Outlook for Luna M1

2013-08-22 Thread David M Williams 
Ok, it's Thursday morning :) 

Only a few more have been enabled, but that includes DTP and BIRT, so that 
should help Luna (Kepler RC1 repo is already considered done). 

That allowed me to enabled the "JPA" portions of WTP (since depends on 
DataTools) which, I noticed, some others depended on, 
but I had to leave WTPs "JPA Diagram Editor" disabled, since it depends on 
Graphiti, which is not enabled yet. 

Which brings me to my main point. Scanning the list of 22 disabled 
contributions, I'd guess about half are "leaf" components, so if you don't 
get enabled, it'd hurt no one but your self ... and maybe community and 
adopters? But, I'd guess, the other half such as "graphiti", "gmf"? a few 
emf ones? and DLTK are definitely "building blocks" that need to be 
enabled or else others downstream can not function or be enabled. If you 
are a "consuming" project and need some of those lower level ones enabled, 
I'd encourage a lot of "project-to-project" communication so they know how 
much you depend on them, and the effect they have by being "late" or 
incomplete, etc. 

So, I'm just asking everyone to be aware of your place in the eco system 
and plan accordingly. I suspect I'm just stating the obvious ... but not 
sure what else I can do to help. 

Thanks, 

= = = = = = = = =


actf.b3aggrcon - org.eclipse.simrel.build
amalgam.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
dltk.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
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
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
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev