from:"Campo, Christian"

[cross-project-issues-dev] Riena (+3) participation in Luna

2013-12-12 Thread Campo, Christian

Riena 6.0 will be participating in the Luna release train. The offset of Riena 
is +3 (same as in the past).

Riena 6.0 runs on Eclipse 3.x, Eclipse 4.x and on RAP 2.3. Same as for 5.0 the 
cool is maintain that ability, fix bugs where they are coming and stabilize the 
platform. For 5.0SR1 we had to remove all dependencies to Nebula. We are hoping 
to include them back in again, once Nebula has its components in the Release 
train.

You find our current project plan at 
https://projects.eclipse.org/projects/rt.riena/releases/6.0.0

Feel free to supply feedback in the developer forum 
http://www.eclipse.org/forums/index.php?t=thread&frm_id=35

Christian Campo

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Reminder M2 closes tomorrow, Wednesday 10/2, approximately 5 PM

2013-10-01 Thread Campo, Christian

Riena is planing to participate in Luna. However we are not ready to contribute 
to M2. I post our plan for the next release next week.

sorry
christian

Von: "David com>" mailto:david_willi...@us.ibm.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 1. Oktober 2013 16:14
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: [cross-project-issues-dev] Reminder M2 closes tomorrow, Wednesday 
10/2, approximately 5 PM

Please join if you are able.
The following projects still have disabled contributions elements:

actf.b3aggrcon - org.eclipse.simrel.build
amp.b3aggrcon - org.eclipse.simrel.build
ecf.b3aggrcon - org.eclipse.simrel.build
emft-eef.b3aggrcon - org.eclipse.simrel.build
emft-egf.b3aggrcon - org.eclipse.simrel.build
jwt.b3aggrcon - org.eclipse.simrel.build
koneki.b3aggrcon - org.eclipse.simrel.build
mft.b3aggrcon - org.eclipse.simrel.build
pdt.b3aggrcon - org.eclipse.simrel.build
scout-rap.b3aggrcon - org.eclipse.simrel.build
soa-bpel.b3aggrcon - org.eclipse.simrel.build
soa-sca.b3aggrcon - org.eclipse.simrel.build

And the following have disabled repositories or features:

dltk.b3aggrcon - org.eclipse.simrel.build
egit.b3aggrcon - org.eclipse.simrel.build
mat.b3aggrcon - org.eclipse.simrel.build
riena.b3aggrcon - org.eclipse.simrel.build
stardust.b3aggrcon - org.eclipse.simrel.build

I've been seeing a lot of contributions in last day or two. Thanks! (to all you 
actively participating projects).


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] How to have dependencies on an Eclipse project (NatTable) which is not in the release train?

2013-07-31 Thread Campo, Christian

About that "you can redistribute parts of Nebula". Riena is also
redistributing parts of Nebula which led you bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=411977 which might be
worthwhile checking for you, although its about Grid and a little about
CompositeTable.

Nebula is currently discussing a release as I understand Wim's comment on
the bugŠ.

Make sure you communicate with the leader of the Nebula project (Tom and
Wim) before you include any of their pluginsŠ.

christian

Am 31.07.13 12:27 schrieb "Eike Stepper" unter :

>Am 31.07.2013 11:46, schrieb LORENZO Vincent:
>> Hi,
>>
>> The Papyrus team is working on a new Eclipse NatTable integration,
>>so we have several Papyrus plugins that we would
>> like to distribute in Papyrus.
>>
>> Unfortunately, NatTable is not in the release train, so we don¹t know
>>how to proceed.  Currently, if we add these
>> plugins to Papyrus, we will break the simrel buildŠ
>
>You can add the needed plugins to your feature.xml and thereby
>redistribute parts of Nebula.
>
>> Could we add the NatTable update site to the Papyrus contribution in
>>the simrel file ? Do we need to create a CQ for that?
>
>Only the Nebula team can decide to participate in the release train as a
>project.
>
>Cheers
>/Eike
>
>
>http://www.esc-net.de
>http://thegordian.blogspot.com
>http://twitter.com/eikestepper
>
>
>>
>> Additional question :
>>
>>  Could we add these new plugins in papyrus for Kepler
>>SR1?
>>
>> Best regards,
>>
>> --
>>
>> Vincent Lorenzo
>>
>> 01-69-08-17-24
>>
>> CEA Saclay Nano-INNOV
>>
>> Institut CARNOT CEA LIST
>>
>> DILS/LISE
>>
>> Point Courrier n° 174
>>
>> 91 191 Gif sur Yvette CEDEX
>>
>>
>>
>> ___
>> 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



-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main 
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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] Are too many packages actually hurting Eclipse?

2013-07-30 Thread Campo, Christian

I admit that I didnt look much in the Kepler repo if there was a feature for 
me. My fear was that there is no single feature that includes everything that 
is in the JavaEE Eclipse IDE. And I didnt really know or took the time to look 
where I could possibly find it.

If I look at the Kepler repo now in software install (after it took 30 seconds 
to download the metadata) now its still tricky to know what would get me 
everything for J2EE.

I think my point is that a download of 245 MB where I have some confidence that 
I am all set is easier than digging through a large repo with many features

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Pascal 
Rapicault
Gesendet: Dienstag, 30. Juli 2013 16:57
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

Out of curiosity, what were the blocking factors that prevented you to download 
WTP in your existing install? My thinking is that if someone as immersed as you 
with the Eclipse ecosystem can't figure this out, then there may be something 
there as well.

On 07/30/2013 04:49 PM, Campo, Christian wrote:
The answer is simple. I downloaded 2 IDEs because currently there is NO 
Ultimate Its NOT that I prefer 2 IDE installations

But your point about a bloated UI is worthwhile thinking about really. Its in 
the same direction of Doug's and Martin's comment. About either controlling the 
UI bloat or being able to switch from J2EE to RCP to WTP in the same IDE 
without installing something new

Von: Mickael Istria mailto:mist...@redhat.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 16:38
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 04:19 PM, Campo, Christian wrote:

Maybe its also because I do a lot of RCP development and always download the 
RCP packages for the Eclipse IDE. Recently I decided to do some WTP stuff for 
myself. And the easiest way for me was to download a WTP Eclipse IDE. So maybe 
you can say that I could have downloaded some features from the Kepler repo. 
But I wasnt sure what was necessary so I downloaded a new IDE. (Felt strange, 
but worked)

So after that I thought, maybe I would preferred an IDE that can do "everything 
java" aka "ultimate"...

You usage of the IDE seems to show that even if you know it's possible to have 
everything in the same IDE, you prefered to download a second IDE and have an 
IDE for RCP and an IDE for Web applications development.
Your use-case seems opposed to what you're advocating for, so I'm curious: If 
you did not find the value of creating a "utilmate IDE" and prefered multiple 
IDEs, why do you think a "Ultimate" IDE would be better.

Here is my story to advocate against a "Ultimate IDE": I used to have much 
stuff in the same IDE for a few monthes, it contained my work stuff (mainly 
RCP) and some entertainment stuff (WTP, JBoss Tools and Android Dev Tools). My 
work tools and entertainment activities are not related at all. One day, I got 
angry of having too much stuff in that IDE and I spitted it because I used to 
get bugs coming from Android Tools when doing some RCP work, and WTP was doing 
some extra validation which was time consuming and because I was upset by many 
menus that are irrelevant; and the other way round, I got a lot of irrelevant 
noise and UI elements coming from PDE when doing to Web/Android development. 
Since them, I'm much happier in both of these activity-centric IDEs.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat<http://www.jboss.org/tools>
My blog<http://mickaelistria.wordpress.com> - My 
Tweets<http://twitter.com/mickaelistria>
-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-



___

cross-project-issues-dev mailing list

cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

2013-07-30 Thread Campo, Christian

The answer is simple. I downloaded 2 IDEs because currently there is NO 
Ultimate…. Its NOT that I prefer 2 IDE installations

But your point about a bloated UI is worthwhile thinking about really. Its in 
the same direction of Doug's and Martin's comment. About either controlling the 
UI bloat or being able to switch from J2EE to RCP to WTP in the same IDE 
without installing something new….

Von: Mickael Istria mailto:mist...@redhat.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 16:38
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 04:19 PM, Campo, Christian wrote:

Maybe its also because I do a lot of RCP development and always download the 
RCP packages for the Eclipse IDE. Recently I decided to do some WTP stuff for 
myself. And the easiest way for me was to download a WTP Eclipse IDE. So maybe 
you can say that I could have downloaded some features from the Kepler repo. 
But I wasnt sure what was necessary so I downloaded a new IDE. (Felt strange, 
but worked)

So after that I thought, maybe I would preferred an IDE that can do „everything 
java“ aka „ultimate“...

You usage of the IDE seems to show that even if you know it's possible to have 
everything in the same IDE, you prefered to download a second IDE and have an 
IDE for RCP and an IDE for Web applications development.
Your use-case seems opposed to what you're advocating for, so I'm curious: If 
you did not find the value of creating a "utilmate IDE" and prefered multiple 
IDEs, why do you think a "Ultimate" IDE would be better.

Here is my story to advocate against a "Ultimate IDE": I used to have much 
stuff in the same IDE for a few monthes, it contained my work stuff (mainly 
RCP) and some entertainment stuff (WTP, JBoss Tools and Android Dev Tools). My 
work tools and entertainment activities are not related at all. One day, I got 
angry of having too much stuff in that IDE and I spitted it because I used to 
get bugs coming from Android Tools when doing some RCP work, and WTP was doing 
some extra validation which was time consuming and because I was upset by many 
menus that are irrelevant; and the other way round, I got a lot of irrelevant 
noise and UI elements coming from PDE when doing to Web/Android development. 
Since them, I'm much happier in both of these activity-centric IDEs.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat<http://www.jboss.org/tools>
My blog<http://mickaelistria.wordpress.com> - My 
Tweets<http://twitter.com/mickaelistria>

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Are too many packages actually hurting Eclipse?

2013-07-30 Thread Campo, Christian

As an alternative we could replace "Standard" with an "Ultimate Java" Edition 
(including J2EE, WTP, RCP, Modeling)  and see what the download numbers are 
next year.

See I totally agree that are places where you want to specialize. My only 
problem that we are discussing this among ~ 1000 eclipse committers here and we 
have around 2 mio downloads.

Maybe its also because I do a lot of RCP development and always download the 
RCP packages for the Eclipse IDE. Recently I decided to do some WTP stuff for 
myself. And the easiest way for me was to download a WTP Eclipse IDE. So maybe 
you can say that I could have downloaded some features from the Kepler repo. 
But I wasnt sure what was necessary so I downloaded a new IDE. (Felt strange, 
but worked)

So after that I thought, maybe I would preferred an IDE that can do "everything 
java" aka "ultimate"...

christian

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Mickael 
Istria
Gesendet: Dienstag, 30. Juli 2013 16:12
An: cross-project-issues-dev@eclipse.org
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 03:57 PM, Igor Fedorenko wrote:
Are you suggesting forcing webtools on all java developers? Seriously?
I've just had a new look at the Eclipse community survey and since about 45% 
(~=100% - web dev perventage - RCP percentage - non-Java users percentage) of 
Java users are doing something else that Web or Plugin development, it seems 
indeed that a Java package without WTP makes sense.
The use cases are people doing some server side stuff and plugins for various 
non-web applications (Maven, Jenkins, Ant...).

So I'm changing my mind and now agree that two distinct "Java" and "Java for 
Web development" package would still make sense. However I still keep thinking 
that "Eclipse Standard" doesn't help much.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My 
Tweets

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Are too many packages actually hurting Eclipse?

2013-07-30 Thread Campo, Christian

Thats what I am told that "Ultimate" is everything. You can probably still 
install more, and IntelliJ does not do C/C++ or other languages (I believe).

So what we only had Java and C++ as the Prime Packages and then have 
specialized Packages less prominent lower on the bottom of that page ?

Just assuming that a Java developer wants to do J2ee, RCP, Webtools, Modeling 
and reporting….

I think its also something that changed over time. Today I can download 300 MB 
in no time and if my IDE sucks up half a GB of diskspace so what. If I dont 
need to worry again that I am missing something that I need to install while I 
am offline, I might go for that.

And seriously what again is "Standard" vs Java vs Java EE ?

Von: Pascal Rapicault 
mailto:pascal.rapica...@ericsson.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 15:15
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

Are you sure that “Ultimate” actually means everything? To me the difference is 
free vs non free.

I think the problem of today’s download page is that it forces you to ask 
yourself too many questions. I’m primarily a Java developer so if there was no 
other choice I would naturally download the Java IDE. However today the dl page 
gets me wondering about whether I’m a Tester, Modeler, a shoe maker, etc... 
which diminishes my sense of having downloaded the right package 
(http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less) because 
in the end the value that I find in those is minimal when my primary role is 
Java dev.


From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
Christian
Sent: July-30-13 8:56 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

I am not sure about the disaster thing really. As we are also having the 
discussion about other IDE's look at IntelliJ just for a second 
(http://www.jetbrains.com/idea/download/index.html)

They have 2 downloads. One that is free and one that is everything.

That makes it at least very simple for users of the IDE. Even if you dont agree 
on that, 90 % of the downloads are from 4 pre-packed IDEs for Eclipse.

How about an "Ultimate" edition for Eclipse. Why do I have to make a choice 
whether I want to develop J2EE, Modelling or RCP or be a Tester ? We all know 
that you can do multiple things with one IDE at the same time. The download 
page makes us think we have to make a choice.

Von: Pascal Rapicault mailto:pas...@rapicault.net>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 14:05
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

An all in one IDE is a recipe for disaster and will contribute to even more FUD 
around Eclipse.
Also I fail to see which improvements to the user experience can be done since 
we would not have a specific persona to focus on.
Instead I think we should focus on improving the integrations between the tools 
that are known to be installed together (yes ideally we would need user input 
on this). IMO this will have a better chance of success since it is much more 
focused and would also involve less ppl.


On 07/30/2013 12:13 PM, Konstantin Komissarchik wrote:
> so they are actually useful to end-users.

Actually, we have no evidence that users find packages useful. They download 
them because what else is there for them to do. Then if they are experienced, 
they know what’s included and how to install the missing pieces. If not, they 
thrash on forums wondering why Eclipse for Java Developers doesn’t come with an 
XML editor.

We can certainly measure the value of maintaining a menagerie of packages. All 
it would take is to put out an everything package alongside the existing ones 
and compare download numbers.

While it wouldn’t happen overnight, a single Eclipse IDE would have a unifying 
effect on the community, ultimately leading, I believe, to higher overall 
quality.

- Konstantin



From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Tuesday, July 30, 2013 2:46 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 12:35 AM, Konstantin Komissarchik wrote:

Would user experience be better if there was only one Eclipse package on the 
main download site that had pretty much everything that’s in the aggregated 
rep

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

2013-07-30 Thread Campo, Christian

I am not sure about the disaster thing really. As we are also having the 
discussion about other IDE's look at IntelliJ just for a second 
(http://www.jetbrains.com/idea/download/index.html)

They have 2 downloads. One that is free and one that is everything.

That makes it at least very simple for users of the IDE. Even if you dont agree 
on that, 90 % of the downloads are from 4 pre-packed IDEs for Eclipse.

How about an "Ultimate" edition for Eclipse. Why do I have to make a choice 
whether I want to develop J2EE, Modelling or RCP or be a Tester ? We all know 
that you can do multiple things with one IDE at the same time. The download 
page makes us think we have to make a choice.

Von: Pascal Rapicault mailto:pas...@rapicault.net>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Dienstag, 30. Juli 2013 14:05
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

An all in one IDE is a recipe for disaster and will contribute to even more FUD 
around Eclipse.
Also I fail to see which improvements to the user experience can be done since 
we would not have a specific persona to focus on.
Instead I think we should focus on improving the integrations between the tools 
that are known to be installed together (yes ideally we would need user input 
on this). IMO this will have a better chance of success since it is much more 
focused and would also involve less ppl.


On 07/30/2013 12:13 PM, Konstantin Komissarchik wrote:
> so they are actually useful to end-users.

Actually, we have no evidence that users find packages useful. They download 
them because what else is there for them to do. Then if they are experienced, 
they know what’s included and how to install the missing pieces. If not, they 
thrash on forums wondering why Eclipse for Java Developers doesn’t come with an 
XML editor.

We can certainly measure the value of maintaining a menagerie of packages. All 
it would take is to put out an everything package alongside the existing ones 
and compare download numbers.

While it wouldn’t happen overnight, a single Eclipse IDE would have a unifying 
effect on the community, ultimately leading, I believe, to higher overall 
quality.

- Konstantin



From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Mickael 
Istria
Sent: Tuesday, July 30, 2013 2:46 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting 
Eclipse?

On 07/30/2013 12:35 AM, Konstantin Komissarchik wrote:

Would user experience be better if there was only one Eclipse package on the 
main download site that had pretty much everything that’s in the aggregated 
repository?
I really don't think so.
Packages are a good way to start which includes most available relevant stuff 
for release-train.


1. The package would be too large. With modern download speeds, I suspect most 
users would rather wait a few minutes longer for Eclipse to download than spend 
time later trying to figure out how to install the missing pieces. The disk 
space difference is also inconsequential these days.
A lot of people would feel better with something lighter to achieve the same 
goal. If Eclipse goes to 1.5G to download whereas NetBeans is 200M, people 
would probably try NetBeans first, and adopt it.


 2. The users prefer to not include pieces in their installation that they 
don’t use. I can see that being the case for some advanced Eclipse users, but I 
don’t believe this holds true across the user base. I suspect that most users 
would rather spend time on their development project than tuning their Eclipse 
installation.
A frequent complaint is that Eclipse contains too many things for usage, so 
many UI entries make usage more complicated and confusing. I can imagine that 
people doing some GMF stuff really don't want WTP at all because it introduce a 
lot of new menus, so a GMF user which is used to the Modeling package would 
spend more time to find the relevant menus for his work, and this is pretty 
annoying.


 3. Too many plugins in one installation leads to poor user experience. If 
there are problems like that, we should be identifying and fixing them.
Eclipse is very heterogeneous in term of quality and ergonomics. That's 
something I'm afraid that can't be fixed easily because of the community being 
heterogeneous itself. Just hoping we increase and unify the usage experience 
for all projects in the release train seems totally unachievable.


 Thoughts?
Although people complain about installation taking some time, it's a yearly 
effort. Having a single package with everything installed introduce a lot of 
noise to end-user which can be very annoying and reduce productivity every day. 
I really think that good IDEs are not the ones that do everything,

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

2013-07-18 Thread Campo, Christian

I partially agree that your top 10 list is different than mine. However I dont 
believe in the "ultimate truth" that the Eclipse Foundation could supply.

I see the EF as an umbrella not really as the someone/something who wants too 
or should open feature bugs against a project or come up with a list of things 
that should be done. That would be pretty unusual.

And just assume they (the EF) would create just a list, its pretty demotivating 
to invest time and money in that, if there are no resources around who pick it 
up, dont you think ?

Maybe that makes a good topic for ECE 2013 for a BoF or something. I remember 
last year when John reported about the platform in a BoF at ECE 2012 and there 
were quite a number of people listening, but resources were a large topic. Any 
the plans that he talked about were rather small things since they are not many 
active platform committers.

christian

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Mickael 
Istria
Gesendet: Donnerstag, 18. Juli 2013 10:52
An: cross-project-issues-dev@eclipse.org
Betreff: Re: [cross-project-issues-dev] Preferences (topic was touched in 
"Eclipse smells kind of dead" thread)

On 07/18/2013 10:37 AM, Campo, Christian wrote:
But are we not already aware of say the top 10 things that we think should be 
done.
I'm not sure about that. I have my personal bets on some of the top features, 
but I'm not sure what I have in mind is actually what would make the user 
ecosystem happier. That's why I would find quite interesting to have some 
"official" reports about this top 10 (or more) based on the actual state of IDE 
market/ecosystem.
It would help contributors to focus on the most important issues, and help 
companies to decide of where to focus their investment.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat<http://www.jboss.org/tools>
My blog<http://mickaelistria.wordpress.com> - My 
Tweets<http://twitter.com/mickaelistria>

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

2013-07-18 Thread Campo, Christian

But are we not already aware of say the top 10 things that we think should be 
done. Maybe just in our view but its not that we have no idea what is needed.

I think Mike points at the 2 or 3 people in the platform that are currently 
only available and that means that they have mostly to concentrate on bug fixes 
and smaller features. If you now have a wish for a larger feature that requires 
a few month to implement, who steps up and raises his/her hand to actually do 
it.

christian

Von: Mickael Istria mailto:mist...@redhat.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Donnerstag, 18. Juli 2013 09:59
An: "mike.milinkov...@eclipse.org" 
mailto:mike.milinkov...@eclipse.org>>
Cc: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Preferences (topic was touched in 
"Eclipse smells kind of dead" thread)

I understand your point about the lack of resources. For sure, more 
contributors/workforce would be the solution to most issues.
But let's face it, the "lack of resources" problem has been there for years, 
and despite of all efforts made by the project teams, the number of 
contributors doens't grow that much. In parallel to making efforts to get more 
contributors, we have to deal with this lack of resources in the Eclipse 
community. A way to deal with this is to provide some guidance to make the best 
things happen with the current amount of contributors. And Eclipse Foundation 
is IMO the only organization which is able to be efficient at listening to the 
"market" of IDEs and provide summaries of what people from outside of the 
community see as main issues in Eclipse in a sustainable. Then the Foundation 
could provide recommendation to projects so they could take them into account 
in their roadmap or in the way they prioritize bugs.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My 
Tweets

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

2013-07-17 Thread Campo, Christian

Are you sure that Visual Studio is our target for comparison ?

How about this comparision ? 
http://developer4life.blogspot.de/2012/01/intellij-vs-eclipse.html

And while Eclipse makes some good points there, there are still a number of 
points where Intellij seems to be better (to my surprise) i.e. "Usability: 
Intellij user experience is much easier to grasp."

And there are many comparisons of that kind. I think we should be tackle the 
points where the IntellJ community edition is better than Eclipse rather than 
compare us with Visual Studio.

just my 2 cent…..

Von: "mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>" 
mailto:mike.milinkov...@eclipse.org>>
Organisation: Eclipse Foundation
Antworten an: 
"mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>" 
mailto:mike.milinkov...@eclipse.org>>, Cross 
issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Mittwoch, 17. Juli 2013 16:29
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Preferences (topic was touched in 
"Eclipse smells kind of dead" thread)

If we’re looking for user feedback, reading the article and comments here[1] 
would be helpful.

[1] http://slashdot.org/topic/bi/visual-studio-vs-eclipse-a-programmers-matchup/

Mike Milinkovich
mike.milinkov...@eclipse.org<mailto:mike.milinkov...@eclipse.org>
+1.613.220.3223

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Daniel 
Megert
Sent: July-16-13 4:12 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Preferences (topic was touched in 
"Eclipse smells kind of dead" thread)

Christian,

the "refresh" issue has been resolved a year ago in the Juno (4.2) release, but 
you might not see it in old workspaces yet. Make sure the General > Workspace > 
'Refresh on access' preference is checked. You can even go further and enable 
'Refresh using native hooks or poling'.

Regarding recompiling the whole workspace: definitely a big bug. Please file a 
bug report (if not done already) and we will investigate.

The line number preference discussion currently happens in 
https://bugs.eclipse.org/191154.

Dani


From:"Campo, Christian" 
mailto:christian.ca...@compeople.de>>
To:Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date:16.07.2013 09:54
Subject:Re: [cross-project-issues-dev] Preferences (topic was touched 
in "Eclipse smells kind of dead" thread)
Sent by:
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>




Sharing prefs between workspaces sounds good. The suggested solution still 
sounds a little bit too complicated (for my taste of course). If I open a 
workspace, why cant I not directly reference an existing workspace and copy the 
preferences from there ? (why the extra export step) And for completeness 
wouldnt it be call if all my Eclipse installations share the same list of know 
workspace locations :-) so that I dont have to add them again when I unpack a 
new Eclipse IDE.

I also think the "IHateEclipse" page is not only about preferences. I can think 
of a list of top 10 items that every newcomer to Eclipse hates and we since we 
use it so long got used to it. We accept although deep in us we dont think that 
it has to be that way right ?

  *   line numbers
  *   the reoccuring refresh option (eclipse detects a change on disk, but you 
need to press F5, no option (default=true) to always refresh)
  *   software update: couldnt Eclipse auto check for updates like any current 
other tool I use and say "there are updates, do you want to install them"
  *   software update:  when I select a software update site, it checks the P2 
data, yet the progress of this is shown at the bottom of the shell window and 
not in the dialog where I am currently working, maybe a thing that people dont 
even notice and get the impression of slowliness
  *   and yes I have also seen myself "An error occurred, details: cant display 
details: an error occurred"
  *   which leads too:  could it be interesting to give users the option to 
send exceptions in the IDE to eclipse.org and then the individual plugin 
providers can pick them up or query them. (What exceptions in real life have 
happened in the EMF model editor ?) 
  *   easier or standard shortcuts. I like the point about CTRL-TAB for editor 
switching. And I hate shortcuts like ALT-CTRL + G + I (does anyone seriously 
use that)
  *   I also dont get it why Eclipse recompiles my whole workspace when I start 
the Eclipse IDE, although it was compiled and running when I stopped the IDE

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

2013-07-16 Thread Campo, Christian

Sharing prefs between workspaces sounds good. The suggested solution still 
sounds a little bit too complicated (for my taste of course). If I open a 
workspace, why cant I not directly reference an existing workspace and copy the 
preferences from there ? (why the extra export step) And for completeness 
wouldnt it be call if all my Eclipse installations share the same list of know 
workspace locations :-) so that I dont have to add them again when I unpack a 
new Eclipse IDE.

I also think the "IHateEclipse" page is not only about preferences. I can think 
of a list of top 10 items that every newcomer to Eclipse hates and we since we 
use it so long got used to it. We accept although deep in us we dont think that 
it has to be that way right ?


  *   line numbers
  *   the reoccuring refresh option (eclipse detects a change on disk, but you 
need to press F5, no option (default=true) to always refresh)
  *   software update: couldnt Eclipse auto check for updates like any current 
other tool I use and say "there are updates, do you want to install them"
  *   software update:  when I select a software update site, it checks the P2 
data, yet the progress of this is shown at the bottom of the shell window and 
not in the dialog where I am currently working, maybe a thing that people dont 
even notice and get the impression of slowliness
  *   and yes I have also seen myself "An error occurred, details: cant display 
details: an error occurred"
  *   which leads too:  could it be interesting to give users the option to 
send exceptions in the IDE to eclipse.org and then the individual plugin 
providers can pick them up or query them. (What exceptions in real life have 
happened in the EMF model editor ?) 
  *   easier or standard shortcuts. I like the point about CTRL-TAB for editor 
switching. And I hate shortcuts like ALT-CTRL + G + I (does anyone seriously 
use that)
  *   I also dont get it why Eclipse recompiles my whole workspace when I start 
the Eclipse IDE, although it was compiled and running when I stopped the IDE
  *   why is the Maven default to update the dependencies from all remote 
repositories (takes ages)
  *   startup time ("preparing JDT tooling" etc.) also a complain.

What I really want to say is the pain points that are articulated on that 
website, I believe are larger than fixing the preferences.

So next to that existing technical discussion of preferences I think it would 
be also cool if there where a thread about what kind of others improvments we 
see. Does anyone agree with my personal list above ? Do you have your own list 
of things that got used too but dont really like ? What are the pain points of 
your customers ?

christian

Von: Eric Moffatt mailto:emoff...@ca.ibm.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Montag, 15. Juli 2013 20:39
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] Preferences (topic was touched in 
"Eclipse smells kind of dead" thread)


This is a great discussion !  To me it's always seemed odd that the workspace 
is where all the ui information is stored. I'd like to always use the same UI 
for the same type of task regardless of where the projects / files reside.

We've already started looking into how we might support a 'common' UI setup in 
Luna. Basically it would try to separate the UI from the workspace as well as 
allowing different setups based on the type of work you are doing. The current 
approach would effectively override the current mechanism(s) to gain access to 
the '.metadata' to allow a choice between using the workspace's location or the 
'common' one.

The main issue is to determine *which* metadata is common vs workspace 
oriented. The best approach I can think of would be an 'opt in' one where a 
component would declare which of its 'plugins' directories can be 'common'. The 
platform would then use this info when providing the path to store the 
information for a particular bundle...

Do you think that this can work ? For the UI certainly but without capturing 
things like dialog settings and ui preferences it's not likely to be seen as a 
huge gain. My guess is that of all the information we save in '.metadata' most 
is not really specific to a particular workspace.

I realize after talking to McQ that how to split up preferences has proven in 
the past to be a very difficult problem. How about if the user just exports 
whatever prefs they're interested in to the 'common' area and we auto-import 
these whenever we're working against a new workspace ?

Onwards,
Eric


[Inactive hide details for Doug Schaefer ---07/15/2013 01:23:51 PM---It may be 
hard, but it's is one huge item that we've all ru]Doug Schaefer ---07/15/2013 
01:23:51 PM---It may be hard, but it's is one huge item that we've all run into 
with our users. It's probably wort



From:

Doug Schaefer mailto:dschae...@qnx.com>>


To:

Cross project issues 
mailto:cro

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

2013-07-01 Thread Campo, Christian

I have created  https://bugs.eclipse.org/bugs/show_bug.cgi?id=411977 to track 
the discussion…. and to take it off the cross project mailing list.

christian

Von: Doug Schaefer mailto:dschae...@qnx.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Samstag, 29. Juni 2013 16:46
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>,
 Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Cc: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

It would be awesome to see a release of Nebula, BTW. As we try to modernize the 
UI for Eclipse we're finding some nice things there.

D

From: Tom Schindl
Sent: Saturday, June 29, 2013 3:36 AM
To: Cross project issues
Reply To: Cross project issues
Cc: Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site


We have not yet done any release at nebula! We have split the project, into an 
incubator and to-be-released components but did not yet finish it!

Tom

Von meinem iPhone gesendet

Am 28.06.2013 um 23:53 schrieb "Konstantin Komissarchik" 
mailto:konstantin.komissarc...@oracle.com>>:

An official release (as defined by EDP) of an incubating project can be 
contributed, such as a 0.7 of something, but not a pre-release build.

Note that this distinction doesn’t apply to Nebula Grid, since Nebula has 
graduated from incubation status and made a 1.0 release back in 2012, so the 
only question is whether the bundles actually correspond to Nebula’s 1.0 
release.

- Konstantin

From:cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
Christian
Sent: Friday, June 28, 2013 2:19 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

to my knowledge a project can also contribute components that are still in 
incubator and havnt done a release yet. I am sure we asked that in the past. 
(EMO)

We also distributed Nebula CompositeTable in the past for a number of years and 
now we include the Nebula Grid.

So I disagree with "there should not be any pre-release bundle in the release 
train repo".

christian

Von: Konstantin Komissarchik 
mailto:konstantin.komissarc...@oracle.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Freitag, 28. Juni 2013 22:58
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Cc: 'Nebula Dev' mailto:nebula-...@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Does the version of nebular.widgets.grid in Kepler correspond to a Nebula 
release (not a pre-release build)?

If it does corresponds to a release, there is nothing wrong here. A project can 
contribute its dependencies to the release train aggregation even if those 
dependencies aren’t part of the release train.

If it doesn’t correspond to a release, then there is a serious problem as there 
shouldn’t be any pre-release bundles in Kepler.

I notice that Nebula is using 1.0.0.HEAD versioning for the bundle and it seems 
that the version doesn’t change from build to build. This is very wrong and may 
make answering the above question rather difficult. Nebula should work to fix 
the build ASAP.

Thanks,

- Konstantin


From:cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
Christian
Sent: Friday, June 28, 2013 1:43 PM
To: Cross project issues
Cc: Nebula Dev; Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Hi,

Yes riena uses the nebula gid widget and because of that we distribute it in 
our p2 repo.

Whats wrong with that ?

Gruesse

Christian

Am 28.06.2013 um 15:25 schrieb "Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>:

Hi Tom,



I can confirm it’s riena:



$> ssh build.eclipse.org<http://build.eclipse.org>

$> cd 
/home/data/httpd/download.eclipse.org/releases/kepler/201306260900<http://download.eclipse.org/releases/kepler/201306260900>

$> unzip -p content.jar | grep -B 50 'require.*nebula.widgets.grid' | egrep 
'unit|nebula.widgets.grid'

























I don’t know from what repository riena (or the aggregator) pulls in the odd 
version.



Thanks,

Martin

--

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

direct +43.662.457915.85  fax +43.662.457915.6





-Original Message

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

2013-06-28 Thread Campo, Christian

to my knowledge a project can also contribute components that are still in 
incubator and havnt done a release yet. I am sure we asked that in the past. 
(EMO)

We also distributed Nebula CompositeTable in the past for a number of years and 
now we include the Nebula Grid.

So I disagree with "there should not be any pre-release bundle in the release 
train repo".

christian

Von: Konstantin Komissarchik 
mailto:konstantin.komissarc...@oracle.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Freitag, 28. Juni 2013 22:58
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Cc: 'Nebula Dev' mailto:nebula-...@eclipse.org>>
Betreff: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Does the version of nebular.widgets.grid in Kepler correspond to a Nebula 
release (not a pre-release build)?

If it does corresponds to a release, there is nothing wrong here. A project can 
contribute its dependencies to the release train aggregation even if those 
dependencies aren’t part of the release train.

If it doesn’t correspond to a release, then there is a serious problem as there 
shouldn’t be any pre-release bundles in Kepler.

I notice that Nebula is using 1.0.0.HEAD versioning for the bundle and it seems 
that the version doesn’t change from build to build. This is very wrong and may 
make answering the above question rather difficult. Nebula should work to fix 
the build ASAP.

Thanks,

- Konstantin

From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Campo, 
Christian
Sent: Friday, June 28, 2013 1:43 PM
To: Cross project issues
Cc: Nebula Dev; Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Hi,

Yes riena uses the nebula gid widget and because of that we distribute it in 
our p2 repo.

Whats wrong with that ?

Gruesse

Christian

Am 28.06.2013 um 15:25 schrieb "Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>:

Hi Tom,

I can confirm it’s riena:

$> ssh build.eclipse.org<http://build.eclipse.org>

$> cd 
/home/data/httpd/download.eclipse.org/releases/kepler/201306260900<http://download.eclipse.org/releases/kepler/201306260900>

$> unzip -p content.jar | grep -B 50 'require.*nebula.widgets.grid' | egrep 
'unit|nebula.widgets.grid'

I don’t know from what repository riena (or the aggregator) pulls in the odd 
version.

Thanks,

Martin

--

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

direct +43.662.457915.85  fax +43.662.457915.6

-Original Message-
From: 
cross-project-issues-dev-boun...@eclipse.org<mailto:cross-project-issues-dev-boun...@eclipse.org>
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Tom Schindl
Sent: Friday, June 28, 2013 3:08 PM
To: Nebula Dev
Cc: Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Wild guess is that one of the release train projects uses it - IIRC riena used 
to use it.

Tom

On 28.06.13 13:51, Wim Jongman wrote:

> Hi,

>

> Apparently the Nebula Grid widget is available from the Kepler Update

> site. This should not be the case.

>

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=411867

>

> Regards,

>

> Wim

>

>

> ___

> nebula-dev mailing list

> nebula-...@eclipse.org<mailto:nebula-...@eclipse.org>

> https://dev.eclipse.org/mailman/listinfo/nebula-dev

>

___

cross-project-issues-dev mailing list

cross-project-issues-dev@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de<http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

2013-06-28 Thread Campo, Christian

Hi,

Yes riena uses the nebula gid widget and because of that we distribute it in 
our p2 repo.

Whats wrong with that ?

Gruesse

Christian

Am 28.06.2013 um 15:25 schrieb "Oberhuber, Martin" 
mailto:martin.oberhu...@windriver.com>>:

Hi Tom,

I can confirm it’s riena:

$> ssh build.eclipse.org

$> cd 
/home/data/httpd/download.eclipse.org/releases/kepler/201306260900

$> unzip -p content.jar | grep -B 50 'require.*nebula.widgets.grid' | egrep 
'unit|nebula.widgets.grid'

I don’t know from what repository riena (or the aggregator) pulls in the odd 
version.

Thanks,

Martin

--

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

direct +43.662.457915.85  fax +43.662.457915.6

-Original Message-
From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Tom Schindl
Sent: Friday, June 28, 2013 3:08 PM
To: Nebula Dev
Cc: Cross project issues
Subject: Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available 
from Kepler update site

Wild guess is that one of the release train projects uses it - IIRC riena used 
to use it.

Tom

On 28.06.13 13:51, Wim Jongman wrote:

> Hi,

>

> Apparently the Nebula Grid widget is available from the Kepler Update

> site. This should not be the case.

>

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=411867

>

> Regards,

>

> Wim

>

>

> ___

> nebula-dev mailing list

> nebula-...@eclipse.org

> https://dev.eclipse.org/mailman/listinfo/nebula-dev

>

___

cross-project-issues-dev mailing list

cross-project-issues-dev@eclipse.org

https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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 RC1 ... its going to be a late night!

2013-05-23 Thread Campo, Christian

Hi,

maybe I can step up here, since comments from me :-) are already in this
thread. I have to admit that Riena had problems with the aggregation too in the
past.

I also thought for a long time (actually years) that the only way to "try" a
new contribution is to build, sign, upload, change b3aggrcon,commit,push wait
for the aggregation to kick off and pray that there is a reasonable result
while I am still awake. (because of the time difference sometimes). Try a new
run while its actually already after bed-time in my country.

Now yesterday I found that all you need to do is run Eclipse, with
org.eclipse.simrel.build checked out in your workspace and the b3 aggregator
editor installed (i.e.
http://download.eclipse.org/modeling/emft/b3/updates-4.2/)

Now I can try to add a new version of Riena, build, sign, upload, change
b3aggrcon but now instead of committing,pushing, praying (you remember from
above) you can in the aggregation editor right click and say "Validate
Aggregation". It takes under 5 minutes and you get exactly the same message
that you have to search and find in the aggregation build console.
Of course you can also locally disable other projects that get in the way of
validating your project.

Really really EASY and I wish I had tried that years ago

Christian campo

Von: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von
sven.rottst...@sungard.com
Gesendet: Donnerstag, 23. Mai 2013 15:44
An: cross-project-issues-dev@eclipse.org
Betreff: Re: [cross-project-issues-dev] Status and outlook for RC1 ... its
going to be a late night!

Hi Greg,

[1] shows that the build was triggered by only one SCM change with the comment:
"For ptp, add org.eclipse.ptp.debug.sdm feature". Before of this change the
build was working. So IMO it suggests itself that this commit was breaking the
build.

BTW: This is exactly the way how I was checking that my change for Kepler RC1
was not breaking the build (because it was my first commit into the simrel
repo), that was obviously not that case [2] ;)

In general I would vote to use Gerrit and CI a little bit closer together how
it is mentioned in [3]. But IMO this is not acceptable for such a "build
sprint".

[1] https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/476/
[2] https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/472/
[3]
http://blogs.collab.net/teamforge/teamforge-git-gerrit-integration-with-jenkins-ci

Cheers,
Sven

Von:
cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Greg
Watson
Gesendet: Donnerstag, 23. Mai 2013 13:38
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Status and outlook for RC1 ... its
going to be a late night!

On May 22, 2013, at 11:43 PM, David M Williams
mailto:david_willi...@us.ibm.com>> wrote:

There's no change in policy. Projects choose to be in the (our) common repo.
Part of that is to provide valid input to the build. Normally the tools work
well to send out notifications for problems. Occasionally the contributed input
is so bad that the tool can't even read it well enough to find the email
addresses. You can wait until someone tells you that, if you'd like. But, as
tonight, sometimes that takes 3 or 4 hours (or longer) for someone else to
notice. As you said, you were "waiting for a build" ... how long would you wait
before you looked at
https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.kepler.runaggregator/
?

I looked at it and the error was "exec returned: 13". How am I supposed to know
that this is related to ptp? Is your expectation that I should dig into how it
works to determine what is causing this problem? I don't think so.

The automatic notifications may be deceptive, because they say they are from
"me" but its all automated. I do not send them. I do not even see
most of them ... at least, usually, until after the contributors have already
fixed their problem. If it fails so badly that it can not find email addresses,
I get an RSS notification that the Hudson failed. But, you may be surprised to
hear, I am not on-line monitoring that queue 24 hours a day!

Come on David, you said that "it was ptp breaking the builds..." and you
"...spent an extra hour of my time fixing that". So you obviously knew there
was a problem, but chose not to inform anyone about it.

And, I'll be blunt, I'm sensitive to this for the PTP project, because similar
things have happened several times before, most recently in M7... also last
minute. (I know, I know, you were on vacation then :)

But, I somehow how get the impression your project has not yet learned the
convenience of using the b3 aggregator editor, a requirement that is well
documented in
http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build
Maybe i

Re: [cross-project-issues-dev] SSH down on Build.eclipse.org?

2013-05-23 Thread Campo, Christian

I get there with no problem

Von: Mark Russell mailto:mrruss...@google.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Datum: Donnerstag, 23. Mai 2013 15:32
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: [cross-project-issues-dev] SSH down on Build.eclipse.org?

I can't get to build.eclipse.org via ssh.  But I can 
get there via http (http://build.eclipse.org).  anyone else having issues or is 
it just something local?

--
Mark R Russell
(724) 473-3140
Software Engineer in Test
Google Shopping Express
Google Pittsburgh


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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 M7

2013-05-08 Thread Campo, Christian

I seem to have the same problem with Riena :-)

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Tsvetkov, 
Krum
Gesendet: Mittwoch, 8. Mai 2013 16:40
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] Status and outlook for M7

Just checked that the next build 422, building because of 
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=fd51b94b8bfabbd71f15ae1c31fdd33c72707c87

is also taking the previous repo (in this case of riena): 
https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/422/consoleText

 [exec] Loading repository 
file:///home/data/httpd/download.eclipse.org/rt/riena/5.0.0.M6/update
...
 [exec] - mirroring artifact 
osgi.bundle,org.eclipse.riena.sample.app.common,5.0.0.v20130319_5_0_0_M6



From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Tsvetkov, 
Krum
Sent: Mittwoch, 8. Mai 2013 15:54
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status and outlook for M7

Hi,

I made a change to update MAT contribution for M7 (updated the p2repo location 
and the version numbers), and the aggregator build picked it:
https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/421/

However, when I look into the console logs I see that the build still takes our 
old bundles. Did I miss something?

Git tree:
http://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/mat.b3aggrcon
...
  http://download.eclipse.org/mat/kepler/M7/update-site/"; 
description="Memory Analyzer Updates">

...

Build output:
https://hudson.eclipse.org/hudson/job/simrel.kepler.runaggregator/421/consoleText

...

 [exec] Loading repository 
file:///home/data/httpd/download.eclipse.org/mat/kepler/M5/update-site
...

 [exec] - mirroring artifact 
osgi.bundle,org.eclipse.mat.api,1.3.0.201302052014
...

Any hints?
I checked the commit id in the console log, and it is my commit.

Krum
PS: I just saw that the next build still uses our old contribution.

From: 
cross-project-issues-dev-boun...@eclipse.org
 [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of David M 
Williams
Sent: Mittwoch, 8. Mai 2013 08:09
To: 
cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Status and outlook for M7

Just a reminder that today (Wednesday) is the last day to make contributions 
towards the M7 Sim. Rel. repository.

As usual, we will set the deadline for 5 PM Eastern ... but, glad to be 
flexible for a few additional hours, if projects speaks up here to this list 
and requests additional hour or two (and preferably why)

Don't forget to check the repo reports from time to time ... lots of good stuff 
in there to fix for RC1.
http://build.eclipse.org/simrel/kepler/reporeports/

Here are two things keeping me awake tonight (among others, not related to Sim. 
Release):

1) I believe EGit is planning to move to "3.0.0" (still) in M7 and I have seen 
no "warm up" contributions yet, so I am anxious to see what, if anything breaks 
from that. (Short runway!)

2) I've not seen a green build for EPP for M7 and in talking to Markus, he's 
not had time to work on it yet, getting RAP contribution ready ... so, in other 
words ... I sure hope no one (such as my Platform builds, broke the EPP builds!)

So ... have a good Wednesday! Sleep well. :)

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] M7 dependency problems

2013-05-08 Thread Campo, Christian

Riena has moved to RAP 2.1 in Riena M7. For some reason the aggregator does not 
like to pick it up. I emailed David already.

Maybe you can see what I am doing wrong in the b3aggr files

Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Markus 
Knauer
Gesendet: Mittwoch, 8. Mai 2013 16:36
An: Eclipse Cross Project Issues
Betreff: [cross-project-issues-dev] M7 dependency problems

Hi all,
I've contributed our RAP 2.1M2 to Kepler M7 now and by running the validator 
locally on my computer I see at least two open issues in other projects:

- Scout RAP Runtime with 
org.eclipse.scout.rt.rap.testing/com.thoughtworks.selenium seems to rely on RAP 
contributing a bundle to the Simultaneous Release repository that exports 
org.json. But with our own parser implementation we do not include any external 
JSON bundle any more.
- The Riena Eclipse UI Fragment seems to require RAP 1.4.0 but we have moved on 
to RAP 2.1.0.
Thanks,
Markus

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] CVS access to Orbit

2013-01-15 Thread Campo, Christian

Hi Ed,

I totally understand your point and frustration.

However havnt we all been warned by Wayne in numerous emails that "CVS will be 
shutdown" at the 21st December 2012 for over one year now.

CVS shutdown is not the same thing as "set to readonly".

So I think if that was a concern it should have been brought up way earlier.

Just my 2 cents

Christian Campo

-Ursprüngliche Nachricht-
Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Ed Willink
Gesendet: Dienstag, 15. Januar 2013 17:20
An: Cross project issues
Betreff: Re: [cross-project-issues-dev] CVS access to Orbit

Hi

December 21st was the end of the world as far as committer CVS write access was 
concerned.

However it was not the end of the world as far as user CVS read access was 
concerned.

A variety of examples and documentation describe fetching code from CVS.
It is not feasible
to rewrite such text within Helios/Indigo/Juno distributions taht are still in 
use.

It is also a major pain for us committers. For instance, when a Bugzilla report 
refers to line 45 of version 1.9 of a file; without viewcvs, it takes 
significantly longer to identify the line in question.

There seems absolutely no benefit in retracting this useful facility and 
breaking functionality upon which the current Juno release documentation 
depends.

 Regards

 Ed Willink

On 15/01/2013 15:14, Doug Schaefer wrote:
> While Denis is pealing himself off the ceiling, I'll chime in. Isn't
> this all in git now? I thought Orbit was the only thing officially left in 
> CVS.
>
> :D
>
> On 13-01-15 10:08 AM, "Ed Willink"  wrote:
>
>> Hi
>>
>> /cvsroot/modeling etc etc
>>
>>  Regards
>>
>>  Ed Willink
>>
>>
>> On 15/01/2013 14:58, Denis Roy wrote:
>>> What other repositories?  The only CVS repo I know of is Orbit.
>>>
>>> Denis
>>>
>>>
>>>
>>> On 01/15/2013 03:36 AM, Ed Willink wrote:
 Hi Denis

 Thanks. CVS from PSFs works again.

 If we now have an anonymous CVS server for Orbit, can we please
 restore the anonymous CVS access for the other repositories too so
 that Helios, Indigo, Juno facilities work again for ordinary users?

  Regards

  Ed Willink

 On 14/01/2013 22:29, Denis Roy wrote:
> I've re-enabled pserver CVS for /cvsroot/tools.  I'm hoping
> someone can try it out, since my modern-day computer doesn't ship
> with cvs :-D
>
> Denis
>
>
>
> On 01/14/2013 03:36 PM, Ed Willink wrote:
>> Hi
>>
>> My understanding is that CVS has been preserved for Orbit, at
>> least temporarily, but anonymous access has not.
>>
>> How am I expected to rewrite PSF fetches (for use by ordinary
>> users) such as
>>
>> 
>> >
>> reference="1.0,:pserver:anonym...@dev.eclipse.org:/cvsroot/tools,
>> org.e clipse.orbit/lpg.runtime.java,lpg.runtime.java,v2_0_17"/>
>> 
>>
>>  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
>>>
>>>
>>> -
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2013.0.2890 / Virus Database: 2638/6031 - Release Date:
>>> 01/13/13
>>>
>>>
>> ___
>> 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.2890 / Virus Database: 2638/6031 - Release Date:
> 01/13/13
>
>

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

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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] Juno RC1 staging repository is complete

2012-05-23 Thread Campo, Christian

Hi David,

please dont confuse me :-). We had an extensive discussion back at the 
beginning of the year, that Riena does not run on top of Eclipse 4.x. It only 
runs on top of 3.8.

Thats a deal breaker for participating in Juno since e4 support is a 
requirement for Juno participation.

The discussion was going forth and back and I think you made the suggestion 
that Riena would deliver their own repo but dont aggregate into the composite 
repo. So thats what we do since then. We also didnt aggregate M6 and M7 I 
believe.

BTW the platform dependent bundle bundles that we used to deliver in our p2 
repo and create a lot of problems in the past are all gone.

Still we dont run yet on e4. (We are currently building that ability in a 
branch and are making good progress but its not ready and it will not be 
finished in the Juno time frame. But there is hope for the future :-) )

Hope that clears it up……

christian

p.s. Riena RC1 is finished since monday (http://www.eclipse.org/riena/)

Von: David M Williams 
mailto:david_willi...@us.ibm.com>>
Antworten an: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
An: Cross issues 
mailto:cross-project-issues-dev@eclipse.org>>
Betreff: [cross-project-issues-dev] Juno RC1 staging repository is complete


Thanks to all the last minute fixes and getting a clean build. I've disabled 
the aggregation build and assume we are ready for RC1, unless someone comes up 
with a blocking problem that justifies a respin.

My main concern is that there are still two projects still disabled:

amp.b3aggrcon
riena.b3aggrcon

Riena I'm not worried about, I know they sort of "come and go" as are sensitive 
to exact platform version, so assuming this was an oversight or busy week for 
the Riena team and they are basically ok and will be back in for RC2.

Amp, on the other hand, has been disabled for nearly all of Juno, and its 
update site in the b3aggrcon file still points to a software repository named 
"indigo_b3" which sounds old.

I think maybe Amp has "dropped out" of Juno, and I have just missed that. The 
contact listed in file is Mile Parker. If I don't here from him soon, here on 
this list, or hear from the Modeling PMC, I'll assume they've withdrawn and 
remove the contribution file before RC2.

Thanks all,


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Hudson shutdown wait from hell

2012-02-10 Thread Campo, Christian

FWIW

I am personally very much in favor of having a new mailing list for hudson
build infrastructure messages. Many issues like slaves hanging, hudson is
restarted are short-lived issues that are not always worth a bugzilla
entry. Also cross project list gets really a lot of traffic from hudson
issues currently which maybe is not interesting to people who dont build
there.

I am sure also some messages get lost because not cross project mails dont
have a high priority for everyone. And they could reduce the redundant
traffic on all the other channels that Denis mentioned.
It shouldnt make bugzilla redundant but it could be used for every message
about hudson that we otherwise post to cross-projectŠ.

just a thought

christian


Am 08.02.12 20:49 schrieb "David M Williams" unter
:

>I'd agree with this general idea ... perhaps a general notice go out on a
>mailing list "hudson is being shutdown and restarted ... any jobs not done
>by +1 hour [or something] will be killed". (I'm proud to say I cancelled
>one of my running aggregator jobs when I saw it was about to be shutdown,
>saving 50 minutes or so (if I was only job running)  partially because
>I knew it needed to run again anyway.
>
>But, now I am panicking ... seeing 30 jobs stacked up in queue! I suggest
>anyone that has a non-essential job running or queued up consider
>canceling
>it until Hudson "stabilizes" and then run your nightlies, etc. I looks
>like
>the number of threads (executors) has been reduced again (understandably).
>But, who knows, maybe it will clear itself up in an hour or two? In time
>for our RC3 deadline?
>
>In general, I'll say there's been very little communication about the
>state
>of Hudson  seems several comments made or questions asked on this list
>with no response ... Hudson restarted, configuration changes all without
>comment. Is there some resistance to that? Everyone too busy to
>communicate? Is their a better channel? Hudson bug list? Do we need a
>"hudson-and-infrastructure" mailing list? Just asking.
>
>The queue is down to 26 now ... in the 10 minutes I took to write this
>note ... if that rate holds, it will be clear in 90 minutes or so? :/
>
>Thanks,
>
>
>
>
>
>
>From:  Miles Parker 
>To:Cross project issues ,
>Date:  02/08/2012 02:22 PM
>Subject:   [cross-project-issues-dev] Hudson shutdown wait from hell
>Sent by:   cross-project-issues-dev-boun...@eclipse.org
>
>
>
>Hi all,
>
>I wanted to bring up a Hudson annoyance and see if people had ideas for
>improving this. What's happening now is that any time Hudson gets sent a
>shutdown, everyone is locked out until the last job in queue finishes.
>Which is a) Good news for the people with running builds, b) Bad news for
>everyone else. Observing that most of the time most of us are  in category
>b) I vote for making things work better for group b). Nothing against
>PTP :D, but they happen to be in group a) this time around and the last
>run
>took 22 hours. :O But there are lot's of long builds out there. This means
>that snapshots are delayed for everyone.
>
>So I'm wondering if it might be possible to have some kind of policy where
>builds are terminated with prejudice under shutdown. I'm not sure if a)
>this is even supportable OOTB in Hudson, and b) whether that would have
>the
>possibility of FUBAR'ing anyone project builds. As project builds should
>not be relying on previous state, I would say that the answer to b is
>probably no. I also imagine allowance should be made for key builds such
>as
>aggregator. IIRC in the past when in release panic mode we were triggering
>hard shutdowns from time to time.
>
>thoughts?
>
>Miles
>___
>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


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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] Declaring Indigo SR2 RC3 staging repo done

2012-02-09 Thread Campo, Christian

David, One day over a beer I'd like to hear your "respectful" definition
of pesky :-)

But it only took us 3 years to learn from our errors :-) and remove the 2
platform bundles from our p2 repo. I did that last year for Juno and done
the same thing for Indigo SRxxx. So you are free to run as many SRs as you
want NOW, Riena wont stumble over updated platform bundles anymoreŠ

christian

p.s. sorry you have to find a new "pesky" Eclipse project

Am 09.02.12 15:09 schrieb "David M Williams" unter
:

>
>Thanks Kim, for the early submission and letting us know of this important
>final submission. (And, I even re-enabled the PDE/EE feature for you :)
>
>But, ... point of this note, to be clear to all ... I have disabled Indigo
>aggregation builds for today ... to wait until RC3 is "out the door" (not
>to mention give Hudson a rest :) ... and will re-enable them Friday
>morning.
>
>From my "local build" though it looks like everything will build fine ...
>even that pesky Riena which normally has to react to each platform change
>(and, I say "pesky" with the greatest respect ... and quirkiest of humor
>:)
>
>Thanks all,
>
>
>
>
>
>From:  Kim Moir 
>To:Cross project issues ,
>Date:  02/09/2012 08:12 AM
>Subject:   Re: [cross-project-issues-dev] Declaring Indigo SR2 RC3 staging
>repo   done
>Sent by:   cross-project-issues-dev-boun...@eclipse.org
>
>
>
>I've just contributed 3.7.2RC4 to the Indigo build.
>
>Kim
>
>
>
>From:David M Williams 
>To:cross-project-issues-dev@eclipse.org
>Date:02/08/2012 07:27 PM
>Subject:[cross-project-issues-dev] Declaring Indigo SR2 RC3
>staging
>repodone
>Sent by:cross-project-issues-dev-boun...@eclipse.org
>
>
>
>
>
>Despite Hudson's attempts to thwart our progress, our RC3 repo is done and
>testable at
>
>http://download.eclipse.org/releases/maintenance/
>
>and this one is a true release candidate!  (though, I know a few more bug
>fixes are planned for RC4, our final build).
>Thanks to all those fixing "legal file" type problems, etc. to get as
>close
>as possible to final form.
>
>http://build.eclipse.org/indigo/simrel/index.html
>
>Remember that once we release Indigo SR2, it will joining the Indigo
>Release and Indigo SR1 repositories as a composite repo, at
>
>http://download.eclipse.org/releases/indigo/
>
>This RC3 build will be a good one to test as a "pseudo composite" by
>careful construction of your software repository list. See
>http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#What.27s_the_best_
>way_to_test_with_the_staging_repository.3F
>
>
>This is important to test for things like "updates"
>(You will have to wait till Friday, to test "updates" if you start with an
>EPP Package).
>
>and to confirm no features/bundles accidentally went "down" in version
>number or in general other issues that can work fine in isolation, but
>fail
>in composite repositories.
>
>Test early, test often.
>
>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 mailing list
>cross-project-issues-dev@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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 Indigo RC3

2012-02-06 Thread Campo, Christian

Hi David,

thanks for the help. I have updated the Riena p2 repo to no longer contain
core.net and core.variables (as we already did for Juno). So there should
be no future conflicts in the Indigo aggregation with the bundles supplied
by the Eclipse platform.

christian

Am 06.02.12 07:11 schrieb "David M Williams" unter
:

>
>Nag note ...
>
>Here we are, at beginning of RC3 +1 day, and a few questions and
>reminders ...
>
>Has Eclipse ("the platform") contributed for RC3 yet?
>
>I notice the contribution file says
>M20120127-0800
>but there is an M build from
>M20120201-1336
>which "sounds like" its closer to RC3, but, I do not know the intent.
>
>I ask mostly on behalf of Riena project, which I have re-enabled, and I
>expect that to fail, as they will need to prepare a build that "matches
>exactly" the platform build, so I thought best to ask, and maybe they can
>avoid doing it twice in same week?
>
>I have also re-enabled windowbuilder. I am not sure if that pack.gz issue
>has been fixed yet, but if you need help, be sure to ask.
>
>There is still one missing (disabled) feature,
>org.eclipse.pde.api.tools.ee.fragments, which if I understand bug 362103,
>it will not be back in until the final build (RC4).
>
>Remember that PTP and Papyrus still have "missing legal files",
>http://build.eclipse.org/indigo/simrel/reports/layoutCheck.txt
>
>From the "non unique version numbers" reports
>http://build.eclipse.org/indigo/simrel/reports/nonUniqueVersions.txt
>It appears some projects are not using the latest Orbit repo ... or else
>(worse) are not using Orbit at all, as they should be.
>For Indigo SR2, please use the Orbit repo from
>http://download.eclipse.org/tools/orbit/downloads/drops/R20120119162704/
>
>Thanks,
>
>
>
>
>
>___
>cross-project-issues-dev mailing list
>cross-project-issues-dev@eclipse.org
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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] deploying snapshot builds fromhudson.e.o to oss.sonatype.org

2011-12-09 Thread Campo, Christian

What kind of software is used by  other maven installations that have staging 
support. Is any of this open source ?

What software is i.e. Used by maven central ?

Maybe that is a silly question and just unclear to me

Gruesse

Christian

Am 09.12.2011 um 21:06 schrieb "Mike Milinkovich" 
mailto:mike.milinkov...@eclipse.org>>:

The Eclipse Foundation has a strict policy of using only open source technology 
for its core infrastructure. The reason is that we have over 100 commerical 
members who compete in  the marketplace and would love to point to Eclipse as a 
reference case for their software. Vendor neutrality is, upon occasion, a PITA.

This has been discussed at the Board many times, but if you want to raise it as 
an issue with the committer reps please do so.

I just checked with the folks at Sonatype, and they have a standing offer of a 
free license for Nexus Pro, with no strings attached, for the Eclipse 
Foundation.
http://www.compeople.de/>

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] Exclude optional bundle dependencies

2011-12-07 Thread Campo, Christian

We had this problem a while ago but more with target platforms, where p2 would 
pull in the optional dependencies never the less they were optional. What we 
did is added a p2.inf file to the META-INF directory of each bundle with RAP 
dependencies with this content:

---
requires.0.namespace = osgi.bundle
requires.0.name = org.eclipse.rap.jface.databinding
requires.0.greedy = false
requires.0.optional = true

requires.1.namespace = osgi.bundle
requires.1.name = org.eclipse.rap.jface
requires.1.greedy = false
requires.1.optional = true

requires.2.namespace = osgi.bundle
requires.2.name = org.eclipse.rap.rwt
requires.2.greedy = false
requires.2.optional = true

requires.3.namespace = osgi.bundle
requires.3.name = org.eclipse.rap.ui.workbench
requires.3.greedy = false
requires.3.optional = true

requires.4.namespace = osgi.bundle
requires.4.name = org.pushingpixels.trident
requires.4.greedy = false
requires.4.optional = true

requires.5.namespace = osgi.bundle
requires.5.name = org.eclipse.rap.ui.forms
requires.5.optional = true
requires.5.greedy = false

requires.6.namespace = osgi.bundle
requires.6.name = org.eclipse.rap.ui
requires.6.optional = true
requires.6.greedy = false

requires.7.namespace = osgi.bundle
requires.7.name = org.eclipse.rap.ui.workbench
requires.7.optional = true
requires.7.greedy = false
---
Maybe that is also helpful for you

christian


-Ursprüngliche Nachricht-
Von: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] Im Auftrag von Markus 
Tiede
Gesendet: Mittwoch, 7. Dezember 2011 13:21
An: cross-project-issues-dev@eclipse.org
Betreff: [cross-project-issues-dev] Exclude optional bundle dependencies

Hello Folks,

we, the Jubula team, are currently experiencing problems with the inclusion of 
optional bundles (RAP) dependencies when installing our feature into the IDE 
and / or packaging our feature for Juno "Eclipse for testers" (see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=365865).

I am aware that there are multiple longish bugs filed on this topic but does 
any project actually have a working solution for this kind of problem?

With best regards,
MarkusT
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-

___
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] Reminders and notes about upcoming M4

2011-12-05 Thread Campo, Christian

Furthermore.

1. Why was the rule changed anyway? I anticipated Riena to be in Juno until I 
found out through this mail that I am not.

2. Why do projects get aggregated in the composite repo like Riena did in M3 if 
I am not signed up?

A little confusing to me, but apparently I missed the point where somebody 
said, we changed the rule, make sure you sign up...

Anyway I signed up Riena and we already provided content for M3..

christian

Am 06.12.2011 um 00:44 schrieb Matthias Sohn:

2011/12/6 David M Williams 
mailto:david_willi...@us.ibm.com>>


First, remember M4 is "next week" and is short  code-done window from
Friday 12/9 to Wednesday 12/14 ... to be made available on 12/16. Please
remember to respond quickly to "build breaks", even if before your official
+n due date.

Second, projects leads, remember to "sign up" for the Juno release by M4,
on the Eclipse Foundation's Portal. For a list of who is signed up, see
http://eclipse.org/juno/planning/SimultaneousReleaseOverview.php

I was surprised that jgit and egit weren't contained in the Juno list,
I remember for the Indigo release train projects which had participated
in Helios were automatically signed up for Indigo.

Apparently I missed that this policy changed. I signed up jgit and egit for Juno
to fix this. I'll add them to the build soon.

--
Matthias



-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-
___
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] 3.8 bundles in Juno

2011-11-08 Thread Campo, Christian

I thought 3.8 is not in Juno but only 4.2 and 3.8 is released at the same time 
as Juno. But I am not an expert and might be wrong

Gruesse

Christian

Am 08.11.2011 um 17:34 schrieb "Ralf Sternberg" 
mailto:rsternb...@eclipsesource.com>>:

Hi,

the RAP M3 contribution causes a conflict with the Juno aggregator
build, which I'm not quite sure how to tackle. The problem is that we
have a feature that contains the requirements for a basic RAP target.
These bundles are taken from 3.8M3 (since RAP is still based on 3.x).
We provide this feature to make it easy for beginners to setup a
complete RAP target. This went well so far, but now 4.2 seems to
diverge from 3.8 and our 3.8 bundles clash with the 4.2 ones. I didn't
expect those problems as 3.8 is still part of Juno.

So here are my questions:
Is it true that the aggregator build is now based on 4.2 and that 3.8
is not part of it anymore?
If so, does this mean that we just can't include any bundles from 3.8
in the Juno repository anymore?

As a quick fix, I disabled the problematic feature for now. This way,
RAP itself is still part of M3, but a target must be assembled
manually.

Regards, Ralf

On Tue, Nov 8, 2011 at 14:55, David Williams 
mailto:david_willi...@us.ibm.com>> wrote:
> The following errors occured when building Juno:
>
> Software being installed: validationSet_main 1.0.0
>
> Only one of the following can be installed at once: 
> [org.eclipse.equinox.http.registry 1.1.100.v20111010-1614, 
> org.eclipse.equinox.http.registry 1.1.100.v20110502]
>
> Cannot satisfy dependency: 
> mappedRepo_download.eclipse.org_eclipse_updates_4.2milestones_S-4.2M3-201110281100
>  1.0.0 depends on: org.eclipse.sdk.feature.group 
> 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0
>
> Cannot satisfy dependency: 
> mappedRepo_home_data_httpd_download.eclipse.org_rt_rap_1.5_runtime_M3-2008-1014
>  1.0.0 depends on: org.eclipse.rap.runtime.requirements.feature.group 
> [1.5.0,1.6.0)
>
> Cannot satisfy dependency: org.eclipse.help.feature.group 
> 1.3.0.v20110809-0800-7i7uFLyFFt6Zqoimz0Bbd48R depends on: 
> org.eclipse.equinox.http.registry [1.1.100.v20111010-1614]
>
> Cannot satisfy dependency: org.eclipse.rap.runtime.requirements.feature.group 
> 1.5.0.2008-1028 depends on: org.eclipse.equinox.http.registry 
> [1.1.100.v20110502]
>
> Cannot satisfy dependency: org.eclipse.sdk.feature.group 
> 4.1.0.v20110612-1800-7T7jA7F8Yx_b_g7iQ1Lsy1jM8NC4BSMUny-agK5mAGqK0 depends 
> on: org.eclipse.help.feature.group 
> [1.3.0.v20110809-0800-7i7uFLyFFt6Zqoimz0Bbd48R]
>
> Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
> mappedRepo_download.eclipse.org_eclipse_updates_4.2milestones_S-4.2M3-201110281100
>  [1.0.0]
>
> Cannot satisfy dependency: validationSet_main 1.0.0 depends on: 
> mappedRepo_home_data_httpd_download.eclipse.org_rt_rap_1.5_runtime_M3-2008-1014
>  [1.0.0]
>
> Check the log file for more information: 
> https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/juno.runAggregator/124/console
>
>

-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-
___
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 Juno M3, nearing end of +1 day

2011-11-07 Thread Campo, Christian

The riena build is nearly finished. I upload an reenable it tomorrow 
morning.
christian

Am 07.11.2011 um 22:33 schrieb David M Williams:


Things are looking pretty good ... which means I was able to coax out a green 
build, hacking in a few "quick fixes" and disable a few contributions.

I've opened bugs where I made a "quick fix" and will remind everyone that the 
following projects still have disabled features or repositories. Some of these 
were "from before", some from today, some expected, some not. So, please take a 
look and see if they can be enabled for M3. (And, please, if any of these 
should be removed, please do so, or let me know if I can help.)

emf-emf.b3aggrcon
emft-eef.b3aggrcon
emft-egf.b3aggrcon
equinox.b3aggrcon (4 matches)
mdt-papyrus.b3aggrcon
rap.b3aggrcon (2 matches)
riena.b3aggrcon
scout.b3aggrcon
windowbuilder.b3aggrcon


Don't forget to periodically check your repository reports ...

http://build.eclipse.org/juno/simrel/

Currently there are quite a few "missing legal files" which would be a lot 
easier to fix earlier rather than later. (And, too many for me to open bugs on 
each project that has some, but the names "ptp", "libra", and "sapphire" show 
up the most).

Thanks everyone,

Now I'm off the Raleigh DemoCamp and Birthday 
party ... I 
hope they have cake!





-
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: J?rgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-
___
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] Riena (+3) participation in Luna

Re: [cross-project-issues-dev] Reminder M2 closes tomorrow, Wednesday 10/2, approximately 5 PM

Re: [cross-project-issues-dev] How to have dependencies on an Eclipse project (NatTable) which is not in the release train?

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

Re: [cross-project-issues-dev] Preferences (topic was touched in "Eclipse smells kind of dead" thread)

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

Re: [cross-project-issues-dev] [nebula-dev] Nebula Grid is available from Kepler update site

Re: [cross-project-issues-dev] Status and outlook for RC1 ... its going to be a late night!

Re: [cross-project-issues-dev] SSH down on Build.eclipse.org?

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

Re: [cross-project-issues-dev] M7 dependency problems

Re: [cross-project-issues-dev] CVS access to Orbit

Re: [cross-project-issues-dev] Juno RC1 staging repository is complete

Re: [cross-project-issues-dev] Hudson shutdown wait from hell

Re: [cross-project-issues-dev] Declaring Indigo SR2 RC3 staging repo done

Re: [cross-project-issues-dev] Status and Outlook for Indigo RC3

Re: [cross-project-issues-dev] deploying snapshot builds fromhudson.e.o to oss.sonatype.org

Re: [cross-project-issues-dev] Exclude optional bundle dependencies

Re: [cross-project-issues-dev] Reminders and notes about upcoming M4

Re: [cross-project-issues-dev] 3.8 bundles in Juno

Re: [cross-project-issues-dev] Status and outlook for Juno M3, nearing end of +1 day

29 matches

Site Navigation

Mail list logo

Footer information