From manderse at redhat.com  Fri May  1 03:00:09 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Fri, 1 May 2015 03:00:09 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505010700.t41709CM023522@int-mx13.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBIDE-19745

https://issues.jboss.org/browse/JBIDE-19745
Summary: rename jbosstools-build-ci 4.3.x to jbosstools-4.3.x 

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 16:20:12.743494

----------------------------



Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27

From manderse at redhat.com  Fri May  1 05:14:08 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Fri, 1 May 2015 05:14:08 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505010914.t419E8eP003134@int-mx13.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBIDE-19745

https://issues.jboss.org/browse/JBIDE-19745
Summary: rename jbosstools-build-ci 4.3.x to jbosstools-4.3.x 

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please ensure this issue has a proper component set.
Last Update: 18:34:11.138539

----------------------------



Query used: https://issues.jboss.org/issues/?jql=%28filter%3D%27ds_lint_nocomponent%27%29

From rstryker at redhat.com  Fri May  1 10:51:21 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Fri, 01 May 2015 10:51:21 -0400
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
Message-ID: <554392E9.3020907@redhat.com>

On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
> I would prefer it actually tagged the sha1 that was used instead of 
> just assumed used. 
Are we any closer to this happening?  What's still 'missing' to make 
this a possibility?

From manderse at redhat.com  Fri May  1 17:11:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 1 May 2015 17:11:34 -0400 (EDT)
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <554392E9.3020907@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
Message-ID: <54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>

If you want the 100% method we need to build from the tag, meaning Dev need start doing their tags and declare them into the build. 

But can we tackle one issue at the time, please :)

I would like to at least have our past final releases tagged consistently. 

We got it for most - just a few stands out. 

/max
http://about.me/maxandersen


> On 01 May 2015, at 16:51, Rob Stryker <rstryker at redhat.com> wrote:
> 
>> On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
>> I would prefer it actually tagged the sha1 that was used instead of 
>> just assumed used.
> Are we any closer to this happening?  What's still 'missing' to make 
> this a possibility?
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From rstryker at redhat.com  Fri May  1 17:33:35 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Fri, 01 May 2015 17:33:35 -0400
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
Message-ID: <5543F12F.5000407@redhat.com>

Maybe I'm missing something, but, how do we go and accurately tag 
previous releases? Do we have the old SHA tags stored somewhere for old 
builds?  Otherwise I don't see how its possible to go and accurately tag 
our previous releases.

On 05/01/2015 05:11 PM, Max Rydahl Andersen wrote:
> If you want the 100% method we need to build from the tag, meaning Dev need start doing their tags and declare them into the build.
>
> But can we tackle one issue at the time, please :)
>
> I would like to at least have our past final releases tagged consistently.
>
> We got it for most - just a few stands out.
>
> /max
> http://about.me/maxandersen
>
>
>> On 01 May 2015, at 16:51, Rob Stryker <rstryker at redhat.com> wrote:
>>
>>> On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
>>> I would prefer it actually tagged the sha1 that was used instead of
>>> just assumed used.
>> Are we any closer to this happening?  What's still 'missing' to make
>> this a possibility?
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From manderse at redhat.com  Fri May  1 21:23:31 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 02 May 2015 03:23:31 +0200
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <5543F12F.5000407@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
	<5543F12F.5000407@redhat.com>
Message-ID: <2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>

On 1 May 2015, at 23:33, Rob Stryker wrote:

> Maybe I'm missing something, but, how do we go and accurately tag 
> previous releases? Do we have the old SHA tags stored somewhere for 
> old builds?  Otherwise I don't see how its possible to go and 
> accurately tag our previous releases.

That is what I asked Nick about since we have been supposed to gather 
that for all builds. Waiting for the answer.

But if not there, then you can start by tagging the tip of the branch 
they should have been made on.

/max


>
> On 05/01/2015 05:11 PM, Max Rydahl Andersen wrote:
>> If you want the 100% method we need to build from the tag, meaning 
>> Dev need start doing their tags and declare them into the build.
>>
>> But can we tackle one issue at the time, please :)
>>
>> I would like to at least have our past final releases tagged 
>> consistently.
>>
>> We got it for most - just a few stands out.
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>> On 01 May 2015, at 16:51, Rob Stryker <rstryker at redhat.com> wrote:
>>>
>>>> On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
>>>> I would prefer it actually tagged the sha1 that was used instead of
>>>> just assumed used.
>>> Are we any closer to this happening?  What's still 'missing' to make
>>> this a possibility?
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From manderse at redhat.com  Mon May  4 05:59:30 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 04 May 2015 11:59:30 +0200
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
Message-ID: <BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>


> I have a few things I'd like to ask/discuss about performance.

I'm cc'ing this on jbosstools-dev@ so those who are working on the 
related issues can chime in too.
> 1) I heard that you know about some performance issues in latest 
> JBDS/Eclipse builds. Could you point me to where can I find details 
> about those issues ?

we have multiple reports over the last releases that our CDI and JPA 
tooling gets slow on large projects.

Latest one was discussed on irc: 
http://transcripts.jboss.org/channel/irc.freenode.org/%23jbosstools/2015/%23jbosstools.2015-04-29.log.html
(look for "attiand")
	
> 2) I'm just running performance tests for JBDS9 Alpha2 and will update 
> mojo doc once I have the results.

which doc exactly ?

> 3) Have you noticed that "UI Responsiveness monitoring" was added in 
> Mars M6? (you can find it in Preferences->General->Tracking). It would 
> be cool to use it but the question is what treshold should I use ?
> I was thinking something around 1second, longer jobs shouldn't be 
> running in UI thread.

+100

> 4) The last thing - I'm playing with a few projects in workspace 
> (50+-, mostly eclipse plugins) and when I change required-bundle in 
> MANIFEST whole Eclipse will freeze for 20seconds.
> I will have to investigate further, but is there any Dev I could talk 
> to about similar performance issues which are (not yet) related to any 
> component ?

Snjezana tend to be good at finding causes, but performance is important 
for us all, so ask away here in jbosstools-dev and #jbosstools chat.

First you should do is grab a a few jstack's of that eclipse when it is 
freezing and see what is showing up in the stack trace.

If that does not reveal anything connect a profiler (jvisualvm might be 
enough) to spot the hotspots for your case.

/max
http://about.me/maxandersen


From rawagner at redhat.com  Mon May  4 06:59:21 2015
From: rawagner at redhat.com (Rastislav Wagner)
Date: Mon, 4 May 2015 06:59:21 -0400 (EDT)
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
Message-ID: <374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Max Rydahl Andersen" <manderse at redhat.com>
> To: "Rastislav Wagner" <rawagner at redhat.com>
> Cc: "jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Sent: Monday, May 4, 2015 11:59:30 AM
> Subject: Re: JBDS9/Mars Performance
> 
> 
> > I have a few things I'd like to ask/discuss about performance.
> 
> I'm cc'ing this on jbosstools-dev@ so those who are working on the
> related issues can chime in too.
> > 1) I heard that you know about some performance issues in latest
> > JBDS/Eclipse builds. Could you point me to where can I find details
> > about those issues ?
> 
> we have multiple reports over the last releases that our CDI and JPA
> tooling gets slow on large projects.
> 
> Latest one was discussed on irc:
> http://transcripts.jboss.org/channel/irc.freenode.org/%23jbosstools/2015/%23jbosstools.2015-04-29.log.html
> (look for "attiand")
> 	
> > 2) I'm just running performance tests for JBDS9 Alpha2 and will update
> > mojo doc once I have the results.
> 
> which doc exactly ?
this one
https://mojo.redhat.com/docs/DOC-1002291

> 
> > 3) Have you noticed that "UI Responsiveness monitoring" was added in
> > Mars M6? (you can find it in Preferences->General->Tracking). It would
> > be cool to use it but the question is what treshold should I use ?
> > I was thinking something around 1second, longer jobs shouldn't be
> > running in UI thread.
> 
> +100
> 
> > 4) The last thing - I'm playing with a few projects in workspace
> > (50+-, mostly eclipse plugins) and when I change required-bundle in
> > MANIFEST whole Eclipse will freeze for 20seconds.
> > I will have to investigate further, but is there any Dev I could talk
> > to about similar performance issues which are (not yet) related to any
> > component ?
> 
> Snjezana tend to be good at finding causes, but performance is important
> for us all, so ask away here in jbosstools-dev and #jbosstools chat.
> 
> First you should do is grab a a few jstack's of that eclipse when it is
> freezing and see what is showing up in the stack trace.
> 
> If that does not reveal anything connect a profiler (jvisualvm might be
> enough) to spot the hotspots for your case.
>
 
Will do. Thanks.

> /max
> http://about.me/maxandersen
> 

From manderse at redhat.com  Mon May  4 09:48:14 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 04 May 2015 15:48:14 +0200
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
	<374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>
Message-ID: <5FF2BC4A-37D8-41BA-AFF5-68410C528D4D@redhat.com>

On 4 May 2015, at 12:59, Rastislav Wagner wrote:

>> which doc exactly ?
>
> this one
> https://mojo.redhat.com/docs/DOC-1002291

There does not seem to be any internal info in this.

Can you move this to jboss.org instead ?

Also I still have my same questions that is on that thread ;)

And could you show the % of difference + deviance so it is not just raw 
numbers and a possible misleading average ?




/max
http://about.me/maxandersen

From manderse at redhat.com  Mon May  4 09:54:57 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 04 May 2015 15:54:57 +0200
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <5FF2BC4A-37D8-41BA-AFF5-68410C528D4D@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
	<374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>
	<5FF2BC4A-37D8-41BA-AFF5-68410C528D4D@redhat.com>
Message-ID: <FA450541-4B14-4439-9E37-D5527D685228@redhat.com>

On 4 May 2015, at 15:48, Max Rydahl Andersen wrote:

> On 4 May 2015, at 12:59, Rastislav Wagner wrote:
>
>>> which doc exactly ?
>>
>> this one
>> https://mojo.redhat.com/docs/DOC-1002291
>
> There does not seem to be any internal info in this.
>
> Can you move this to jboss.org instead ?
>
> Also I still have my same questions that is on that thread ;)
>
> And could you show the % of difference + deviance so it is not just raw
> numbers and a possible misleading average ?

std. *deviation* ...sorry for that freudian slip ;)

>
>
>
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From rawagner at redhat.com  Mon May  4 10:58:29 2015
From: rawagner at redhat.com (Rastislav Wagner)
Date: Mon, 4 May 2015 10:58:29 -0400 (EDT)
Subject: [jbosstools-dev] Fwd: JBDS9/Mars Performance
In-Reply-To: <789549334.11130153.1430748969708.JavaMail.zimbra@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
	<374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>
	<5FF2BC4A-37D8-41BA-AFF5-68410C528D4D@redhat.com>
	<789549334.11130153.1430748969708.JavaMail.zimbra@redhat.com>
Message-ID: <714763418.11160365.1430751509161.JavaMail.zimbra@redhat.com>

----- Forwarded Message -----
From: "Rastislav Wagner" <rawagner at redhat.com>
To: "Max Rydahl Andersen" <manderse at redhat.com>
Sent: Monday, May 4, 2015 4:16:09 PM
Subject: Re: JBDS9/Mars Performance


----- Original Message -----
> From: "Max Rydahl Andersen" <manderse at redhat.com>
> To: "Rastislav Wagner" <rawagner at redhat.com>
> Cc: "jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Sent: Monday, May 4, 2015 3:48:14 PM
> Subject: Re: JBDS9/Mars Performance
> 
> On 4 May 2015, at 12:59, Rastislav Wagner wrote:
> 
> >> which doc exactly ?
> >
> > this one
> > https://mojo.redhat.com/docs/DOC-1002291
> 
> There does not seem to be any internal info in this.
> 
> Can you move this to jboss.org instead ?

Ok, I will move it to jboss.org - I posted it to mojo because usually performance results are internal AFAIK.

> 
> Also I still have my same questions that is on that thread ;)
> 
Huh, I missed that! Just replied in mojo.


> And could you show the % of difference + deviance so it is not just raw
> numbers and a possible misleading average ?

Will do.
> 
> 
> 
> 
> /max
> http://about.me/maxandersen
> 

From rawagner at redhat.com  Mon May  4 11:04:32 2015
From: rawagner at redhat.com (Rastislav Wagner)
Date: Mon, 4 May 2015 11:04:32 -0400 (EDT)
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <973722533.12166315.1430742411520.JavaMail.zimbra@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
	<973722533.12166315.1430742411520.JavaMail.zimbra@redhat.com>
Message-ID: <1560494645.11163695.1430751872701.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Len DiMaggio" <ldimaggi at redhat.com>
> To: "rawagner" <rawagner at redhat.com>
> Sent: Monday, May 4, 2015 2:26:51 PM
> Subject: Re: [jbosstools-dev] JBDS9/Mars Performance
> 
> Hi Rasta!,
> 
> Thanks for following up on this with Max, as we expected - he had more
> followup questions. ;-)
> 
> Are you able to devote a consistent level of time to performance tests for
> the next several weeks?
> 
> -- Len
I will try to push some other things aside and focus on performance before JBDS9 Beta arrives.

> 
> ----- Original Message -----
> 
> | From: "Max Rydahl Andersen" <manderse at redhat.com>
> | To: "Rastislav Wagner" <rawagner at redhat.com>
> | Cc: "jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> | Sent: Monday, May 4, 2015 5:59:30 AM
> | Subject: Re: [jbosstools-dev] JBDS9/Mars Performance
> 
> | > I have a few things I'd like to ask/discuss about performance.
> 
> | I'm cc'ing this on jbosstools-dev@ so those who are working on the
> | related issues can chime in too.
> | > 1) I heard that you know about some performance issues in latest
> | > JBDS/Eclipse builds. Could you point me to where can I find details
> | > about those issues ?
> 
> | we have multiple reports over the last releases that our CDI and JPA
> | tooling gets slow on large projects.
> 
> | Latest one was discussed on irc:
> | http://transcripts.jboss.org/channel/irc.freenode.org/%23jbosstools/2015/%23jbosstools.2015-04-29.log.html
> | (look for "attiand")
> 
> | > 2) I'm just running performance tests for JBDS9 Alpha2 and will update
> | > mojo doc once I have the results.
> 
> | which doc exactly ?
> 
> | > 3) Have you noticed that "UI Responsiveness monitoring" was added in
> | > Mars M6? (you can find it in Preferences->General->Tracking). It would
> | > be cool to use it but the question is what treshold should I use ?
> | > I was thinking something around 1second, longer jobs shouldn't be
> | > running in UI thread.
> 
> | +100
> 
> | > 4) The last thing - I'm playing with a few projects in workspace
> | > (50+-, mostly eclipse plugins) and when I change required-bundle in
> | > MANIFEST whole Eclipse will freeze for 20seconds.
> | > I will have to investigate further, but is there any Dev I could talk
> | > to about similar performance issues which are (not yet) related to any
> | > component ?
> 
> | Snjezana tend to be good at finding causes, but performance is important
> | for us all, so ask away here in jbosstools-dev and #jbosstools chat.
> 
> | First you should do is grab a a few jstack's of that eclipse when it is
> | freezing and see what is showing up in the stack trace.
> 
> | If that does not reveal anything connect a profiler (jvisualvm might be
> | enough) to spot the hotspots for your case.
> 
> | /max
> | http://about.me/maxandersen
> 
> | _______________________________________________
> | jbosstools-dev mailing list
> | jbosstools-dev at lists.jboss.org
> | https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 
> --
> 
> Len DiMaggio (ldimaggi at redhat.com)
> JBoss by Red Hat
> 314 Littleton Road
> Westford, MA 01886 USA
> tel: 978.392.3179
> cell: 781.472.9912
> http://www.redhat.com
> http://community.jboss.org/people/ldimaggio
> 

From nboldt at redhat.com  Mon May  4 12:16:02 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Mon, 04 May 2015 12:16:02 -0400
Subject: [jbosstools-dev] Cleaning up old builds in
	http://download.jboss.org/jbosstools/builds/staging/
Message-ID: <55479B42.5070803@redhat.com>

FYI, I've moved some old builds out of the staging folder at 
http://download.jboss.org/jbosstools/builds/staging/ so as to avoid 
confusion with where these builds now live.

Just in case we need them resurrected (eg., because something depends on 
them, or 4.2.x needs a respin), I've moved anything from JBT 4.0 and 
earlier into OLD/, and:

JBT 4.1 -> _4.1.kepler
JBT 4.2 -> _4.2.luna
JBT 4.3 -> _4.3.mars (up to Alpha1)

I have NOT moved any old JBTIS builds, but DID move the old SOA Tools 
stuff from 3.3 into OLD/.

I've also updated the ancient README.txt (circa JBT 3.2/3.3 days) to 
README.html and it now correctly explains that new snapshots can be 
found under /mars/snapshots/.

http://download.jboss.org/jbosstools/builds/staging/README.html

http://download.jboss.org/jbosstools/mars/snapshots/builds/


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Mon May  4 14:50:41 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Mon, 04 May 2015 14:50:41 -0400
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>	<554392E9.3020907@redhat.com>	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>	<5543F12F.5000407@redhat.com>
	<2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>
Message-ID: <5547BF81.3050607@redhat.com>

Whoah, now. Tagging the tip of the 4.2.x branch and calling it something 
like 4.2.1.Final is a bad, and inaccurate plan.

If you need to dig up the SHAs for a given historical build, they can be 
found here:

http://download.jboss.org/jbosstools/builds/stable

For example, the SHAs that went into JBT 4.2.1.Final are here:

http://download.jboss.org/jbosstools/builds/stable/jbosstools-4.2.1.Final-build-core/2014-12-14_19-43-15-B320/logs/ALL_REVISIONS.txt

As to the actual steps for tagging from a SHA... I'm no gitsplainer, but 
I believe this is all you need to do:

    git tag <tagname> <SHA-of-the-commit>

If that's incorrect, I'm sure Max will correct me.

Nick

On 05/01/2015 09:23 PM, Max Rydahl Andersen wrote:
> On 1 May 2015, at 23:33, Rob Stryker wrote:
>
>> Maybe I'm missing something, but, how do we go and accurately tag
>> previous releases? Do we have the old SHA tags stored somewhere for
>> old builds?  Otherwise I don't see how its possible to go and
>> accurately tag our previous releases.
>
> That is what I asked Nick about since we have been supposed to gather
> that for all builds. Waiting for the answer.
>
> But if not there, then you can start by tagging the tip of the branch
> they should have been made on.
>
> /max
>
>
>>
>> On 05/01/2015 05:11 PM, Max Rydahl Andersen wrote:
>>> If you want the 100% method we need to build from the tag, meaning
>>> Dev need start doing their tags and declare them into the build.
>>>
>>> But can we tackle one issue at the time, please :)
>>>
>>> I would like to at least have our past final releases tagged
>>> consistently.
>>>
>>> We got it for most - just a few stands out.
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>>
>>>> On 01 May 2015, at 16:51, Rob Stryker <rstryker at redhat.com> wrote:
>>>>
>>>>> On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
>>>>> I would prefer it actually tagged the sha1 that was used instead of
>>>>> just assumed used.
>>>> Are we any closer to this happening?  What's still 'missing' to make
>>>> this a possibility?
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Tue May  5 06:35:32 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 12:35:32 +0200
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <5547BF81.3050607@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
	<5543F12F.5000407@redhat.com>
	<2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>
	<5547BF81.3050607@redhat.com>
Message-ID: <88F7E0F5-745B-4A3E-BB11-447F6E528505@redhat.com>

On 4 May 2015, at 20:50, Nick Boldt wrote:

> Whoah, now. Tagging the tip of the 4.2.x branch and calling it 
> something
> like 4.2.1.Final is a bad, and inaccurate plan.

I was mainly thinking about the sea of alpha/betas that have not been 
tagged.

> If you need to dig up the SHAs for a given historical build, they can 
> be
> found here:
>
> http://download.jboss.org/jbosstools/builds/stable
>
> For example, the SHAs that went into JBT 4.2.1.Final are here:
>
> http://download.jboss.org/jbosstools/builds/stable/jbosstools-4.2.1.Final-build-core/2014-12-14_19-43-15-B320/logs/ALL_REVISIONS.txt

I took this and massaged into a more usable format:

`jbosstools/jbosstools-aerogear,4586f4e2ccab589cc8d3f9c0a27b07cb0b60054f, 
jbosstools-4.1.2.Final`

wrote a python script that did this:

```
ERROR: jbosstools/jbosstools-aerogear: tag 'jbosstools-4.1.2.Final' not 
found.
Create 'jbosstools-4.1.2.Final' with sha: 
'4586f4e2ccab589cc8d3f9c0a27b07cb0b60054f' in 
'jbosstools/jbosstools-aerogear' ? y
Tag created!
OK: jbosstools/jbosstools-arquillian has 'jbosstools-4.1.2.Final' with 
expected sha: '512a4eb9c86e536609548f89e488e6de59a05997'
OK: jbosstools/jbosstools-base has 'jbosstools-4.1.2.Final' with 
expected sha: 'a2fc76fa5077ead6c157018c7007be78889b278b'
OK: jbosstools/jbosstools-central has 'jbosstools-4.1.2.Final' with 
expected sha: 'a67351bc616681776c4f3e98bc9dae37dbf61cbd'
OK: jbosstools/jbosstools-forge has 'jbosstools-4.1.2.Final' with 
expected sha: 'ec277568d25799042c1b45bfc9a6717ecacc3c18'
OK: jbosstools/jbosstools-hibernate has 'jbosstools-4.1.2.Final' with 
expected sha: '9b968a7902f2f3a9e3d7e8c4253683f7268e542a'
OK: jbosstools/jbosstools-javaee has 'jbosstools-4.1.2.Final' with 
expected sha: '592119339d9621a0ee8c3ce1e48dd6b1a4c4cd31'
OK: jbosstools/jbosstools-jst has 'jbosstools-4.1.2.Final' with expected 
sha: '7e2bde795ba9156ce3d1a6ea96aa29ef85e1b003'
OK: jbosstools/jbosstools-livereload has 'jbosstools-4.1.2.Final' with 
expected sha: '715cd60d1be30e8c8bf21e27328733bbf2c7d3ed'
OK: jbosstools/jbosstools-openshift has 'jbosstools-4.1.2.Final' with 
expected sha: 'a5693dad2e041a3eaf22745b7f09c58b46538b8e'
OK: jbosstools/jbosstools-portlet has 'jbosstools-4.1.2.Final' with 
expected sha: 'b78ad47e21de05d7e8fe770a0b3335de006d43bb'
ERROR: jbosstools/jbosstools-server: tag 'jbosstools-4.1.2.Final' not 
found.
Create 'jbosstools-4.1.2.Final' with sha: 
'1a43a10c94dc70af396589f46680de33333bfa6c' in 
'jbosstools/jbosstools-server' ? y
Tag created!
OK: jbosstools/jbosstools-vpe has 'jbosstools-4.1.2.Final' with expected 
sha: '86607d3ca6614b9ebe5a17205f0244676596fd8f'
OK: jbosstools/jbosstools-webservices has 'jbosstools-4.1.2.Final' with 
expected sha: 'fa9850e334f250eb1ea32951b743bf32d951e391'
```

so now for 4.1.2.Final server and aerogear is fixed.

I'm now wading through the rest I can find. "awesome - not"

/max

> As to the actual steps for tagging from a SHA... I'm no gitsplainer, 
> but
> I believe this is all you need to do:
>
> git tag <tagname> <SHA-of-the-commit>
>
> If that's incorrect, I'm sure Max will correct me.
>
> Nick
>
> On 05/01/2015 09:23 PM, Max Rydahl Andersen wrote:
>> On 1 May 2015, at 23:33, Rob Stryker wrote:
>>
>>> Maybe I'm missing something, but, how do we go and accurately tag
>>> previous releases? Do we have the old SHA tags stored somewhere for
>>> old builds?  Otherwise I don't see how its possible to go and
>>> accurately tag our previous releases.
>>
>> That is what I asked Nick about since we have been supposed to gather
>> that for all builds. Waiting for the answer.
>>
>> But if not there, then you can start by tagging the tip of the branch
>> they should have been made on.
>>
>> /max
>>
>>
>>>
>>> On 05/01/2015 05:11 PM, Max Rydahl Andersen wrote:
>>>> If you want the 100% method we need to build from the tag, meaning
>>>> Dev need start doing their tags and declare them into the build.
>>>>
>>>> But can we tackle one issue at the time, please :)
>>>>
>>>> I would like to at least have our past final releases tagged
>>>> consistently.
>>>>
>>>> We got it for most - just a few stands out.
>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>>>
>>>>
>>>>> On 01 May 2015, at 16:51, Rob Stryker <rstryker at redhat.com> wrote:
>>>>>
>>>>>> On 04/29/2015 01:54 PM, Max Rydahl Andersen wrote:
>>>>>> I would prefer it actually tagged the sha1 that was used instead 
>>>>>> of
>>>>>> just assumed used.
>>>>> Are we any closer to this happening?  What's still 'missing' to 
>>>>> make
>>>>> this a possibility?
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen


From manderse at redhat.com  Tue May  5 07:14:15 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 13:14:15 +0200
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <88F7E0F5-745B-4A3E-BB11-447F6E528505@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
	<5543F12F.5000407@redhat.com>
	<2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>
	<5547BF81.3050607@redhat.com>
	<88F7E0F5-745B-4A3E-BB11-447F6E528505@redhat.com>
Message-ID: <9E5F2D00-49E4-400A-B372-AECA123856D8@redhat.com>

On 5 May 2015, at 12:35, Max Rydahl Andersen wrote:

> so now for 4.1.2.Final server and aerogear is fixed.
> I'm now wading through the rest I can find. "awesome - not"

I've now fixed the missing Final tags for all repos that was missing 
Final's by using my hand modified[1] ALL_REVISIONS.txt files

With respect to Final tags the only component repos that was missing 
them was: server, aerogear and freemarker.

The missing Final ones are:


```
jbosstools-build missing 1 tags:
   jbosstools-4.0.0.Final

jbosstools-build-ci missing 3 tags:
   jbosstools-4.0.0.Final,
   jbosstools-4.1.1.Final,
   jbosstools-4.2.0.Final

jbosstools-build-sites missing 2 tags:
   jbosstools-4.0.0.Final,
   jbosstools-4.1.0.Final

jbosstools-download.jboss.org missing 6 tags:
   jbosstools-4.0.0.Final,
   jbosstools-4.1.0.Final,
   jbosstools-4.1.1.Final,
   jbosstools-4.2.0.Final,
   jbosstools-4.2.1.Final,
   jbosstools-4.2.2.Final
```

Nick - those are maintained by you. Do you have some way to find the 
right sha's for these ?

Note: We still are missing the milestones I'm sure we got others 
missing, but now fixed the ones that are sure.

[1] the files are not easily parseable - something we should make sure 
we have going forward.

/max
http://about.me/maxandersen

From manderse at redhat.com  Tue May  5 07:17:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 13:17:34 +0200
Subject: [jbosstools-dev] feedback on fixing missing alpha/beta/cr tags
Message-ID: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>

I updated the script I made for checking tags to also print out 
"closest"
'x' branch.

For example for jbosstools-server that gives us:

```
jbosstools-server missing 10 tags:
   jbosstools-4.1.0.Beta1 (jbosstools-4.1.0.Beta1x),
   jbosstools-4.1.1.Beta1 (jbosstools-4.1.1.Beta1x),
   jbosstools-4.1.1.CR1,
   jbosstools-4.2.0.Alpha2 (jbosstools-4.2.0.Alpha2x),
   jbosstools-4.2.0.Beta1 (jbosstools-4.2.0.Beta1x),
   jbosstools-4.2.0.Beta2 (jbosstools-4.2.0.Beta2x),
   jbosstools-4.2.0.Beta3 (jbosstools-4.2.0.Beta3x),
   jbosstools-4.2.3.Beta1,
   jbosstools-4.2.3.CR1,
   jbosstools-4.3.0.Alpha1 (jbosstools-4.3.0.Alpha1x)
```

Full list at: https://gist.github.com/maxandersen/78ffedc1edb9569b35b2

Using the tip of the branch seem to be the simplest way to fix this with 
the 'best' tag possible.

Anyone with good arguments for or against doing this ?

(I already have a script ready that can fix this this way, but I wanted 
make sure I'm not
missing something obviously bad about this idea)

/max
http://about.me/maxandersen

From manderse at redhat.com  Tue May  5 07:23:07 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 13:23:07 +0200
Subject: [jbosstools-dev] JBDS9/Mars Performance
In-Reply-To: <714763418.11160365.1430751509161.JavaMail.zimbra@redhat.com>
References: <69045145.10946815.1430731061525.JavaMail.zimbra@redhat.com>
	<BC4E398D-F9FD-4B0F-BD51-FE006F3B6FC6@redhat.com>
	<374247742.10973358.1430737161870.JavaMail.zimbra@redhat.com>
	<5FF2BC4A-37D8-41BA-AFF5-68410C528D4D@redhat.com>
	<789549334.11130153.1430748969708.JavaMail.zimbra@redhat.com>
	<714763418.11160365.1430751509161.JavaMail.zimbra@redhat.com>
Message-ID: <2C96D2D1-5F75-416E-BE9C-662C4857CFD6@redhat.com>

>>> https://mojo.redhat.com/docs/DOC-1002291
>>
>> There does not seem to be any internal info in this.
>>
>> Can you move this to jboss.org instead ?
>
> Ok, I will move it to jboss.org

Thanks. post the link when you get it there.

> I posted it to mojo because usually performance results are internal AFAIK.

We aren't testing performance of runtimes so this is not a concern IMO.

/max
http://about.me/maxandersen

From noreply at turtleandsharkvacationrentals.com  Tue May  5 07:29:13 2015
From: noreply at turtleandsharkvacationrentals.com (New-Canadian-Meds)
Date: Tue, 5 May 2015 16:29:13 +0500
Subject: [jbosstools-dev] Become one of our premium clients who enjoy all
	our privileges and save huge money!
Message-ID: <4C1DA423.5073637@turtleandsharkvacationrentals.com>

   

		Deliberation with another crescent city because i everybody karl
will contribute. Reproduction, this mother preparation for
infringement, has years so our products. 

		Me
		ds
		4f
		or
		3M
		en

Vi
Ci
Ci
Le
Pr
 ag
al
al
vi
op
 ra
is
is
tr
ec

 S
a 
ia

of

t 

Ta

bs

 $0
$1
$2
$2
$0
 .9
.6
.5
.5
.4
 9
5
0
0
5

		Me
		ds
		1f
		or
		4W
		om
		en

Ac
Cl
De
Fe
Fe
 om
om
fl
ma
ma
 pl
id
uc
le
le
 ia

an
 C
 V

ia
ia

li
gr

s 
a 

 $1
$0
$1
$1
$0
 .7
.4
.2
.1
.7
 5
5
5
1
2

 Fa
Sp
No
Vi st
ec
 p
sa  w
ia
re
,M or
l 
sc
as ld
in
ri
te wi
te
pt
rc de
rn
io
ar  s
et
n 
d, hi
 p
re
Ec pp
ri
qu
he in
ce
ir
ck g 
s 
ed

   A
 2
 O
 1 no
4/
nl
00 ny
7 
y 
%  mo
cu
re
Au us
st
li
th  d
om
ab
en el
er
le
ti iv
 s
 s
c  er
up
up
Me y 
po
pl
ds  
rt
ie

rs

		>> Enter Here 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/aa1c7430/attachment-0001.html 

From nboldt at redhat.com  Tue May  5 08:57:34 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 05 May 2015 08:57:34 -0400
Subject: [jbosstools-dev] ATTENTION REQUIRED: missing tags
In-Reply-To: <9E5F2D00-49E4-400A-B372-AECA123856D8@redhat.com>
References: <1271287A-83DB-423D-AF9F-DC9A317D56CA@redhat.com>
	<CAJXFskYo9uz2LQyDz5vWyS-3gcsd3cMW7dxeprW7NgF6HqpfVw@mail.gmail.com>
	<6904A361-AAD5-4464-8390-C45457C43580@redhat.com>
	<CAJXFskY1g9rLyq1KhtQr7fLvoEv2UzkY5Mvzrd8s2PjHKx5kOA@mail.gmail.com>
	<A1DC19F0-612E-421A-9171-B079C5DD6A64@redhat.com>
	<554392E9.3020907@redhat.com>
	<54F6E03B-EA39-4BEA-BCE1-EF26C6493A33@redhat.com>
	<5543F12F.5000407@redhat.com>
	<2EB59747-BED2-4744-B50A-C55B8D8B51D2@redhat.com>
	<5547BF81.3050607@redhat.com>
	<88F7E0F5-745B-4A3E-BB11-447F6E528505@redhat.com>
	<9E5F2D00-49E4-400A-B372-AECA123856D8@redhat.com>
Message-ID: <5548BE3E.1060502@redhat.com>

> ```
> jbosstools-build missing 1 tags:
>    jbosstools-4.0.0.Final
>
> jbosstools-build-ci missing 3 tags:
>    jbosstools-4.0.0.Final,
>    jbosstools-4.1.1.Final,
>    jbosstools-4.2.0.Final
>
> jbosstools-build-sites missing 2 tags:
>    jbosstools-4.0.0.Final,
>    jbosstools-4.1.0.Final
>
> jbosstools-download.jboss.org missing 6 tags:
>    jbosstools-4.0.0.Final,
>    jbosstools-4.1.0.Final,
>    jbosstools-4.1.1.Final,
>    jbosstools-4.2.0.Final,
>    jbosstools-4.2.1.Final,
>    jbosstools-4.2.2.Final
> ```
> Nick - those are maintained by you. Do you have some way to find the
> right sha's for these ?

Only thing I can immediately think of:

1. get dates of each release
2. crawl through commits on the master or 4.n.x branches looking for the 
last commit before that date in github.
3. use that commit to create the tags

> Note: We still are missing the milestones I'm sure we got others
> missing, but now fixed the ones that are sure.
>
> [1] the files are not easily parseable - something we should make sure
> we have going forward.

We have buildinfo.json now.

Nick

From nboldt at redhat.com  Tue May  5 08:59:23 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 05 May 2015 08:59:23 -0400
Subject: [jbosstools-dev] feedback on fixing missing alpha/beta/cr tags
In-Reply-To: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>
References: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>
Message-ID: <5548BEAB.4070802@redhat.com>

Makes sense for missing tags up to the first .Final (the Beta1x, Beta2x, 
etc. branches).

Does not compute for CR1, Final, and all future maintenance as these all 
come from the same 4.n.x branch.

On 05/05/2015 07:17 AM, Max Rydahl Andersen wrote:
> I updated the script I made for checking tags to also print out
> "closest"
> 'x' branch.
>
> For example for jbosstools-server that gives us:
>
> ```
> jbosstools-server missing 10 tags:
>     jbosstools-4.1.0.Beta1 (jbosstools-4.1.0.Beta1x),
>     jbosstools-4.1.1.Beta1 (jbosstools-4.1.1.Beta1x),
>     jbosstools-4.1.1.CR1,
>     jbosstools-4.2.0.Alpha2 (jbosstools-4.2.0.Alpha2x),
>     jbosstools-4.2.0.Beta1 (jbosstools-4.2.0.Beta1x),
>     jbosstools-4.2.0.Beta2 (jbosstools-4.2.0.Beta2x),
>     jbosstools-4.2.0.Beta3 (jbosstools-4.2.0.Beta3x),
>     jbosstools-4.2.3.Beta1,
>     jbosstools-4.2.3.CR1,
>     jbosstools-4.3.0.Alpha1 (jbosstools-4.3.0.Alpha1x)
> ```
>
> Full list at: https://gist.github.com/maxandersen/78ffedc1edb9569b35b2
>
> Using the tip of the branch seem to be the simplest way to fix this with
> the 'best' tag possible.
>
> Anyone with good arguments for or against doing this ?
>
> (I already have a script ready that can fix this this way, but I wanted
> make sure I'm not
> missing something obviously bad about this idea)
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From mistria at redhat.com  Tue May  5 11:12:44 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 17:12:44 +0200
Subject: [jbosstools-dev] Upcoming release of Locus
Message-ID: <5548DDEC.9030807@redhat.com>

Hi all,

The JBoss Tools - Integration Stack requires some new version of 
external libs, so we need to release Locus 1.2.0 soon to deliver those 
libs as OSGi bundles in time.
Here are the changes that will be part of this release: 
https://issues.jboss.org/browse/LOCUS/fixforversion/12326796/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel

If you're concerned, please give a try to the 1.2.0-SNAPSHOT build at 
https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.Final/update.site-1.2.0.Final.zip-unzip 
immediately and send an alarm as an answer to this mail if you notice 
something wrong.
The plan is to release it on Thurday (May 7th).

Cheers
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/6ece7924/attachment.html 

From manderse at redhat.com  Tue May  5 11:16:10 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 17:16:10 +0200
Subject: [jbosstools-dev] feedback on fixing missing alpha/beta/cr tags
In-Reply-To: <5548BEAB.4070802@redhat.com>
References: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>
	<5548BEAB.4070802@redhat.com>
Message-ID: <A55CEE90-997E-4777-911B-E07F058C0670@redhat.com>

On 5 May 2015, at 14:59, Nick Boldt wrote:

> Makes sense for missing tags up to the first .Final (the Beta1x, 
> Beta2x,
> etc. branches).

yup.

> Does not compute for CR1, Final, and all future maintenance as these 
> all
> come from the same 4.n.x branch.

I did not spot any such in the output, did you ?

Otherwise I'll go ahead and run the same script, but in 
"beast-create-tag"-mode
/max

>
> On 05/05/2015 07:17 AM, Max Rydahl Andersen wrote:
>> I updated the script I made for checking tags to also print out
>> "closest"
>> 'x' branch.
>>
>> For example for jbosstools-server that gives us:
>>
>> ```
>> jbosstools-server missing 10 tags:
>>   jbosstools-4.1.0.Beta1 (jbosstools-4.1.0.Beta1x),
>>   jbosstools-4.1.1.Beta1 (jbosstools-4.1.1.Beta1x),
>>   jbosstools-4.1.1.CR1,
>>   jbosstools-4.2.0.Alpha2 (jbosstools-4.2.0.Alpha2x),
>>   jbosstools-4.2.0.Beta1 (jbosstools-4.2.0.Beta1x),
>>   jbosstools-4.2.0.Beta2 (jbosstools-4.2.0.Beta2x),
>>   jbosstools-4.2.0.Beta3 (jbosstools-4.2.0.Beta3x),
>>   jbosstools-4.2.3.Beta1,
>>   jbosstools-4.2.3.CR1,
>>   jbosstools-4.3.0.Alpha1 (jbosstools-4.3.0.Alpha1x)
>> ```
>>
>> Full list at: 
>> https://gist.github.com/maxandersen/78ffedc1edb9569b35b2
>>
>> Using the tip of the branch seem to be the simplest way to fix this 
>> with
>> the 'best' tag possible.
>>
>> Anyone with good arguments for or against doing this ?
>>
>> (I already have a script ready that can fix this this way, but I 
>> wanted
>> make sure I'm not
>> missing something obviously bad about this idea)
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From manderse at redhat.com  Tue May  5 11:17:47 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 05 May 2015 17:17:47 +0200
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <5548DDEC.9030807@redhat.com>
References: <5548DDEC.9030807@redhat.com>
Message-ID: <6DD5E360-C085-416D-A19F-83B2D84CC59D@redhat.com>

On 5 May 2015, at 17:12, Mickael Istria wrote:

> Hi all,
>
> The JBoss Tools - Integration Stack requires some new version of 
> external libs,

...and JBoss Tools core, in form of the dmr.jar.

/max

> so we need to release Locus 1.2.0 soon to deliver those libs as OSGi 
> bundles in time.
> Here are the changes that will be part of this release: 
> https://issues.jboss.org/browse/LOCUS/fixforversion/12326796/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
>
> If you're concerned, please give a try to the 1.2.0-SNAPSHOT build at 
> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.Final/update.site-1.2.0.Final.zip-unzip 
> immediately and send an alarm as an answer to this mail if you notice 
> something wrong.
> The plan is to release it on Thurday (May 7th).
>
> Cheers
> -- 
> 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>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen


From nboldt at redhat.com  Tue May  5 12:07:09 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 05 May 2015 12:07:09 -0400
Subject: [jbosstools-dev] feedback on fixing missing alpha/beta/cr tags
In-Reply-To: <A55CEE90-997E-4777-911B-E07F058C0670@redhat.com>
References: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>
	<5548BEAB.4070802@redhat.com>
	<A55CEE90-997E-4777-911B-E07F058C0670@redhat.com>
Message-ID: <5548EAAD.8080004@redhat.com>

>> Does not compute for CR1, Final, and all future maintenance as these all
>> come from the same 4.n.x branch.
> I did not spot any such in the output, did you ?

Your email below only shows associated branches for the *.0.Alphas and 
Betas. So I think you're good.

> Otherwise I'll go ahead and run the same script, but in
> "beast-create-tag"-mode

I don't understand what you mean here ("beast-*" mode?), but ignoring 
everything after the "but...", +1.

>> On 05/05/2015 07:17 AM, Max Rydahl Andersen wrote:
>>> I updated the script I made for checking tags to also print out
>>> "closest"
>>> 'x' branch.
>>>
>>> For example for jbosstools-server that gives us:
>>>
>>> ```
>>> jbosstools-server missing 10 tags:
>>>   jbosstools-4.1.0.Beta1 (jbosstools-4.1.0.Beta1x),
>>>   jbosstools-4.1.1.Beta1 (jbosstools-4.1.1.Beta1x),
>>>   jbosstools-4.1.1.CR1,
>>>   jbosstools-4.2.0.Alpha2 (jbosstools-4.2.0.Alpha2x),
>>>   jbosstools-4.2.0.Beta1 (jbosstools-4.2.0.Beta1x),
>>>   jbosstools-4.2.0.Beta2 (jbosstools-4.2.0.Beta2x),
>>>   jbosstools-4.2.0.Beta3 (jbosstools-4.2.0.Beta3x),
>>>   jbosstools-4.2.3.Beta1,
>>>   jbosstools-4.2.3.CR1,
>>>   jbosstools-4.3.0.Alpha1 (jbosstools-4.3.0.Alpha1x)
>>> ```
>>>
>>> Full list at: https://gist.github.com/maxandersen/78ffedc1edb9569b35b2
>>>
>>> Using the tip of the branch seem to be the simplest way to fix this with
>>> the 'best' tag possible.
>>>
>>> Anyone with good arguments for or against doing this ?
>>>
>>> (I already have a script ready that can fix this this way, but I wanted
>>> make sure I'm not
>>> missing something obviously bad about this idea)
>>>
>>> /max
>>> http://about.me/maxandersen
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Tue May  5 13:36:50 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 5 May 2015 13:36:50 -0400 (EDT)
Subject: [jbosstools-dev] feedback on fixing missing alpha/beta/cr tags
In-Reply-To: <5548EAAD.8080004@redhat.com>
References: <3C7978F2-3EDF-41D2-A29B-31255F837EE7@redhat.com>
	<5548BEAB.4070802@redhat.com>
	<A55CEE90-997E-4777-911B-E07F058C0670@redhat.com>
	<5548EAAD.8080004@redhat.com>
Message-ID: <D5454518-F44E-45A2-A262-87BA351C5E7C@redhat.com>



On 05 May 2015, at 18:07, Nick Boldt <nboldt at redhat.com> wrote:

>>> Does not compute for CR1, Final, and all future maintenance as these all
>>> come from the same 4.n.x branch.
>> I did not spot any such in the output, did you ?
> 
> Your email below only shows associated branches for the *.0.Alphas and Betas. So I think you're good.

Read again: 

Full list is here:
https://gist.github.com/maxandersen/78ffedc1edb9569b35b2

But yes it's all supposed to be no final release branches. 

> 
>> Otherwise I'll go ahead and run the same script, but in
>> "beast-create-tag"-mode
> 
> I don't understand what you mean here ("beast-*" mode?), but ignoring everything after the "but...", +1.

You don't know beast mode? Honey badgers of the world feel sad. 

/max


> 
>>>> On 05/05/2015 07:17 AM, Max Rydahl Andersen wrote:
>>>> I updated the script I made for checking tags to also print out
>>>> "closest"
>>>> 'x' branch.
>>>> 
>>>> For example for jbosstools-server that gives us:
>>>> 
>>>> ```
>>>> jbosstools-server missing 10 tags:
>>>>  jbosstools-4.1.0.Beta1 (jbosstools-4.1.0.Beta1x),
>>>>  jbosstools-4.1.1.Beta1 (jbosstools-4.1.1.Beta1x),
>>>>  jbosstools-4.1.1.CR1,
>>>>  jbosstools-4.2.0.Alpha2 (jbosstools-4.2.0.Alpha2x),
>>>>  jbosstools-4.2.0.Beta1 (jbosstools-4.2.0.Beta1x),
>>>>  jbosstools-4.2.0.Beta2 (jbosstools-4.2.0.Beta2x),
>>>>  jbosstools-4.2.0.Beta3 (jbosstools-4.2.0.Beta3x),
>>>>  jbosstools-4.2.3.Beta1,
>>>>  jbosstools-4.2.3.CR1,
>>>>  jbosstools-4.3.0.Alpha1 (jbosstools-4.3.0.Alpha1x)
>>>> ```
>>>> 
>>>> Full list at: https://gist.github.com/maxandersen/78ffedc1edb9569b35b2
>>>> 
>>>> Using the tip of the branch seem to be the simplest way to fix this with
>>>> the 'best' tag possible.
>>>> 
>>>> Anyone with good arguments for or against doing this ?
>>>> 
>>>> (I already have a script ready that can fix this this way, but I wanted
>>>> make sure I'm not
>>>> missing something obviously bad about this idea)
>>>> 
>>>> /max
>>>> http://about.me/maxandersen
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> 
>>> --
>>> Nick Boldt :: JBoss by Red Hat
>>> Productization Lead :: JBoss Tools & Dev Studio
>>> http://nick.divbyzero.com
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> 
>> 
>> /max
>> http://about.me/maxandersen
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/b81d7433/attachment-0001.html 

From pleacu at redhat.com  Tue May  5 13:51:27 2015
From: pleacu at redhat.com (Paul Leacu)
Date: Tue, 5 May 2015 13:51:27 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <643093878.12665544.1430847403000.JavaMail.zimbra@redhat.com>
Message-ID: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>


   Hey Nick/Mickael -
       I ran into an issue with the mars jbosstools-multiple TP (Alpha2 and Beta1-SNAPSHOT).  They are pulling from the old locus area (mockito):
  
https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.50.0.Alpha2/ https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.50.0.Beta1-SNAPSHOT/

   <!-- JBIDE-12815 JBoss Tools Locus bundles: not quite ready to be included  --> 
   <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="slicer" includeSource="true" type="InstallableUnit"> 
   <repository location="http://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.1.1.Final/update.site-1.1.1.Final.zip-unzip/"/> 
   <unit id="org.jboss.tools.locus.mockito" version="1.9.5.Final_patched_TEIIDDES-1681-v20131024-0922-B58"/>  

   Which is causing a failure with conflicting mockito builds when I pull from the new locus area (B58, B77).  

   WDYT?  Should I Jira it?

   Thkx,
            --paull

From p.g.richardson at phantomjinx.co.uk  Tue May  5 13:57:10 2015
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Tue, 05 May 2015 18:57:10 +0100
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <5548DDEC.9030807@redhat.com>
References: <5548DDEC.9030807@redhat.com>
Message-ID: <55490476.6010302@phantomjinx.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/05/15 16:12, Mickael Istria wrote:
> Hi all,
> 
> The JBoss Tools - Integration Stack requires some new version of external libs, so we need to 
> release Locus 1.2.0 soon to deliver those libs as OSGi bundles in time. Here are the changes
> that will be part of this release: 
> https://issues.jboss.org/browse/LOCUS/fixforversion/12326796/?selectedTab=com.atlassian.jira.jira-
projects-plugin:version-summary-panel
>
>  If you're concerned, please give a try to the 1.2.0-SNAPSHOT build at 
> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.Fin
al/update.site-1.2.0.Final.zip-unzip
>
> 
immediately and send an alarm as an answer to this mail if you notice something wrong.
> The plan is to release it on Thurday (May 7th).
> 
> Cheers -- 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>

Hey Mickael,

I would like to test Designer with this but given we only take a JBTIS version as our TP in our
main pom, I am currently ignorant as to how?

If you could indulge me ...

Thanks

PGR


- -- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVJBHYACgkQcthLMIwdEb1vngCg+OwPWFbS67uLs00sK39YuYo7
sYQAni1z607aBG8wD7h5GgpANmFdwEQb
=3TL+
-----END PGP SIGNATURE-----

From manderse at redhat.com  Tue May  5 13:58:27 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 5 May 2015 13:58:27 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
Message-ID: <5E651625-C5A7-4D40-84B0-419E4B3AC058@redhat.com>

Yes Jira it.

If I understand it right we need a new target platform release for core but that doesn't sound right so would like to know the exact error you are seeing. 

/max
http://about.me/maxandersen


> On 05 May 2015, at 19:51, Paul Leacu <pleacu at redhat.com> wrote:
> 
> 
>   Hey Nick/Mickael -
>       I ran into an issue with the mars jbosstools-multiple TP (Alpha2 and Beta1-SNAPSHOT).  They are pulling from the old locus area (mockito):
> 
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.50.0.Alpha2/ https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/targetplatforms/jbosstools-multiple/4.50.0.Beta1-SNAPSHOT/
> 
>   <!-- JBIDE-12815 JBoss Tools Locus bundles: not quite ready to be included  --> 
>   <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="slicer" includeSource="true" type="InstallableUnit"> 
>   <repository location="http://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.1.1.Final/update.site-1.1.1.Final.zip-unzip/"/> 
>   <unit id="org.jboss.tools.locus.mockito" version="1.9.5.Final_patched_TEIIDDES-1681-v20131024-0922-B58"/>  
> 
>   Which is causing a failure with conflicting mockito builds when I pull from the new locus area (B58, B77).  
> 
>   WDYT?  Should I Jira it?
> 
>   Thkx,
>            --paull
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From mistria at redhat.com  Tue May  5 14:07:51 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 20:07:51 +0200
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
Message-ID: <554906F7.9020405@redhat.com>

On 05/05/2015 07:51 PM, Paul Leacu wrote:
>     Which is causing a failure with conflicting mockito builds when I pull from the new locus area (B58, B77).
Do you mean you're also adding mockito in your target-platform, but with 
another version? If yes, then you should simply remove it to make sure 
you're using the same version as JBoss Tools.
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/96c7969c/attachment.html 

From manderse at redhat.com  Tue May  5 15:11:56 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 5 May 2015 15:11:56 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <554906F7.9020405@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
Message-ID: <B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>

Locus shouldn't be producing different content between releases So that sounds weird too...

/max
http://about.me/maxandersen


> On 05 May 2015, at 20:08, Mickael Istria <mistria at redhat.com> wrote:
> 
>> On 05/05/2015 07:51 PM, Paul Leacu wrote:
>>    Which is causing a failure with conflicting mockito builds when I pull from the new locus area (B58, B77).  
> Do you mean you're also adding mockito in your target-platform, but with another version? If yes, then you should simply remove it to make sure you're using the same version as JBoss Tools.
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/75633309/attachment.html 

From pleacu at redhat.com  Tue May  5 15:22:56 2015
From: pleacu at redhat.com (Paul Leacu)
Date: Tue, 5 May 2015 15:22:56 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
Message-ID: <1984872576.12722345.1430853776045.JavaMail.zimbra@redhat.com>


   The mockito content is the same - it's just the build number that's tagged onto the end of the
   version string:

   <unit id="org.jboss.tools.locus.mockito" version="1.9.5.Final_patched_TEIIDDES-1681-v20131024-0922-B58"/>
   <unit id="org.jboss.tools.locus.mockito" version="1.9.5.Final_patched_TEIIDDES-1681-v20131024-0922-B77"/> 

   I'll just remove it from the JBTIS TP and I'll pick up the JBT TP mockito.  It was my first reaction anyway.

   Thkx,
          --paull



----- Original Message -----
> From: "Max Rydahl Andersen" <manderse at redhat.com>
> To: "Mickael Istria" <mistria at redhat.com>
> Cc: "Paul Leacu" <pleacu at redhat.com>, "Nick Boldt" <nboldt at redhat.com>, "jbosstools-dev jbosstools-dev"
> <jbosstools-dev at lists.jboss.org>
> Sent: Tuesday, May 5, 2015 3:11:56 PM
> Subject: Re: [jbosstools-dev] Mars jbosstools-multiple TP issue
> 
> Locus shouldn't be producing different content between releases So that
> sounds weird too...
> 
> /max
> http://about.me/maxandersen
> 
> 
> > On 05 May 2015, at 20:08, Mickael Istria <mistria at redhat.com> wrote:
> > 
> >> On 05/05/2015 07:51 PM, Paul Leacu wrote:
> >>    Which is causing a failure with conflicting mockito builds when I pull
> >>    from the new locus area (B58, B77).
> > Do you mean you're also adding mockito in your target-platform, but with
> > another version? If yes, then you should simply remove it to make sure
> > you're using the same version as JBoss Tools.
> > --
> > Mickael Istria
> > Eclipse developer at JBoss, by Red Hat
> > My blog - My Tweets
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 

From nboldt at redhat.com  Tue May  5 15:23:46 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 05 May 2015 15:23:46 -0400
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
Message-ID: <554918C2.9090002@redhat.com>

Latest Locus 1.2 build is here:

http://download.jboss.org/jbosstools/mars/snapshots/builds/jbosstools-locus.site_master/2015-05-04_14-16-19-B77/all/repo/plugins/

So... since the artifacts include the BUILD_NUMBER and BUILD_ID in them, 
it therefore follows that each build will have uniquely versioned 
artifacts, even if bitwise they're the same as the previous B76 build.

Is that what you mean by "producing different content between releases" ?

If so, do we need to change the builds so they omit the timestamp and 
build number in their qualifiers, and just use 1.3.0.Final instead of 
1.3.0.Final-v20150430-1349-B77?

On 05/05/2015 03:11 PM, Max Rydahl Andersen wrote:
> Locus shouldn't be producing different content between releases So that
> sounds weird too...
>
> /max
> http://about.me/maxandersen
>
>
> On 05 May 2015, at 20:08, Mickael Istria <mistria at redhat.com
> <mailto:mistria at redhat.com>> wrote:
>
>> On 05/05/2015 07:51 PM, Paul Leacu wrote:
>>>     Which is causing a failure with conflicting mockito builds when I pull from the new locus area (B58, B77).
>> Do you mean you're also adding mockito in your target-platform, but
>> with another version? If yes, then you should simply remove it to make
>> sure you're using the same version as JBoss Tools.
>> --
>> 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>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From mistria at redhat.com  Tue May  5 15:26:13 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 21:26:13 +0200
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
Message-ID: <55491955.2050801@redhat.com>

On 05/05/2015 09:11 PM, Max Rydahl Andersen wrote:
> Locus shouldn't be producing different content between releases So 
> that sounds weird too...
If we want this, it means that we need reproducible qualifiers, so to 
get rid of the BUILD_NUMBER in Locus qualifiers.
We made a few steps towards that point in the past (using 
last-modification timestamps instead of build timestamps), but didn't 
get to the point where we specifically decided to have reproducible 
qualifiers. Since we've used specific build qualifiers in previous 
version, it seems impossible that Locus 1.2 produces the same qualifier 
without bad hacks.
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/0390cdb5/attachment-0001.html 

From mistria at redhat.com  Tue May  5 15:27:25 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 21:27:25 +0200
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <554918C2.9090002@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
	<554918C2.9090002@redhat.com>
Message-ID: <5549199D.5090301@redhat.com>

On 05/05/2015 09:23 PM, Nick Boldt wrote:
> If so, do we need to change the builds so they omit the timestamp and 
> build number in their qualifiers, and just use 1.3.0.Final instead of 
> 1.3.0.Final-v20150430-1349-B77?
For Locus, timestamp is already a last-modification timestamp. Only the 
BUILD_NUMBER is moving between different builds.
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/4c69031e/attachment.html 

From nboldt at redhat.com  Tue May  5 16:06:16 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 05 May 2015 16:06:16 -0400
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <5549199D.5090301@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
	<554918C2.9090002@redhat.com> <5549199D.5090301@redhat.com>
Message-ID: <554922B8.2070302@redhat.com>

So, we could drop BUILD_NUMBER, since it's simply causing churn in 
target platform definitions and not really providing value here.

Two ways to do this...

A) change this to remove BUILD_NUMBER:

https://github.com/jbosstools/jbosstools-locus/blob/master/pom.xml#L214

B) change jobs to not use the -Phudson profile, which does nothing here 
except to add BUILD_NUMBER.

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-locus.site_master/configure

Thoughts? I'd be for removing the profile AND updating the job. Seems 
more complete.

On 05/05/2015 03:27 PM, Mickael Istria wrote:
> On 05/05/2015 09:23 PM, Nick Boldt wrote:
>> If so, do we need to change the builds so they omit the timestamp and
>> build number in their qualifiers, and just use 1.3.0.Final instead of
>> 1.3.0.Final-v20150430-1349-B77?
> For Locus, timestamp is already a last-modification timestamp. Only the
> BUILD_NUMBER is moving between different builds.
> --
> 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>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From mistria at redhat.com  Tue May  5 16:07:38 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 22:07:38 +0200
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <554922B8.2070302@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
	<554918C2.9090002@redhat.com> <5549199D.5090301@redhat.com>
	<554922B8.2070302@redhat.com>
Message-ID: <5549230A.4000502@redhat.com>

On 05/05/2015 10:06 PM, Nick Boldt wrote:
> Thoughts? I'd be for removing the profile AND updating the job. Seems 
> more complete.
+1
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/8388d193/attachment.html 

From manderse at redhat.com  Tue May  5 16:12:38 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 5 May 2015 16:12:38 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <5549199D.5090301@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554906F7.9020405@redhat.com>
	<B1FDC4A1-3761-4AE5-A623-699CAF9EEB74@redhat.com>
	<554918C2.9090002@redhat.com> <5549199D.5090301@redhat.com>
Message-ID: <518F9E45-AD8F-46CF-9080-A16864D1DF2E@redhat.com>

Michael, 

Locus is not supposed to change. That was a requirement from day one. See the root readme. 

That should not be happening. 

/max
http://about.me/maxandersen


> On 05 May 2015, at 21:27, Mickael Istria <mistria at redhat.com> wrote:
> 
>> On 05/05/2015 09:23 PM, Nick Boldt wrote:
>> If so, do we need to change the builds so they omit the timestamp and build number in their qualifiers, and just use 1.3.0.Final instead of 1.3.0.Final-v20150430-1349-B77? 
> For Locus, timestamp is already a last-modification timestamp. Only the BUILD_NUMBER is moving between different builds.
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/c0d583c8/attachment.html 

From mistria at redhat.com  Tue May  5 16:19:35 2015
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 05 May 2015 22:19:35 +0200
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
Message-ID: <554925D7.9010102@redhat.com>

This is actually the story of https://issues.jboss.org/browse/LOCUS-13 .

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/fa777316/attachment.html 

From manderse at redhat.com  Tue May  5 17:29:32 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 5 May 2015 17:29:32 -0400 (EDT)
Subject: [jbosstools-dev] Mars jbosstools-multiple TP issue
In-Reply-To: <554925D7.9010102@redhat.com>
References: <28076213.12672513.1430848287540.JavaMail.zimbra@redhat.com>
	<554925D7.9010102@redhat.com>
Message-ID: <A69B62B0-5850-4C5E-A5D6-AE05D606164A@redhat.com>

That Jira seem to mix qe needs for our core components with what the needs/requirements for locus is. They are very different. So yeah, this should be fixed. We said it early on in locus and it's how orbit works too. 

/max
http://about.me/maxandersen


> On 05 May 2015, at 22:20, Mickael Istria <mistria at redhat.com> wrote:
> 
> This is actually the story of https://issues.jboss.org/browse/LOCUS-13 .
> 
> -- 
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat
> My blog - My Tweets
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150505/f7c03e70/attachment.html 

From p.g.richardson at phantomjinx.co.uk  Wed May  6 05:15:09 2015
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Wed, 06 May 2015 10:15:09 +0100
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <2005820783.12690643.1430849774187.JavaMail.zimbra@redhat.com>
References: <5548DDEC.9030807@redhat.com> <55490476.6010302@phantomjinx.co.uk>
	<2005820783.12690643.1430849774187.JavaMail.zimbra@redhat.com>
Message-ID: <5549DB9D.5000706@phantomjinx.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey all,

Just testing TD build with 4.2.3.CR1a and it fails!

The salient details is:

Could not find "org.jboss.tools.locus.jcip.annotations/1.0.0.Final-v20131024-0922-B75"

See below for further details.

PGR

Build and install the teiid designer plugins
Executing mvn clean install  -P target-platform,multiple.target
- -Dmaven.repo.local=/home/phantomjinx/programming/java/tdesigner/git/../m2-repository
- -Dno.jbosstools.site -Dtycho.localArtifacts=ignore
[INFO] Scanning for projects...
[INFO] Computing target platform for MavenProject:
org.jboss.tools.teiid.plugins.teiid:org.teiid.runtime.client:9.1.0-SNAPSHOT @
/home/phantomjinx/programming/java/tdesigner/git/plugins/teiid/org.teiid.runtime.client/pom.xml
[INFO] Adding repository
http://download.jboss.org/jbosstools/updates/requirements/bpel/1.0.4.v201412041949
[INFO] Adding repository
https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0-SNAPS
HOT/update.site-1.2.0-SNAPSHOT.zip-unzip
[ERROR] Internal error: java.lang.RuntimeException: Failed to resolve target definition
/home/phantomjinx/programming/java/tdesigner/git/../m2-repository/org/jboss/tools/integration-stack/
target-platform/4.2.3.CR1a/target-platform-4.2.3.CR1a-base.target:
Could not find "org.jboss.tools.locus.jcip.annotations/1.0.0.Final-v20131024-0922-B75" in the
repositories of the current location -> [Help 1]
org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: Failed to
resolve target definition
/home/phantomjinx/programming/java/tdesigner/git/../m2-repository/org/jboss/tools/integration-stack/
target-platform/4.2.3.CR1a/target-platform-4.2.3.CR1a-base.target
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:164)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethod ... ... ... ...


On 05/05/15 19:16, Paul Leacu wrote:
> 
> Hey PJ - Change the td.tpc.version in your TD pom to 4.2.3.CR1a.  It has the new locus in it. 
> --paull
> 
> 
> 
> ----- Original Message -----
>> From: "phantomjinx" <p.g.richardson at phantomjinx.co.uk> To: "Mickael Istria"
>> <mistria at redhat.com>, "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org> Sent:
>> Tuesday, May 5, 2015 1:57:10 PM Subject: Re: [jbosstools-dev] Upcoming release of Locus
>> 
> On 05/05/15 16:12, Mickael Istria wrote:
>>>> Hi all,
>>>> 
>>>> The JBoss Tools - Integration Stack requires some new version of external libs, so we
>>>> need to release Locus 1.2.0 soon to deliver those libs as OSGi bundles in time. Here are
>>>> the changes that will be part of this release: 
>>>> https://issues.jboss.org/browse/LOCUS/fixforversion/12326796/?selectedTab=com.atlassian.jira.ji
ra-
>
>>>> 
projects-plugin:version-summary-panel
>>>> 
>>>> If you're concerned, please give a try to the 1.2.0-SNAPSHOT build at 
>>>> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.
Fin
>
>>>> 
al/update.site-1.2.0.Final.zip-unzip
>>>> 
>>>> 
> immediately and send an alarm as an answer to this mail if you notice something wrong.
>>>> The plan is to release it on Thurday (May 7th).
>>>> 
>>>> Cheers -- 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>
> 
> Hey Mickael,
> 
> I would like to test Designer with this but given we only take a JBTIS version as our TP in
> our main pom, I am currently ignorant as to how?
> 
> If you could indulge me ...
> 
> Thanks
> 
> PGR
> 
> 
>> _______________________________________________ jbosstools-dev mailing list 
>> jbosstools-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> 

- -- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVJ250ACgkQcthLMIwdEb09CgCfdRqaCfImSbPE3RqUi1VY6CQY
w5UAniiYXJY45IOwAPVP2i3eOi7jA4fo
=KfCi
-----END PGP SIGNATURE-----

From p.g.richardson at phantomjinx.co.uk  Wed May  6 11:15:33 2015
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Wed, 06 May 2015 16:15:33 +0100
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <1261342813.12986188.1430917947912.JavaMail.zimbra@redhat.com>
References: <5548DDEC.9030807@redhat.com> <55490476.6010302@phantomjinx.co.uk>
	<2005820783.12690643.1430849774187.JavaMail.zimbra@redhat.com>
	<5549DB9D.5000706@phantomjinx.co.uk>
	<1261342813.12986188.1430917947912.JavaMail.zimbra@redhat.com>
Message-ID: <554A3015.6050601@phantomjinx.co.uk>

Paul,

No need for apologies. Was testing as per mistria's original mail.

Anyway, building from your instructions works fine and all good.

PGR


On 06/05/15 14:12, Paul Leacu wrote:
>  
>    Hey PJ -
>        Sorry - we're working through some build number issues.  I don't want to build/release to nexus a new
>    JBTIS TP before locus goes final.  You can test TD by doing this:
> 
>    git clone -o origin https://github.com/jbosstools/jbosstools-integration-stack.git ./jbosstools-integration-stack
>    cd ./jbosstools-integration-stack/target-platform
>    git checkout jbosstools-4.2.x
>    mvn -Pmirror -U -Dtycho.localArtifacts=ignore clean install
> 
>    Keep your jbtis TP version at 4.2.3.CR1a and then rebuild TD - it should pick up the correct TP from your local 
>    m2 repo.
> 
>    Let me know...
> 
>           --paull
> 
> 
> ----- Original Message -----
>> From: "phantomjinx" <p.g.richardson at phantomjinx.co.uk>
>> To: "Paul Leacu" <pleacu at redhat.com>, "Mickael Istria" <mistria at redhat.com>
>> Cc: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
>> Sent: Wednesday, May 6, 2015 5:15:09 AM
>> Subject: Re: [jbosstools-dev] Upcoming release of Locus
>>
> Hey all,
> 
> Just testing TD build with 4.2.3.CR1a and it fails!
> 
> The salient details is:
> 
> Could not find
> "org.jboss.tools.locus.jcip.annotations/1.0.0.Final-v20131024-0922-B75"
> 
> See below for further details.
> 
> PGR
> 
> Build and install the teiid designer plugins
> Executing mvn clean install  -P target-platform,multiple.target
> -
> -Dmaven.repo.local=/home/phantomjinx/programming/java/tdesigner/git/../m2-repository
> -Dno.jbosstools.site -Dtycho.localArtifacts=ignore
> [INFO] Scanning for projects...
> [INFO] Computing target platform for MavenProject:
> org.jboss.tools.teiid.plugins.teiid:org.teiid.runtime.client:9.1.0-SNAPSHOT @
> /home/phantomjinx/programming/java/tdesigner/git/plugins/teiid/org.teiid.runtime.client/pom.xml
> [INFO] Adding repository
> http://download.jboss.org/jbosstools/updates/requirements/bpel/1.0.4.v201412041949
> [INFO] Adding repository
> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0-SNAPS
> HOT/update.site-1.2.0-SNAPSHOT.zip-unzip
> [ERROR] Internal error: java.lang.RuntimeException: Failed to resolve target
> definition
> /home/phantomjinx/programming/java/tdesigner/git/../m2-repository/org/jboss/tools/integration-stack/
> target-platform/4.2.3.CR1a/target-platform-4.2.3.CR1a-base.target:
> Could not find
> "org.jboss.tools.locus.jcip.annotations/1.0.0.Final-v20131024-0922-B75" in
> the
> repositories of the current location -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.RuntimeException: Failed to
> resolve target definition
> /home/phantomjinx/programming/java/tdesigner/git/../m2-repository/org/jboss/tools/integration-stack/
> target-platform/4.2.3.CR1a/target-platform-4.2.3.CR1a-base.target
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:164)
>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>         at sun.reflect.DelegatingMethod ... ... ... ...
> 
> 
> On 05/05/15 19:16, Paul Leacu wrote:
>>>>
>>>> Hey PJ - Change the td.tpc.version in your TD pom to 4.2.3.CR1a.  It has
>>>> the new locus in it.
>>>> --paull
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "phantomjinx" <p.g.richardson at phantomjinx.co.uk> To: "Mickael
>>>>> Istria"
>>>>> <mistria at redhat.com>, "jbosstools-dev jbosstools-dev"
>>>>> <jbosstools-dev at lists.jboss.org> Sent:
>>>>> Tuesday, May 5, 2015 1:57:10 PM Subject: Re: [jbosstools-dev] Upcoming
>>>>> release of Locus
>>>>>
>>>> On 05/05/15 16:12, Mickael Istria wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The JBoss Tools - Integration Stack requires some new version of
>>>>>>> external libs, so we
>>>>>>> need to release Locus 1.2.0 soon to deliver those libs as OSGi bundles
>>>>>>> in time. Here are
>>>>>>> the changes that will be part of this release:
>>>>>>> https://issues.jboss.org/browse/LOCUS/fixforversion/12326796/?selectedTab=com.atlassian.jira.ji
> ra-
>>>>
>>>>>>>
> projects-plugin:version-summary-panel
>>>>>>>
>>>>>>> If you're concerned, please give a try to the 1.2.0-SNAPSHOT build at
>>>>>>> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.
> Fin
>>>>
>>>>>>>
> al/update.site-1.2.0.Final.zip-unzip
>>>>>>>
>>>>>>>
>>>> immediately and send an alarm as an answer to this mail if you notice
>>>> something wrong.
>>>>>>> The plan is to release it on Thurday (May 7th).
>>>>>>>
>>>>>>> Cheers -- 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>
>>>>
>>>> Hey Mickael,
>>>>
>>>> I would like to test Designer with this but given we only take a JBTIS
>>>> version as our TP in
>>>> our main pom, I am currently ignorant as to how?
>>>>
>>>> If you could indulge me ...
>>>>
>>>> Thanks
>>>>
>>>> PGR
>>>>
>>>>
>>>>> _______________________________________________ jbosstools-dev mailing
>>>>> list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
> 
>>

-- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister


From mistria at redhat.com  Wed May  6 11:24:10 2015
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 06 May 2015 17:24:10 +0200
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <554A3015.6050601@phantomjinx.co.uk>
References: <5548DDEC.9030807@redhat.com>
	<55490476.6010302@phantomjinx.co.uk>	<2005820783.12690643.1430849774187.JavaMail.zimbra@redhat.com>	<5549DB9D.5000706@phantomjinx.co.uk>	<1261342813.12986188.1430917947912.JavaMail.zimbra@redhat.com>
	<554A3015.6050601@phantomjinx.co.uk>
Message-ID: <554A321A.6070000@redhat.com>

On 05/06/2015 05:15 PM, phantomjinx wrote:
> Paul,
>
> No need for apologies. Was testing as per mistria's original mail.
> Anyway, building from your instructions works fine and all good.
Now that things are working for you, I have some news.
In order to prevent this issue to happen in the future (see 
https://issues.jboss.org/browse/LOCUS-13 ) , we've made a change on how 
we set the qualifier for Locus bundles, so that the qualifier has 
changed (again).
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150506/207b2abf/attachment.html 

From mistria at redhat.com  Wed May  6 13:12:05 2015
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 06 May 2015 19:12:05 +0200
Subject: [jbosstools-dev] Upcoming release of Locus
In-Reply-To: <1160768498.13116408.1430932258043.JavaMail.zimbra@redhat.com>
References: <5548DDEC.9030807@redhat.com> <55490476.6010302@phantomjinx.co.uk>
	<2005820783.12690643.1430849774187.JavaMail.zimbra@redhat.com>
	<5549DB9D.5000706@phantomjinx.co.uk>
	<1261342813.12986188.1430917947912.JavaMail.zimbra@redhat.com>
	<554A3015.6050601@phantomjinx.co.uk> <554A321A.6070000@redhat.com>
	<1160768498.13116408.1430932258043.JavaMail.zimbra@redhat.com>
Message-ID: <554A4B65.5000201@redhat.com>

On 05/06/2015 07:10 PM, Paul Leacu wrote:
>     Hey Mickael -
>         Will you still produce a 1.2.0.Final locus tomorrow (Thursday)?
Yes, that's still the plan. Unless you discover something that would 
make it worth delaying it.

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150506/5403d882/attachment.html 

From manderse at redhat.com  Thu May  7 08:30:32 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 07 May 2015 14:30:32 +0200
Subject: [jbosstools-dev] mass tagging..
Message-ID: <FFB9627C-B1D9-416A-9837-FE954A353CAD@redhat.com>

Hey,

Just FYI, I went ahead and made tags for the releases that were missing 
but we had an approximate branch for.

That will explain why you see tags coming in when doing a pull or fetch.

Thanks,
/max
http://about.me/maxandersen

From mistria at redhat.com  Thu May  7 09:12:39 2015
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 07 May 2015 15:12:39 +0200
Subject: [jbosstools-dev] JBoss Tools Locus repository 1.2.0.Final is
	released
Message-ID: <554B64C7.8030300@redhat.com>

JBoss Tools Locus, the repository that we used to share common 3rd-party 
libraries as OSGi bundles, has been released in version 1.2.0.Final

See 
https://issues.jboss.org/issues/?jql=project%20%3D%20LOCUS%20AND%20fixVersion%20%3D%201.2.0%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC 
for the list of changes that are included in this release.
You can access the Locus repository here: 
http://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.Final/update.site-1.2.0.Final.zip-unzip/ 
, in order to install some bundles or update your target-platforms.
The commit from which this release was generated was tagged as 
1.2.0.Final on the related GitHub repository: 
https://github.com/jbosstools/jbosstools-locus/tree/1.2.0.Final

The master stream of Locus is now in version 1.3.0-SNAPSHOT.
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150507/84058405/attachment.html 

From nboldt at redhat.com  Thu May  7 12:26:51 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 07 May 2015 12:26:51 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
Message-ID: <554B924B.6090505@redhat.com>

Here is a proposal for a change to the JBoss Tools and Red Hat JBoss 
Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.

https://github.com/jbosstools/jbosstools-target-platforms/pull/142/

It consists in the following change(s):

* JBIDE-19776: Create and use Mars M7 target-platform

p2diff reports:

https://issues.jboss.org/secure/attachment/12389427/jbosstools.p2diff.txt
https://issues.jboss.org/secure/attachment/12389428/jbdevstudio.p2diff.txt

Please review the above PR(s), as it will be applied as soon as possible.

You can use the following to build & test the target-platform locally 
against your component(s).

Build target-platform:
   cd jbosstools-target-platforms/jbosstools/multiple
   git checkout 
https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
   mvn clean install

Or, without hub:
   cd jbosstools-target-platforms/jbosstools/multiple
   git fetch origin pull/142/head && git checkout FETCH_HEAD
   mvn clean install

Try with just built target-platform:
   $ cd /path/to/your/component
   $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT -Pmultiple.target
--

If you want to perform a scripted install of the entire target platform
into your local Eclipse or JBDS instance, you can now do so with this
script:

https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/installFromTarget.sh

Usage is documented in the above script, and in this README:

https://github.com/jbosstools/jbosstools-target-platforms/tree/master#updating-versions-of-ius-in-target-files

--


-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From mistria at redhat.com  Thu May  7 13:44:14 2015
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 07 May 2015 19:44:14 +0200
Subject: [jbosstools-dev] Microservices
Message-ID: <554BA46E.70109@redhat.com>

Hi all,

As I'm following some discussions about microservices (which are more or 
less regular Jax-RS services in many cases), I'm wondering whether JBoss 
Tools could embrace the word "Microservices" in some ways, for example 
in wizards or archetypes.
Would a "Microservices" category in the Import wizard, that would repeat 
most Jax-RS wizards be a good idea ?
Or just prefixing all occurence of the "service" word with "(micro)" ?

WDYT?
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150507/d574fe94/attachment-0001.html 

From ggastald at redhat.com  Thu May  7 13:50:31 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Thu, 07 May 2015 14:50:31 -0300
Subject: [jbosstools-dev] Microservices
In-Reply-To: <554BA46E.70109@redhat.com>
References: <554BA46E.70109@redhat.com>
Message-ID: <554BA5E7.8020709@redhat.com>

I think that the term "Microservices" is related to deployment of apps 
instead of the artifacts you produce to achieve that.

That said, I think it would make sense to have a Microservice category 
if you intend to create a project that should run by itself (eg. A Maven 
project with Wildfly-swarm configured in its pom.xml for example).

Something like New Project -> New JavaEE Microservice project

On 05/07/2015 02:44 PM, Mickael Istria wrote:
> Hi all,
>
> As I'm following some discussions about microservices (which are more 
> or less regular Jax-RS services in many cases), I'm wondering whether 
> JBoss Tools could embrace the word "Microservices" in some ways, for 
> example in wizards or archetypes.
> Would a "Microservices" category in the Import wizard, that would 
> repeat most Jax-RS wizards be a good idea ?
> Or just prefixing all occurence of the "service" word with "(micro)" ?
>
> WDYT?
> -- 
> 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>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150507/3dabe8b7/attachment.html 

From akazakov at exadel.com  Thu May  7 14:32:55 2015
From: akazakov at exadel.com (Alexey Kazakov)
Date: Thu, 07 May 2015 11:32:55 -0700
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <554B924B.6090505@redhat.com>
References: <554B924B.6090505@redhat.com>
Message-ID: <554BAFD7.7040403@exadel.com>


The new TP includes the updated Sapphire v. 9.0.0.201505051659.
Sapphire was updated in M7 and this version is not compatible with 
Sapphire v.9.0.0.201408261741 which was included in Mars TP before (M1-M6)

Batch and Arquillian tools require Sapphire. It's not a big deal for us 
to migrate Batch and Arquillian to new Sapphire API.
But the problem is that the new Sapphire (M7) has 
*RequiredExecutionEnvironment: JavaSE-1.8*

If we can't require Java 8 for Batch and Arquillian then we have to 
switch to Sapphire 8.2 from 9.0 in our TP.
Sapphire 8.2 supports Mars but Mars update site includes Sapphire 9.0. only.

How are we going to deal with that?


On 05/07/2015 09:26 AM, Nick Boldt wrote:
> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
> Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
>
> https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
>
> It consists in the following change(s):
>
> * JBIDE-19776: Create and use Mars M7 target-platform
>
> p2diff reports:
>
> https://issues.jboss.org/secure/attachment/12389427/jbosstools.p2diff.txt
> https://issues.jboss.org/secure/attachment/12389428/jbdevstudio.p2diff.txt
>
> Please review the above PR(s), as it will be applied as soon as possible.
>
> You can use the following to build & test the target-platform locally
> against your component(s).
>
> Build target-platform:
>     cd jbosstools-target-platforms/jbosstools/multiple
>     git checkout
> https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
>     mvn clean install
>
> Or, without hub:
>     cd jbosstools-target-platforms/jbosstools/multiple
>     git fetch origin pull/142/head && git checkout FETCH_HEAD
>     mvn clean install
>
> Try with just built target-platform:
>     $ cd /path/to/your/component
>     $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT -Pmultiple.target
> --
>
> If you want to perform a scripted install of the entire target platform
> into your local Eclipse or JBDS instance, you can now do so with this
> script:
>
> https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/installFromTarget.sh
>
> Usage is documented in the above script, and in this README:
>
> https://github.com/jbosstools/jbosstools-target-platforms/tree/master#updating-versions-of-ius-in-target-files
>
> --
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150507/a44074ec/attachment.html 

From mistria at redhat.com  Thu May  7 15:25:20 2015
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 07 May 2015 21:25:20 +0200
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <554BAFD7.7040403@exadel.com>
References: <554B924B.6090505@redhat.com> <554BAFD7.7040403@exadel.com>
Message-ID: <554BBC20.4070902@redhat.com>

On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
>
> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
> Sapphire was updated in M7 and this version is not compatible with 
> Sapphire v.9.0.0.201408261741 which was included in Mars TP before (M1-M6)
> Batch and Arquillian tools require Sapphire. It's not a big deal for 
> us to migrate Batch and Arquillian to new Sapphire API.
> But the problem is that the new Sapphire (M7) has 
> *RequiredExecutionEnvironment: JavaSE-1.8*
Too bad this wasn't spotted earlier. Is anyone following the Sapphire 
mailing-list or bugzilla component?

> If we can't require Java 8 for Batch and Arquillian then we have to 
> switch to Sapphire 8.2 from 9.0 in our TP.
> Sapphire 8.2 supports Mars but Mars update site includes Sapphire 9.0. 
> only.
> How are we going to deal with that?
Well, Java 7 has reached end-of-life a few days ago, so I would support 
the idea of requiring Java 8 for those components. If they are part of 
JBDS default package, then it means that JBDS will also require Java 8.
If we want to keep Java 7, we can simply include only Sapphire 8.2 in 
the target-platform and keep Sapphire 9.0 out. But I guess Sapphire 8.2 
and 9.0 cannot be installed simultaneously; can they? If not, then we 
need to make sure no other project that is important to us and that we 
want to work together with JBoss Tools relies on newer Sapphire.
So is anyone aware of some other project that requires Sapphire and that 
we'd like to keep compatible with?
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150507/a5da8ca3/attachment.html 

From manderse at redhat.com  Fri May  8 03:32:30 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 08 May 2015 09:32:30 +0200
Subject: [jbosstools-dev] Microservices
In-Reply-To: <554BA46E.70109@redhat.com>
References: <554BA46E.70109@redhat.com>
Message-ID: <FF5FAF5F-5867-47D3-89C0-4531A07D1DE2@redhat.com>

>
>
> As I'm following some discussions about microservices (which are more 
> or less regular Jax-RS services in many cases), I'm wondering whether 
> JBoss Tools could embrace the word "Microservices" in some ways, for 
> example in wizards or archetypes.

I tend to think that using todays buzzwords are a bad way of configuring 
your IDE UI.

> Would a "Microservices" category in the Import wizard, that would 
> repeat most Jax-RS wizards be a good idea ?
> Or just prefixing all occurence of the "service" word with "(micro)" ?
> WDYT?

none of those does anything besides create a confusion imo.

For me its more relevant to make sure our tools continues to not have 
lockins into specific systems where it can be avoided
(i.e. we use maven a lot of places, but most of our plugins does not 
require it. fuse/switchyard are exceptions to this currently
and I believe it will hurt them in the long run)

Our server adapters is optimised for wildfly, but we also have a variant 
called deploy only server that works great for any tech
that just need content uploaded to a remote place.

Our debugging and jmx monitoring should work with any java vm. No matter 
if a micro service or a full blown app server.

Our wizards is optimised for WTP but we don't prevent users to use them 
on projects that are non WTP (they might miss some features, but thats 
life if you don't want to tell the IDE about your project runtime needs)

WTP's utility jar is going to be playing a vital role in "micro 
services", they are the ones that should be deployable to spring boot, 
wildfly-swarm etc. so
all our existing tooling should work with that (at least). If not - that 
is a problem.

With that said - I think with the new central update having some 
quickstarts with instructions on how to use our tools with micro service 
runtimes would
be a great thing to have.

Showing the world that IDE tools are *NOT* tied to monolithic 
architectures.

/max
http://about.me/maxandersen

From manderse at redhat.com  Fri May  8 03:55:51 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 08 May 2015 09:55:51 +0200
Subject: [jbosstools-dev] JBoss Tools Locus repository 1.2.0.Final is
 released
In-Reply-To: <554B64C7.8030300@redhat.com>
References: <554B64C7.8030300@redhat.com>
Message-ID: <0A780F98-82A5-4692-A054-2A96D58563D0@redhat.com>

On 7 May 2015, at 15:12, Mickael Istria wrote:

> JBoss Tools Locus, the repository that we used to share common 
> 3rd-party libraries as OSGi bundles, has been released in version 
> 1.2.0.Final

*use* to share. Its not something we plan to drop ;)

> See 
> https://issues.jboss.org/issues/?jql=project%20%3D%20LOCUS%20AND%20fixVersion%20%3D%201.2.0%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC 
> for the list of changes that are included in this release.
> You can access the Locus repository here: 
> http://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0.Final/update.site-1.2.0.Final.zip-unzip/ 
> , in order to install some bundles or update your target-platforms.
> The commit from which this release was generated was tagged as 
> 1.2.0.Final on the related GitHub repository: 
> https://github.com/jbosstools/jbosstools-locus/tree/1.2.0.Final

Thanks - sounds like this was tested and verified to work in IS and 
core, so now its time to start using the dmr in locus instead of the 4-5 
copies we have ;)

/max
http://about.me/maxandersen


From manderse at redhat.com  Fri May  8 04:02:24 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 08 May 2015 10:02:24 +0200
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <554BBC20.4070902@redhat.com>
References: <554B924B.6090505@redhat.com> <554BAFD7.7040403@exadel.com>
	<554BBC20.4070902@redhat.com>
Message-ID: <DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>

On 7 May 2015, at 21:25, Mickael Istria wrote:

> On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
>>
>> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
>> Sapphire was updated in M7 and this version is not compatible with 
>> Sapphire v.9.0.0.201408261741 which was included in Mars TP before 
>> (M1-M6)
>> Batch and Arquillian tools require Sapphire. It's not a big deal for 
>> us to migrate Batch and Arquillian to new Sapphire API.
>> But the problem is that the new Sapphire (M7) has 
>> *RequiredExecutionEnvironment: JavaSE-1.8*
> Too bad this wasn't spotted earlier. Is anyone following the Sapphire 
> mailing-list or bugzilla component?


Sapphire announced it here: 
https://www.eclipse.org/forums/index.php/t/890531/ back in January and 
yes, really bad we did not catch that.

But we did monitor the release train but Sapphire did not put this 
change until M7. Where it is IMO is too late as said over here 
https://www.eclipse.org/forums/index.php/m/1694326

But Konstantin from Sapphire seem to not care about that ;/

>> If we can't require Java 8 for Batch and Arquillian then we have to 
>> switch to Sapphire 8.2 from 9.0 in our TP.
>> Sapphire 8.2 supports Mars but Mars update site includes Sapphire 
>> 9.0. only.
>> How are we going to deal with that?
> Well, Java 7 has reached end-of-life a few days ago, so I would 
> support the idea of requiring Java 8 for those components. If they are 
> part of JBDS default package, then it means that JBDS will also 
> require Java 8.
> If we want to keep Java 7, we can simply include only Sapphire 8.2 in 
> the target-platform and keep Sapphire 9.0 out. But I guess Sapphire 
> 8.2 and 9.0 cannot be installed simultaneously; can they?

Konstantin claims they can - as long as you don't include two colliding 
features that requires them.

> If not, then we need to make sure no other project that is important 
> to us and that we want to work together with JBoss Tools relies on 
> newer Sapphire.
> So is anyone aware of some other project that requires Sapphire and 
> that we'd like to keep compatible with?

I've raised question internally to see if any objections against raising 
to Java 8 since Java 7 is EOL'ed now *and* it seems its usage is 
declining faster than Java 6 did.

/max
http://about.me/maxandersen

From nboldt at redhat.com  Fri May  8 14:51:55 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 08 May 2015 14:51:55 -0400
Subject: [jbosstools-dev] New location of the source files for
	earlyaccess.properties
Message-ID: <554D05CB.3090407@redhat.com>

If you are a developer who is producing content which is tagged as Early 
Access in JBoss Central, this email applies to you. Or, if you're 
involved in releasing new discovery plugins to JBoss Central (Paul, 
Mickael, myself), this email applies to you.

For everyone else, it's just an FYI.

---

In order to avoid confusion concerning which version is the latest for a 
given stream of builds (master vs. stable branch), and to streamline the 
release process to handle both JBT/JBDS releases and their associated 
(but later) JBTIS/JBDSIS releases, I've moved stuff around so it's more 
obvious where the latest versions come from.

Note: this applies to the Mars releases only.

Thus, here are the source files to update if/when things are added to 
the list of things we include in Central which are Early Access:

* 
http://download.jboss.org/jbosstools/mars/snapshots/updates/earlyaccess.properties/ 
{stream}/jbosstools-earlyaccess.properties

* 
https://devstudio.redhat.com/9.0/snapshots/updates/earlyaccess.properties/ 
{stream}/devstudio-earlyaccess.properties

When those are updated in github, they will cascade into the Central 
plugins when rebuilt (such that when in offline mode there's still a 
backup/default list), and also into the creation of the Central and 
Early Access *Discovery* sites.

For changes related to new versions of IS features, this may require a 
rebuild of jbosstools-discovery project or will simply require copying 
the new properties on top of those released versions elsewhere on 
devstudio.redhat.com or download.jboss.org.

Which version of the properties file should be used for a given version 
of JBT/JBDS is still controlled here:

http://download.jboss.org/jbosstools/configuration/ide-config.properties

Any questions about this reorg, see these JIRA or ask in this thread:

* https://issues.jboss.org/browse/JBIDE-19346
* https://issues.jboss.org/browse/JBDS-3208

Thanks,

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Mon May 11 04:34:18 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 10:34:18 +0200
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
	jbosstools-arquillian_master #282
References: <70886434.689.1431256460841.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
Message-ID: <0A880784-2049-4925-89D7-D19D350901FD@redhat.com>

Anyone with info on why vncserver is failing to run on jenkins for 
arquillian now ?

/max
http://about.me/maxandersen
Forwarded message:

> From: ci-builds at redhat.com
> To: manderse at redhat.com
> Subject: Build failed in Jenkins: jbosstools-arquillian_master #282
> Date: Sun, 10 May 2015 07:14:20 -0400 (EDT)
>
> See 
> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/282/>
>
> ------------------------------------------
> Started by build flow jbosstools-buildflow_master#162
> [EnvInject] - Loading node environment variables.
> Building remotely on dev218-virt1 in workspace 
> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/>
> Fetching changes from the remote Git repository
> Fetching upstream changes from 
> git://github.com/jbosstools/jbosstools-arquillian.git
> Checking out Revision 85c91abfefba2f39607e73e6912f4f7cfc1beddf 
> (origin/master)
> Starting xvnc
> [jbosstools-arquillian_master] $ vncserver :89 -geometry 1920x1080
> FATAL: Cannot run program "vncserver" (in directory 
> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>: 
> java.io.IOException: error=2, No such file or directory
> java.io.IOException: Cannot run program "vncserver" (in directory 
> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>: 
> java.io.IOException: error=2, No such file or directory
> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
> 	at hudson.Proc$LocalProc.<init>(Proc.java:244)
> 	at hudson.Proc$LocalProc.<init>(Proc.java:216)
> 	at hudson.Launcher$LocalLauncher.launch(Launcher.java:773)
> 	at hudson.Launcher$ProcStarter.start(Launcher.java:353)
> 	at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:998)
> 	at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:965)
> 	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> 	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> 	at hudson.remoting.Request$2.run(Request.java:328)
> 	at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> 	at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> 	at hudson.remoting.Engine$1$1.run(Engine.java:63)
> 	at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.io.IOException: error=2, No such 
> file or directory
> 	at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
> 	at java.lang.ProcessImpl.start(ProcessImpl.java:65)
> 	at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
> 	... 16 more


From max.andersen at redhat.com  Mon May 11 04:45:29 2015
From: max.andersen at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 10:45:29 +0200
Subject: [jbosstools-dev] New location of the source files for
 earlyaccess.properties
In-Reply-To: <554D05CB.3090407@redhat.com>
References: <554D05CB.3090407@redhat.com>
Message-ID: <4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>


> In order to avoid confusion concerning which version is the latest for 
> a
> given stream of builds (master vs. stable branch), and to streamline 
> the
> release process to handle both JBT/JBDS releases and their associated
> (but later) JBTIS/JBDSIS releases, I've moved stuff around so it's 
> more
> obvious where the latest versions come from.
>
> Note: this applies to the Mars releases only.
>
> Thus, here are the source files to update if/when things are added to
> the list of things we include in Central which are Early Access:
>
> *
> http://download.jboss.org/jbosstools/mars/snapshots/updates/earlyaccess.properties/
> {stream}/jbosstools-earlyaccess.properties
>
> *
> https://devstudio.redhat.com/9.0/snapshots/updates/earlyaccess.properties/
> {stream}/devstudio-earlyaccess.properties

Sorry for being dumb here, but these do not look like the *source* files 
- those are their destination; where users will get the mappings from
when running eclipse.

> When those are updated in github, they will cascade into the Central
> plugins when rebuilt (such that when in offline mode there's still a
> backup/default list), and also into the creation of the Central and
> Early Access *Discovery* sites.

Where is the *actual* source in github ?

I would expect these to live inside jbosstools-discovery project.

/max
http://about.me/maxandersen


From mistria at redhat.com  Mon May 11 04:48:57 2015
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 11 May 2015 10:48:57 +0200
Subject: [jbosstools-dev] New location of the source files for
	earlyaccess.properties
In-Reply-To: <4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
References: <554D05CB.3090407@redhat.com>
	<4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
Message-ID: <55506CF9.7050900@redhat.com>

On 05/11/2015 10:45 AM, Max Rydahl Andersen wrote:
> I would expect these to live inside jbosstools-discovery project.
I'm trying an answer there, Nick may correct me later.
So far, these files do not require any compilation, generation, 
packaging, deployment effort. So it seems to be best to only have them 
where they're expected in the end rather than having them in some repo 
and having to implement some additional deployment steps.
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150511/04f9730b/attachment.html 

From manderse at redhat.com  Mon May 11 05:05:49 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 11:05:49 +0200
Subject: [jbosstools-dev] simple memory leaks...
Message-ID: <C8E4BBD1-343C-4207-BC65-CE36F0522A79@redhat.com>

Hey,

Just reading through some recently closed memory leak bugs in Eclipse 
Platform and realising
how easy it is to forget to set references to null in ones dispose() 
method sometimes ;)

The bug is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=436225
and gerrit is at https://git.eclipse.org/r/#/c/36201/17

What is noticeable here its the fixes are mainly about ensuring not to 
hold on to a selection forever
in a view. It will slowly but steadily leak over time.

Just a reminder to check ones dispose() and listener methods ;)

/max
http://about.me/maxandersen

From max.andersen at redhat.com  Mon May 11 06:26:56 2015
From: max.andersen at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 12:26:56 +0200
Subject: [jbosstools-dev] New location of the source files for
 earlyaccess.properties
In-Reply-To: <55506CF9.7050900@redhat.com>
References: <554D05CB.3090407@redhat.com>
	<4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
	<55506CF9.7050900@redhat.com>
Message-ID: <B88D443D-50C1-4B61-B5B7-228240C86C58@redhat.com>

On 11 May 2015, at 10:48, Mickael Istria wrote:

> On 05/11/2015 10:45 AM, Max Rydahl Andersen wrote:
>> I would expect these to live inside jbosstools-discovery project.
> I'm trying an answer there, Nick may correct me later.
> So far, these files do not require any compilation, generation, 
> packaging, deployment effort.

There is testing and that it affects all installs so pushing these 
directly is not really sensical IMO.

> So it seems to be best to only have them where they're expected in the 
> end rather than having them in some repo and having to implement some 
> additional deployment steps.

download.jboss.org has zero tagging, testing or control at the moment so 
its not where I would like to put
things directly.

So the *source* of the files is at some location in 
https://github.com/jbosstools/jbosstools-download.jboss.org and then 
separate one for jbdevstudio ?

I found 10 different ones in jbosstools-download.jboss.org...should we 
remove some of them ?

/max
http://about.me/maxandersen

From manderse at redhat.com  Mon May 11 06:29:50 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 12:29:50 +0200
Subject: [jbosstools-dev] simple memory leaks...
In-Reply-To: <C8E4BBD1-343C-4207-BC65-CE36F0522A79@redhat.com>
References: <C8E4BBD1-343C-4207-BC65-CE36F0522A79@redhat.com>
Message-ID: <B1BF504F-DF27-4464-B0A7-EC117771CA96@redhat.com>

On 11 May 2015, at 11:05, Max Rydahl Andersen wrote:

> Hey,
>
> Just reading through some recently closed memory leak bugs in Eclipse
> Platform and realising
> how easy it is to forget to set references to null in ones dispose()
> method sometimes ;)
>
> The bug is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=436225
> and gerrit is at https://git.eclipse.org/r/#/c/36201/17
>
> What is noticeable here its the fixes are mainly about ensuring not to
> hold on to a selection forever
> in a view. It will slowly but steadily leak over time.
>
> Just a reminder to check ones dispose() and listener methods ;)

ha...a few seconds after I posted this it turns out the fix here
caused massive regressions since there code expect some of this state to 
always
be there.

lesson of story - don't rely on state, always have a fallback plan ;)

/max
http://about.me/maxandersen

From max.andersen at redhat.com  Mon May 11 08:02:29 2015
From: max.andersen at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 14:02:29 +0200
Subject: [jbosstools-dev] New location of the source files for
 earlyaccess.properties
In-Reply-To: <B88D443D-50C1-4B61-B5B7-228240C86C58@redhat.com>
References: <554D05CB.3090407@redhat.com>
	<4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
	<55506CF9.7050900@redhat.com>
	<B88D443D-50C1-4B61-B5B7-228240C86C58@redhat.com>
Message-ID: <FDE3F0DE-B17C-41E6-88E7-0B658DFBC0C7@redhat.com>

On 11 May 2015, at 12:26, Max Rydahl Andersen wrote:

> On 11 May 2015, at 10:48, Mickael Istria wrote:
>
>> On 05/11/2015 10:45 AM, Max Rydahl Andersen wrote:
>>> I would expect these to live inside jbosstools-discovery project.
>> I'm trying an answer there, Nick may correct me later.
>> So far, these files do not require any compilation, generation, 
>> packaging, deployment effort.
>
> There is testing and that it affects all installs so pushing these 
> directly is not really sensical IMO.
>
>> So it seems to be best to only have them where they're expected in 
>> the end rather than having them in some repo and having to implement 
>> some additional deployment steps.
>
> download.jboss.org has zero tagging, testing or control at the moment 
> so its not where I would like to put
> things directly.
>
> So the *source* of the files is at some location in 
> https://github.com/jbosstools/jbosstools-download.jboss.org and then 
> separate one for jbdevstudio ?
>
> I found 10 different ones in jbosstools-download.jboss.org...should we 
> remove some of them ?

Thanks for explanation on irc mickael.

The *Source* is here: 
https://github.com/jbosstools/jbosstools-download.jboss.org/tree/master/jbosstools/mars/snapshots/updates/earlyaccess.properties
in 4.3.mars and master folders.

What I don't grok from this is why we are now introducing yet another 
naming standard/convention when we in 
https://issues.jboss.org/browse/JBDS-3208
agreed on this:

mars/
    snapshots
    staging
    development
    stable

Why do we need a 2nd level under snapshots called master and 4.3.mars 
when that is already supposed to be covered by snapshots and staging 
(and eventually development/stable) ?

/max
http://about.me/maxandersen


From mistria at redhat.com  Mon May 11 08:21:38 2015
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 11 May 2015 14:21:38 +0200
Subject: [jbosstools-dev] New location of the source files for
	earlyaccess.properties
In-Reply-To: <FDE3F0DE-B17C-41E6-88E7-0B658DFBC0C7@redhat.com>
References: <554D05CB.3090407@redhat.com>
	<4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
	<55506CF9.7050900@redhat.com>
	<B88D443D-50C1-4B61-B5B7-228240C86C58@redhat.com>
	<FDE3F0DE-B17C-41E6-88E7-0B658DFBC0C7@redhat.com>
Message-ID: <55509ED2.5090404@redhat.com>

On 05/11/2015 02:02 PM, Max Rydahl Andersen wrote:
> Why do we need a 2nd level under snapshots called master and 4.3.mars 
> when that is already supposed to be covered by snapshots and staging 
> (and eventually development/stable) ?
Currently, the process of creating a good 'staging' directory is not 
only a matter of letting CI put its output in a different folder.
Ouput of CI jobs (whether master or stabilization branch) go under 
snapshots/.
In order to stage, we take the output of snapshots/<some_jobs>_4.3.mars 
and turn it into something more test-friendly into staging/. The various 
steps are described in 
https://github.com/jbdevstudio/jbdevstudio-devdoc/blob/master/release_guide/9.x/JBT_Staging_for_QE.adoc
-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150511/61b3e501/attachment-0001.html 

From p.g.richardson at phantomjinx.co.uk  Mon May 11 14:23:17 2015
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Mon, 11 May 2015 19:23:17 +0100
Subject: [jbosstools-dev] Advice on use of apache.directory.browser plugins
Message-ID: <5550F395.3040707@phantomjinx.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Wanted to get a handle on the way forward for use of bundles from update sites outside of JBT and
JBT-IS.

Teiid Designer has the ability to model connections to LDAP servers. Up until this point, we have
created the modelling UI from scratch but I have found that
org.apache.directory.studio.ldapbrowser has a superior set of UI widgets that Designer could make
use of. While experimenting I have appended the directory update site [1] to our eclipse TP but
long term, if everything works okay, I would prefer a most resiliant strategy to avoid just
situations as their update site suddenly disappearing.

Can I get some advice on how to proceed with this, in that should the update site be appended to
the JBT TP? Should their update site be mirrored? Is this a non-starter?

Cheers

PGR

[1] http://directory.apache.org/studio/update/2.x/

- -- 
Paul Richardson

  * p.g.richardson at phantomjinx.co.uk
  * p.g.richardson at redhat.com
  * pgrichardson at linux.com

"I know exactly who reads the papers ...

  * The Daily Mirror is read by people who think they run the country.
  * The Guardian is read by people who think they ought to run the country.
  * The Times is read by people who do actually run the country.
  * The Daily Mail is read by the wives of the people who run the country.
  * The Financial Times is read by the people who own the country.
  * The Morning Star is read by the people who think the country ought to be run by another country.
  * The Daily Telegraph is read by the people who think it is."

Jim Hacker, Yes Minister

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVQ85UACgkQcthLMIwdEb0d6gCfSvOiTlcXnYFGwnzTW4VNiNx7
3JAAoK4I2Xb5YT4CnIvF70guReALtOnN
=LLn9
-----END PGP SIGNATURE-----

From max.andersen at redhat.com  Mon May 11 15:21:24 2015
From: max.andersen at redhat.com (Max Rydahl Andersen)
Date: Mon, 11 May 2015 21:21:24 +0200
Subject: [jbosstools-dev] New location of the source files for
 earlyaccess.properties
In-Reply-To: <55509ED2.5090404@redhat.com>
References: <554D05CB.3090407@redhat.com>
	<4749E279-D328-490D-9652-9D8AF7B49182@redhat.com>
	<55506CF9.7050900@redhat.com>
	<B88D443D-50C1-4B61-B5B7-228240C86C58@redhat.com>
	<FDE3F0DE-B17C-41E6-88E7-0B658DFBC0C7@redhat.com>
	<55509ED2.5090404@redhat.com>
Message-ID: <119E36FE-F3E4-4D41-94D3-36054CF04847@redhat.com>

On 11 May 2015, at 14:21, Mickael Istria wrote:

> On 05/11/2015 02:02 PM, Max Rydahl Andersen wrote:
>> Why do we need a 2nd level under snapshots called master and 4.3.mars 
>> when that is already supposed to be covered by snapshots and staging 
>> (and eventually development/stable) ?
> Currently, the process of creating a good 'staging' directory is not 
> only a matter of letting CI put its output in a different folder.
> Ouput of CI jobs (whether master or stabilization branch) go under 
> snapshots/.
> In order to stage, we take the output of 
> snapshots/<some_jobs>_4.3.mars and turn it into something more 
> test-friendly into staging/. The various steps are described in 
> https://github.com/jbdevstudio/jbdevstudio-devdoc/blob/master/release_guide/9.x/JBT_Staging_for_QE.adoc

yes, but for some reason that all seem to be skipped/ignored/different 
or am I reading it wrong ?

/max
http://about.me/maxandersen


From manderse at redhat.com  Tue May 12 03:08:30 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 12 May 2015 09:08:30 +0200
Subject: [jbosstools-dev] Advice on use of apache.directory.browser
 plugins
In-Reply-To: <5550F395.3040707@phantomjinx.co.uk>
References: <5550F395.3040707@phantomjinx.co.uk>
Message-ID: <6FA8E6E1-3668-407E-8327-B95A4BB5309B@redhat.com>

On 11 May 2015, at 20:23, phantomjinx wrote:

> Hi,
>
> Wanted to get a handle on the way forward for use of bundles from 
> update sites outside of JBT and
> JBT-IS.

We have a very explicit document outlining how to cope with additions to 
our TP's - this applies to
*anything* that goes into JBoss Tools, including Teiid.

See 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc

> Teiid Designer has the ability to model connections to LDAP servers. 
> Up until this point, we have
> created the modelling UI from scratch but I have found that
> org.apache.directory.studio.ldapbrowser has a superior set of UI 
> widgets that Designer could make
> use of.

Never heard about it - got some more info besides just their updatesite 
?

I found http://directory.apache.org/studio/

They don't seem to have had a release for 2 years ?

Any reason why we need their full content and not just take the controls 
we need ?

> While experimenting I have appended the directory update site [1] to 
> our eclipse TP but
> long term, if everything works okay, I would prefer a most resiliant 
> strategy to avoid just
> situations as their update site suddenly disappearing.

Yes, we always mirror what we include in TP. But before we do we'll need 
to check
what kind of dependencies etc. it drags in etc.

> Can I get some advice on how to proceed with this, in that should the 
> update site be appended to
> the JBT TP? Should their update site be mirrored? Is this a 
> non-starter?

Please, start by doing whats in 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc

And yeah, for me the biggest issue is that there seem to have been no 
release for 2 years so
who is going to maintain these is my biggest question.

/max

> Cheers
>
> PGR
>
> [1] http://directory.apache.org/studio/update/2.x/
>
> - --
> Paul Richardson
>
> * p.g.richardson at phantomjinx.co.uk
> * p.g.richardson at redhat.com
> * pgrichardson at linux.com
>
> "I know exactly who reads the papers ...
>
> * The Daily Mirror is read by people who think they run the country.
> * The Guardian is read by people who think they ought to run the 
> country.
> * The Times is read by people who do actually run the country.
> * The Daily Mail is read by the wives of the people who run the 
> country.
> * The Financial Times is read by the people who own the country.
> * The Morning Star is read by the people who think the country ought 
> to be run by another country.
> * The Daily Telegraph is read by the people who think it is."
>
> Jim Hacker, Yes Minister
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen


From p.g.richardson at phantomjinx.co.uk  Tue May 12 04:33:12 2015
From: p.g.richardson at phantomjinx.co.uk (phantomjinx)
Date: Tue, 12 May 2015 09:33:12 +0100
Subject: [jbosstools-dev] Advice on use of apache.directory.browser
	plugins
In-Reply-To: <6FA8E6E1-3668-407E-8327-B95A4BB5309B@redhat.com>
References: <5550F395.3040707@phantomjinx.co.uk>
	<6FA8E6E1-3668-407E-8327-B95A4BB5309B@redhat.com>
Message-ID: <5551BAC8.5070400@phantomjinx.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/05/15 08:08, Max Rydahl Andersen wrote:
> On 11 May 2015, at 20:23, phantomjinx wrote:
> 
>> Hi,
>> 
>> Wanted to get a handle on the way forward for use of bundles from update sites outside of JBT
>> and JBT-IS.
> 
> We have a very explicit document outlining how to cope with additions to our TP's - this
> applies to *anything* that goes into JBoss Tools, including Teiid.
> 
> See 
> https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platf
orms_updates.adoc
>
> 
That's handy. Thanks!

>> Teiid Designer has the ability to model connections to LDAP servers. Up until this point, we
>> have created the modelling UI from scratch but I have found that 
>> org.apache.directory.studio.ldapbrowser has a superior set of UI widgets that Designer could
>> make use of.
> 
> Never heard about it - got some more info besides just their updatesite ?
> 
> I found http://directory.apache.org/studio/

That's the one!

> They don't seem to have had a release for 2 years ?

Indeed. However, their ldap BrowserConnection and BrowserUI work/look a lot better than the one I
created for Designer.

> Any reason why we need their full content and not just take the controls we need ?
> 

Nope. I just want the LdapBrowser feature and its dependencies. Experimenting yesterday got it
down two about 6 plugins
from their repository and a few extras such as org.apache.poi and org.apache.directory.api.ldap.mode
l.

>> While experimenting I have appended the directory update site [1] to our eclipse TP but long
>> term, if everything works okay, I would prefer a most resiliant strategy to avoid just 
>> situations as their update site suddenly disappearing.
> 
> Yes, we always mirror what we include in TP. But before we do we'll need to check what kind of
> dependencies etc. it drags in etc.

I can compile a list as I work through the doc you posted above.

>> Can I get some advice on how to proceed with this, in that should the update site be appended
>> to the JBT TP? Should their update site be mirrored? Is this a non-starter?
> 
> Please, start by doing whats in 
> https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platf
orms_updates.adoc

No
> 
Problem.

> And yeah, for me the biggest issue is that there seem to have been no release for 2 years so 
> who is going to maintain these is my biggest question.

That's an interesting question. My first experiment was to take the bits I wanted out of their
code and integrate
it directly in Teiid. However, the cascading/snowball affect soon kicked in and I was migrating
over 100 classes before any
real functionality was ported. In that sense, I was forking it and dangerously coming close to
adding little foobars here and
there.

Therefore, the natural alternative is to depend on these plugins instead hence first adding them
as quick referenced libs
coming straight from maven. That failed since these are full-on plugins and need osgi to properly
start them with a bundle context
and initialise their activators. Consequently, depending on them as plugins from the update site
seems the next option hence
my exploratory email.

We have a number of bugs in Teiid concerning the ldap importer and the widgets will help both
mitigate some of those. Thus, I
definitely want to use some of this code but I have no answer and little experience to the
maintenance question.

PGR
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlVRusgACgkQcthLMIwdEb335ACg4JNypOwVC4m51A6uCoEFW46C
rKIAoNq7ftI5xmGBaqiMc6dgh0mvqgBU
=rkoz
-----END PGP SIGNATURE-----

From bastian.ugimachi at gmail.com  Tue May 12 05:22:57 2015
From: bastian.ugimachi at gmail.com (Bastian Ugimachi)
Date: Tue, 12 May 2015 11:22:57 +0200
Subject: [jbosstools-dev] antlr packages and lib not exported in
 Hibernate Tools 4.0.1
In-Reply-To: <1B447044-6635-41D2-93C0-290914707E33@redhat.com>
References: <CAFEyyCJu+-LgoQ5HuCDhy9Kn9sPLSUB1+vOwoOD8-8BhLU=oQw@mail.gmail.com>
	<55353EFE.6040702@exadel.com>
	<A86EAF8E-5B33-4ABB-9C4A-F61DB208E120@redhat.com>
	<1B447044-6635-41D2-93C0-290914707E33@redhat.com>
Message-ID: <CAFEyyCKj8tFSfObeK8O2nAULfhVrU652qjesbfuiGcm1spgtuA@mail.gmail.com>

Sorry for responding lately. (Your last mail was the only one that reached
my mailbox for some reason...)


2015-04-30 13:10 GMT+02:00 Max Rydahl Andersen <manderse at redhat.com>:

> Bastian - did you get your problem solved ?
>
> > On 20 Apr 2015, at 20:01, Alexey Kazakov wrote:
> >
> >> First at all, please create an issue in
> >> https://issues.jboss.org/browse/JBIDE to solve this problem in the
> >> next release.
> >> A pull request for https://github.com/jbosstools/jbosstools-hibernate
> >> would be useful too :)
> >
> > please note that we are really trying to limit exposing any of hibernate
> > internal runtime API's to support multiple versions of Hibernate. Thus
> > if this break that we won't be able to do it.
> >
>

I strongly agree with that! On the other hand, the HqlParser (from package
org.hibernate.hql.ast) itself is exposed; wouldn't it then be consquent to
also expose its required libraries for external usage?


> > What is your plugin trying to do that needs this level of access ?
> >
>

My tool uses the HqlParser from the Eclipse Libs to get information about
the query's referred entities, referred fields etc. It uses these
information for some further verification; e.g. whether named parameters
exist / are used correctly.

Bastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150512/06d3c3fa/attachment.html 

From nboldt at redhat.com  Wed May 13 00:04:42 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 13 May 2015 00:04:42 -0400
Subject: [jbosstools-dev] Fwd: Build failed in Jenkins:
 jbosstools-arquillian_master #282
In-Reply-To: <0A880784-2049-4925-89D7-D19D350901FD@redhat.com>
References: <70886434.689.1431256460841.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
	<0A880784-2049-4925-89D7-D19D350901FD@redhat.com>
Message-ID: <5552CD5A.2070408@redhat.com>

Have opened a ticket to get vncserver installed on that slave. 
https://engineering.redhat.com/rt/Ticket/Display.html?id=351632

On 05/11/2015 04:34 AM, Max Rydahl Andersen wrote:
> See
>><http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/282/>
>>
>>------------------------------------------
>>Started by build flow jbosstools-buildflow_master#162
>>[EnvInject] - Loading node environment variables.
>>Building remotely on dev218-virt1 in workspace
>><http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/>
>>Fetching changes from the remote Git repository
>>Fetching upstream changes from
>>git://github.com/jbosstools/jbosstools-arquillian.git
>>Checking out Revision 85c91abfefba2f39607e73e6912f4f7cfc1beddf
>>(origin/master)
>>Starting xvnc
>>[jbosstools-arquillian_master] $ vncserver :89 -geometry 1920x1080
>>FATAL: Cannot run program "vncserver" (in directory
>>"<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>:
>>java.io.IOException: error=2, No such file or directory
>>java.io.IOException: Cannot run program "vncserver" (in directory
>>"<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>:
>>java.io.IOException: error=2, No such file or directory

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 13 03:00:40 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Wed, 13 May 2015 03:00:40 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505130700.t4D70eJU012353@int-mx11.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBDS-3434

https://issues.jboss.org/browse/JBDS-3434
Summary: Kubernetes editor & wizard

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 18:22:08.034625

----------------------------



Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27

From manderse at redhat.com  Wed May 13 04:14:22 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 13 May 2015 10:14:22 +0200
Subject: [jbosstools-dev] Build failed in Jenkins:
 jbosstools-arquillian_master #282
In-Reply-To: <5552CD5A.2070408@redhat.com>
References: <70886434.689.1431256460841.JavaMail.hudsonmaster@jenkins.mw.lab.eng.bos.redhat.com>
	<0A880784-2049-4925-89D7-D19D350901FD@redhat.com>
	<5552CD5A.2070408@redhat.com>
Message-ID: <418CC71F-1463-4493-B8DC-067D521C9D5C@redhat.com>

On 13 May 2015, at 6:04, Nick Boldt wrote:

> Have opened a ticket to get vncserver installed on that slave.
> https://engineering.redhat.com/rt/Ticket/Display.html?id=351632

Okey thanks.

And I added Snjezana as recipient of failing arquillian builds since 
turns out
she is not getting any notifications of these unless she was the last to 
commit.

/max

> On 05/11/2015 04:34 AM, Max Rydahl Andersen wrote:
>> See
>>> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/282/>
>>>
>>> ------------------------------------------
>>> Started by build flow jbosstools-buildflow_master#162
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on dev218-virt1 in workspace
>>> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/>
>>> Fetching changes from the remote Git repository
>>> Fetching upstream changes from
>>> git://github.com/jbosstools/jbosstools-arquillian.git
>>> Checking out Revision 85c91abfefba2f39607e73e6912f4f7cfc1beddf
>>> (origin/master)
>>> Starting xvnc
>>> [jbosstools-arquillian_master] $ vncserver :89 -geometry 1920x1080
>>> FATAL: Cannot run program "vncserver" (in directory
>>> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>:
>>> java.io.IOException: error=2, No such file or directory
>>> java.io.IOException: Cannot run program "vncserver" (in directory
>>> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian_master/ws/")>:
>>> java.io.IOException: error=2, No such file or directory
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen


From nboldt at redhat.com  Thu May 14 16:54:07 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 14 May 2015 16:54:07 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>
References: <554B924B.6090505@redhat.com>
	<554BAFD7.7040403@exadel.com>	<554BBC20.4070902@redhat.com>
	<DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>
Message-ID: <55550B6F.4080303@redhat.com>

Some more updates to the M7 TP, while we decide what to do about 
Sapphire / Java 8.

* remove fest (it was commented out already)

* add org.eclipse.tm.terminal.control.feature.feature.group 
(rse.terminals requires it); remove old org.junit 
3.8.2.v3_8_2_v20130308-0410

* add org.eclipse.egit.ui.importer 0.0.1.201505070847 (needed for easymport)

* jbosstools-server requests that the new tm.terminal views/connectors 
be installed along with it, so add org.eclipse.tm.terminal.*, 
connector.local.feature and org.eclipse.cdt.core.native.feature 
(JBIDE-17686, JBIDE-19776)

* Switch to Mockito 1.9.5.v20131024-0922 (from Locus 1.2.0.Final site)

If you haven't tried the latest M7 TP, please do so from this PR:

https://github.com/jbosstools/jbosstools-target-platforms/pull/142/

On 05/08/2015 04:02 AM, Max Rydahl Andersen wrote:
> On 7 May 2015, at 21:25, Mickael Istria wrote:
>
>> On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
>>>
>>> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
>>> Sapphire was updated in M7 and this version is not compatible with
>>> Sapphire v.9.0.0.201408261741 which was included in Mars TP before
>>> (M1-M6)
>>> Batch and Arquillian tools require Sapphire. It's not a big deal for
>>> us to migrate Batch and Arquillian to new Sapphire API.
>>> But the problem is that the new Sapphire (M7) has
>>> *RequiredExecutionEnvironment: JavaSE-1.8*
>> Too bad this wasn't spotted earlier. Is anyone following the Sapphire
>> mailing-list or bugzilla component?
>
>
> Sapphire announced it here:
> https://www.eclipse.org/forums/index.php/t/890531/ back in January and
> yes, really bad we did not catch that.
>
> But we did monitor the release train but Sapphire did not put this
> change until M7. Where it is IMO is too late as said over here
> https://www.eclipse.org/forums/index.php/m/1694326
>
> But Konstantin from Sapphire seem to not care about that ;/
>
>>> If we can't require Java 8 for Batch and Arquillian then we have to
>>> switch to Sapphire 8.2 from 9.0 in our TP.
>>> Sapphire 8.2 supports Mars but Mars update site includes Sapphire
>>> 9.0. only.
>>> How are we going to deal with that?
>> Well, Java 7 has reached end-of-life a few days ago, so I would
>> support the idea of requiring Java 8 for those components. If they are
>> part of JBDS default package, then it means that JBDS will also
>> require Java 8.
>> If we want to keep Java 7, we can simply include only Sapphire 8.2 in
>> the target-platform and keep Sapphire 9.0 out. But I guess Sapphire
>> 8.2 and 9.0 cannot be installed simultaneously; can they?
>
> Konstantin claims they can - as long as you don't include two colliding
> features that requires them.
>
>> If not, then we need to make sure no other project that is important
>> to us and that we want to work together with JBoss Tools relies on
>> newer Sapphire.
>> So is anyone aware of some other project that requires Sapphire and
>> that we'd like to keep compatible with?
>
> I've raised question internally to see if any objections against raising
> to Java 8 since Java 7 is EOL'ed now *and* it seems its usage is
> declining faster than Java 6 did.
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From rstryker at redhat.com  Thu May 14 18:06:23 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Thu, 14 May 2015 18:06:23 -0400
Subject: [jbosstools-dev] Some updates on new terminal
Message-ID: <55551C5F.6070107@redhat.com>

Hi All:

So I've discovered by more code-browsing that the new tm terminal view 
makes their internal viewer public API. This should easily allow someone 
like Lars to use the viewer and embed it into their own view.  I havent' 
yet discovered if their public API is sufficient for Lars to simply call 
and open a specific connection type in the existing view.

I have learned, however, that o.e.remote does not plan to use their 
view, but rather will use the viewer itself and create 'consoles' out of 
it... via IConsoleManager and the associated UI.  You can find their 
code in git://git.eclipse.org/gitroot/ptp/org.eclipse.remote.git   in 
the bundles/org.eclipse.remote.console/ folder.

I've also opened bugs to ensure that this plugin at least has public API 
to open a console for a given o.e.remote IRemoteConnection object, which 
I've just had accepted.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=467350#add_comment

Either way, whether Lars in the future wants to make his servers 
exposable via o.e.remote and implement an IRemoteCommandShellService  
(which I haven't investigated how easy this part is yet, but I suspect 
its not difficult) or if he wants to simply keep his view but change the 
implementation to use the new public API viewers inside,  it should work 
as expected.

There's enough code in existence now that provide PoCs and should make 
converting his console fairly easy.

It would be really nice if Lars had a Mars branch and TP available, 
though.  But it seems he won't get that far for quite a while, so I took 
the lead on making sure API was sufficient.

Does anyone else depend on the terminal situation other than Lars? It'd 
be great if specific usecases could be laid out for how it's being used 
right now and what fucntionality is needed in future impls.


- Rob Stryker

From lhein at redhat.com  Fri May 15 02:09:32 2015
From: lhein at redhat.com (Lars Heinemann)
Date: Fri, 15 May 2015 08:09:32 +0200
Subject: [jbosstools-dev] Some updates on new terminal
In-Reply-To: <55551C5F.6070107@redhat.com>
References: <55551C5F.6070107@redhat.com>
Message-ID: <55558D9C.4060908@redhat.com>

Hey Rob,

that sounds promising.
I hope I will be able to work on that after JBTIS code freeze at May 20th.

Thanks
Lars


Am 15.05.2015 um 00:06 schrieb Rob Stryker:
> Hi All:
>
> So I've discovered by more code-browsing that the new tm terminal view 
> makes their internal viewer public API. This should easily allow someone 
> like Lars to use the viewer and embed it into their own view.  I havent' 
> yet discovered if their public API is sufficient for Lars to simply call 
> and open a specific connection type in the existing view.
>
> I have learned, however, that o.e.remote does not plan to use their 
> view, but rather will use the viewer itself and create 'consoles' out of 
> it... via IConsoleManager and the associated UI.  You can find their 
> code in git://git.eclipse.org/gitroot/ptp/org.eclipse.remote.git   in 
> the bundles/org.eclipse.remote.console/ folder.
>
> I've also opened bugs to ensure that this plugin at least has public API 
> to open a console for a given o.e.remote IRemoteConnection object, which 
> I've just had accepted.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467350#add_comment
>
> Either way, whether Lars in the future wants to make his servers 
> exposable via o.e.remote and implement an IRemoteCommandShellService  
> (which I haven't investigated how easy this part is yet, but I suspect 
> its not difficult) or if he wants to simply keep his view but change the 
> implementation to use the new public API viewers inside,  it should work 
> as expected.
>
> There's enough code in existence now that provide PoCs and should make 
> converting his console fairly easy.
>
> It would be really nice if Lars had a Mars branch and TP available, 
> though.  But it seems he won't get that far for quite a while, so I took 
> the lead on making sure API was sufficient.
>
> Does anyone else depend on the terminal situation other than Lars? It'd 
> be great if specific usecases could be laid out for how it's being used 
> right now and what fucntionality is needed in future impls.
>
>
> - Rob Stryker
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From manderse at redhat.com  Fri May 15 03:00:06 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Fri, 15 May 2015 03:00:06 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505150700.t4F7067N012412@int-mx09.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBIDE-19810

https://issues.jboss.org/browse/JBIDE-19810
Summary: easymport is slow and wrong compared to basic import since it lets mvn overrule .project

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 10:48:44.432147

----------------------------



Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27

From manderse at redhat.com  Fri May 15 05:14:11 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Fri, 15 May 2015 05:14:11 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505150914.t4F9EB33009116@int-mx13.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBIDE-19810

https://issues.jboss.org/browse/JBIDE-19810
Summary: easymport is slow and wrong compared to basic import since it lets mvn overrule .project

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please ensure this issue has a proper component set.
Last Update: 13:02:49.648149

----------------------------



Query used: https://issues.jboss.org/issues/?jql=%28filter%3D%27ds_lint_nocomponent%27%29

From hffv7 at ui.gghhge.com  Sun May 17 20:22:58 2015
From: hffv7 at ui.gghhge.com (Low cost multi monitor video wall solution with IP Manager camera
	supported / Attn: Technical)
Date: Mon, 18 May 2015 00:22:58 +0000
Subject: [jbosstools-dev] =?gb2312?b?TG93IGNvc3QgbXVsdGkgbW9uaXRvciB2aWRl?=
	=?gb2312?b?byB3YWxsIHNvbHV0aW9uIHdpdGggSVAgTWFuYWdlciBjYW1lcmEg?=
	=?gb2312?b?c3VwcG9ydGVkIC8gQXR0bjogVGVjaG5pY2Fs0+vE+rmyz+3By8/g?=
	=?gb2312?b?suGhow==?=
Message-ID: <001a11c2f0022632a30516503282@google.com>

Dear Sirs,

  After visiting your web-site I decided to contact your esteemed company as  
one of the leaders of digital signage field .

  MSP5000 is a multi monitor video wall processor, supporting to up  32  
channel display monitor. What is more MSP5000 can compatible with multi  
capture type, including IP camera ,DVI,VGA SDI and BNC .The PC and FPGA  
architecture offer users with stable, flexible and cost effective image  
processing capabilities.  All these features make it a good choice for  
surveillance application .

  I would appreciate if you forward this letter to Technical Manager or to  
other expert responsible for technical integration of new products in your  
company, or provide me with his contact for we could discuss all the  
details of our future cooperation.

Your early reply is highly appreciated

Anna

https://picasaweb.google.com/lh/sredir?uname=105219742990253803164&target=ALBUM&id=6127800290404118097&authkey=Gv1sRgCKjk2KXjpM70Hw&invite=CLig3I0F&feat=email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150518/d59943c4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: picasaweblogo-zh_CN.gif
Type: image/gif
Size: 1646 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150518/d59943c4/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: email.jpg
Type: image/jpeg
Size: 7038 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150518/d59943c4/attachment-0001.jpg 

From manderse at redhat.com  Mon May 18 03:58:54 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 18 May 2015 09:58:54 +0200
Subject: [jbosstools-dev] posting info about events to tools.jboss.org
Message-ID: <9A9C4F57-4C24-4FF2-9B47-2DDD7A30D634@redhat.com>

Hey,

Please remember that if you are speaking about anything tooling related 
at a conference
or event to simply do a PR for 
https://github.com/jbosstools/jbosstools-website/tree/master/events

After seeing "Upcoming Events" go blank again on tools.jboss.org I went 
and added
EclipseCon France, DevNation and Red Hat Summit.

Please check if I got your various speaking events correctly added at 
tools.jboss.org/events/

I thought we would have more at EclipseCon France but didn't find 
anything beyond
Erik and my talks. Anything I missed ?

Thanks,
/max
http://about.me/maxandersen

From manderse at redhat.com  Mon May 18 05:09:13 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 18 May 2015 11:09:13 +0200
Subject: [jbosstools-dev] Some updates on new terminal
In-Reply-To: <55551C5F.6070107@redhat.com>
References: <55551C5F.6070107@redhat.com>
Message-ID: <623744A8-5B69-41F3-983B-190DA8C9CD55@redhat.com>

On 15 May 2015, at 0:06, Rob Stryker wrote:

> Hi All:
>
> So I've discovered by more code-browsing that the new tm terminal view
> makes their internal viewer public API.

I just want to make sure I grok this right. If there view is public API 
it is *not*
an internal viewer ?

Above makes it sounds like it was accidentally exposed - I assume it was
deliberate ?

And yes, that sounds great!

Just hope their UI outside the actual console view gets better over time 
- it
is a bit "non-smooth" ;)

/max
http://about.me/maxandersen

From rstryker at redhat.com  Mon May 18 12:56:45 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Mon, 18 May 2015 12:56:45 -0400
Subject: [jbosstools-dev] Some updates on new terminal
In-Reply-To: <623744A8-5B69-41F3-983B-190DA8C9CD55@redhat.com>
References: <55551C5F.6070107@redhat.com>
	<623744A8-5B69-41F3-983B-190DA8C9CD55@redhat.com>
Message-ID: <555A19CD.4040805@redhat.com>

On 05/18/2015 05:09 AM, Max Rydahl Andersen wrote:
> I just want to make sure I grok this right. If there view is public 
> API it is *not*
> an internal viewer ?

Sorry... remote.console uses ITerminalViewControl, which is API in the 
new terminals plugin. It gets this object via 
TerminalViewControlFactory, which is also public API.

So yes, it's public API. What I meant by 'internal' was the control used 
inside the view (ie the viewer); not that the class / API was "internal".

Sorry for the confusion.

- Rob

>
> Above makes it sounds like it was accidentally exposed - I assume it was
> deliberate ?
>
> And yes, that sounds great!
>
> Just hope their UI outside the actual console view gets better over 
> time - it
> is a bit "non-smooth" ;)
>
> /max
> http://about.me/maxandersen


From manderse at redhat.com  Mon May 18 15:09:25 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 18 May 2015 21:09:25 +0200
Subject: [jbosstools-dev] Sprint #3 closed, Sprint #4 started ...
Message-ID: <2B30B0DD-1A76-4F4A-93FF-1F0CAD9D78F3@redhat.com>

Heya,

Closed Sprint #3 this morning.

https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=641&view=reporting&chart=sprintRetrospective&sprint=3002

21 issues done, 49+ issues not done.

Either our sprints are too short or jiras too big :)

I've started Sprint #4 with end date June 5th, which is 3 weeks from now 
- the day after code freeze for Beta1.

That at least tries to fixe the "sprints are too" short issue.

Let's not put stuff on the sprints if we can't make them happen.

Thanks,
/max
http://about.me/maxandersen


From manderse at redhat.com  Tue May 19 03:16:17 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 19 May 2015 03:16:17 -0400 (EDT)
Subject: [jbosstools-dev] Some updates on new terminal
In-Reply-To: <555A19CD.4040805@redhat.com>
References: <55551C5F.6070107@redhat.com>
	<623744A8-5B69-41F3-983B-190DA8C9CD55@redhat.com>
	<555A19CD.4040805@redhat.com>
Message-ID: <84F385A3-5A6B-4761-B200-524DBE9FE119@redhat.com>

Okey that makes it more clear. Thanks :)

/max
http://about.me/maxandersen


> On 18 May 2015, at 18:56, Rob Stryker <rstryker at redhat.com> wrote:
> 
>> On 05/18/2015 05:09 AM, Max Rydahl Andersen wrote:
>> I just want to make sure I grok this right. If there view is public API it is *not*
>> an internal viewer ?
> 
> Sorry... remote.console uses ITerminalViewControl, which is API in the new terminals plugin. It gets this object via TerminalViewControlFactory, which is also public API.
> 
> So yes, it's public API. What I meant by 'internal' was the control used inside the view (ie the viewer); not that the class / API was "internal".
> 
> Sorry for the confusion.
> 
> - Rob
> 
>> 
>> Above makes it sounds like it was accidentally exposed - I assume it was
>> deliberate ?
>> 
>> And yes, that sounds great!
>> 
>> Just hope their UI outside the actual console view gets better over time - it
>> is a bit "non-smooth" ;)
>> 
>> /max
>> http://about.me/maxandersen
> 


From rajkumarr at wso2.com  Tue May 19 08:18:32 2015
From: rajkumarr at wso2.com (Rajkumar Rajaratnam)
Date: Tue, 19 May 2015 17:48:32 +0530
Subject: [jbosstools-dev] Where can I download jboss messaging 1.4.7.GA?
Message-ID: <CAFgrWyRM4Peji_DvtpQUmx4h5hRy9073je7esM4q+rM95npstg@mail.gmail.com>

Hi,

Can someone please tell me how to download jboss messaging  1.4.7.GA pre
built binaries?

Thanks.

-- 
Rajkumar Rajaratnam
Committer & PMC Member, Apache Stratos
Software Engineer, WSO2

Mobile : +94777568639
Blog : rajkumarr.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150519/309ab304/attachment.html 

From rstryker at redhat.com  Tue May 19 16:58:14 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Tue, 19 May 2015 16:58:14 -0400
Subject: [jbosstools-dev] Regarding launchbar contribution
Message-ID: <555BA3E6.4080008@redhat.com>

Hi All:

wtp-dev mailing list seems to indicate its a bit too late to get such a 
contribution into Mars. They did suggest it might be reasonable for SR1.

With that in mind, we should discuss how to go about getting this into 
JBT for our Mars release, while still allowing it to be removed / 
overridden by the eventual contribution to SR1.

As of now, it seems the thing most important to discuss is naming of the 
plugin, to ensure that the name we use matches with the WTP one. The 
idea seems to be that if we release this plugin as 0.9.0 in JBT,  it can 
be added to WTP for Mars SR1 with a higher version, thus replacing ours.

The issue at wtp can be discussed here: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604


@Nick:  Any ideas on whether this plan makes sense?

From nboldt at redhat.com  Tue May 19 17:11:56 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 19 May 2015 17:11:56 -0400
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <555BA3E6.4080008@redhat.com>
References: <555BA3E6.4080008@redhat.com>
Message-ID: <555BA71C.1060506@redhat.com>

Since JBT 4.3.0.Final is slated for after Mars SR1, this seems reasonable.

You don't technically need to have the same IU names to allow a seamless 
upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.

We've seen multiple instances where a JBoss project moved to Eclipse, 
and we were able to support the IU rename using a p2.inf instruction.

Here's what we did to rename from com.jboss.jbds to com.jboss.devstudio:

https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5

We've done similar with m2e-wtp, too.

But of course it's simpler if we just build the plugin using the future 
o.e.wtp name, and a lower version.


On 05/19/2015 04:58 PM, Rob Stryker wrote:
> Hi All:
>
> wtp-dev mailing list seems to indicate its a bit too late to get such a
> contribution into Mars. They did suggest it might be reasonable for SR1.
>
> With that in mind, we should discuss how to go about getting this into
> JBT for our Mars release, while still allowing it to be removed /
> overridden by the eventual contribution to SR1.
>
> As of now, it seems the thing most important to discuss is naming of the
> plugin, to ensure that the name we use matches with the WTP one. The
> idea seems to be that if we release this plugin as 0.9.0 in JBT,  it can
> be added to WTP for Mars SR1 with a higher version, thus replacing ours.
>
> The issue at wtp can be discussed here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>
>
> @Nick:  Any ideas on whether this plan makes sense?

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 20 03:37:55 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 20 May 2015 09:37:55 +0200
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <555BA71C.1060506@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
Message-ID: <5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>

Rob,

Have wtp-dev suggested a name for it ?

btw. does the launchbar work with local java apps and units too ?

I just realised we've been focusing purely on remote/server runs - but
local runs should work too.

/max

> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems 
> reasonable.
>
> You don't technically need to have the same IU names to allow a 
> seamless
> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>
> We've seen multiple instances where a JBoss project moved to Eclipse,
> and we were able to support the IU rename using a p2.inf instruction.
>
> Here's what we did to rename from com.jboss.jbds to 
> com.jboss.devstudio:
>
> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5
>
> We've done similar with m2e-wtp, too.
>
> But of course it's simpler if we just build the plugin using the 
> future
> o.e.wtp name, and a lower version.
>
>
> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>> Hi All:
>>
>> wtp-dev mailing list seems to indicate its a bit too late to get such 
>> a
>> contribution into Mars. They did suggest it might be reasonable for 
>> SR1.
>>
>> With that in mind, we should discuss how to go about getting this 
>> into
>> JBT for our Mars release, while still allowing it to be removed /
>> overridden by the eventual contribution to SR1.
>>
>> As of now, it seems the thing most important to discuss is naming of 
>> the
>> plugin, to ensure that the name we use matches with the WTP one. The
>> idea seems to be that if we release this plugin as 0.9.0 in JBT,  it 
>> can
>> be added to WTP for Mars SR1 with a higher version, thus replacing 
>> ours.
>>
>> The issue at wtp can be discussed here:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>
>>
>> @Nick:  Any ideas on whether this plan makes sense?
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen


From manderse at redhat.com  Wed May 20 03:35:23 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 20 May 2015 09:35:23 +0200
Subject: [jbosstools-dev] Where can I download jboss messaging 1.4.7.GA?
In-Reply-To: <CAFgrWyRM4Peji_DvtpQUmx4h5hRy9073je7esM4q+rM95npstg@mail.gmail.com>
References: <CAFgrWyRM4Peji_DvtpQUmx4h5hRy9073je7esM4q+rM95npstg@mail.gmail.com>
Message-ID: <3E7CC427-8253-4D19-B485-2610F5CBBBD6@redhat.com>

On 19 May 2015, at 14:18, Rajkumar Rajaratnam wrote:

> Hi,
>
> Can someone please tell me how to download jboss messaging  1.4.7.GA 
> pre
> built binaries?

This is the mailing list for development of JBoss Tools, not JBoss 
Messaging.

But my guess is 1.4.7.GA was part of EAP product release not a direct 
community release,
thus contact Red Hat support or if you believe it was in community ask 
in HornetQ forums (https://community.jboss.org/en/hornetq) ?

Thanks,
Max
>
> Thanks.
>
> -- 
> Rajkumar Rajaratnam
> Committer & PMC Member, Apache Stratos
> Software Engineer, WSO2
>
> Mobile : +94777568639
> Blog : rajkumarr.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From rstryker at redhat.com  Wed May 20 14:15:13 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Wed, 20 May 2015 14:15:13 -0400
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
	<5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
Message-ID: <555CCF31.4030600@redhat.com>

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

 > Have wtp-dev suggested a name for it ?

No, so far there are no comments on the bugzilla. I suggest you comment 
there if you so choose.

 >  btw. does the launchbar work with local java apps and units too ?

I probably need more of an explanation as to what you're asking, but, 
yes, it works for POJP and other launch configs as well. I've 
successfully seen MyMainClass in the list and run them.

But running a simple MyMainClass on some remote server doesn't work, if 
thats your question. Is that something you'd like to see?

On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
> Rob,
>
> Have wtp-dev suggested a name for it ?
>
> btw. does the launchbar work with local java apps and units too ?
>
> I just realised we've been focusing purely on remote/server runs - but
> local runs should work too.
>
> /max
>
>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems 
>> reasonable.
>>
>> You don't technically need to have the same IU names to allow a seamless
>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>
>> We've seen multiple instances where a JBoss project moved to Eclipse,
>> and we were able to support the IU rename using a p2.inf instruction.
>>
>> Here's what we did to rename from com.jboss.jbds to com.jboss.devstudio:
>>
>> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5 
>>
>>
>> We've done similar with m2e-wtp, too.
>>
>> But of course it's simpler if we just build the plugin using the future
>> o.e.wtp name, and a lower version.
>>
>>
>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>> Hi All:
>>>
>>> wtp-dev mailing list seems to indicate its a bit too late to get such a
>>> contribution into Mars. They did suggest it might be reasonable for 
>>> SR1.
>>>
>>> With that in mind, we should discuss how to go about getting this into
>>> JBT for our Mars release, while still allowing it to be removed /
>>> overridden by the eventual contribution to SR1.
>>>
>>> As of now, it seems the thing most important to discuss is naming of 
>>> the
>>> plugin, to ensure that the name we use matches with the WTP one. The
>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,  it 
>>> can
>>> be added to WTP for Mars SR1 with a higher version, thus replacing 
>>> ours.
>>>
>>> The issue at wtp can be discussed here:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>
>>>
>>> @Nick:  Any ideas on whether this plan makes sense?
>>
>> -- 
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen


From manderse at redhat.com  Wed May 20 17:49:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 20 May 2015 23:49:34 +0200
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <555CCF31.4030600@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
	<5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
	<555CCF31.4030600@redhat.com>
Message-ID: <DBCBE830-F2D2-496B-B840-DE4AA68D50D6@redhat.com>

On 20 May 2015, at 20:15, Rob Stryker wrote:

> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>
> > Have wtp-dev suggested a name for it ?
>
> No, so far there are no comments on the bugzilla. I suggest you 
> comment there if you so choose.
>
> >  btw. does the launchbar work with local java apps and units too ?
>
> I probably need more of an explanation as to what you're asking, but, 
> yes, it works for POJP and other launch configs as well. I've 
> successfully seen MyMainClass in the list and run them.

How does that work ? ..what is selected on the right side for that ?

> But running a simple MyMainClass on some remote server doesn't work, 
> if thats your question. Is that something you'd like to see?

Well, since we are looking at having Docker integrated being able to run 
on java app on a docker container would be a usecase to look at
if this could fit in here.

/max

> On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
>> Rob,
>>
>> Have wtp-dev suggested a name for it ?
>>
>> btw. does the launchbar work with local java apps and units too ?
>>
>> I just realised we've been focusing purely on remote/server runs - 
>> but
>> local runs should work too.
>>
>> /max
>>
>>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems 
>>> reasonable.
>>>
>>> You don't technically need to have the same IU names to allow a 
>>> seamless
>>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>>
>>> We've seen multiple instances where a JBoss project moved to 
>>> Eclipse,
>>> and we were able to support the IU rename using a p2.inf 
>>> instruction.
>>>
>>> Here's what we did to rename from com.jboss.jbds to 
>>> com.jboss.devstudio:
>>>
>>> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5
>>>
>>> We've done similar with m2e-wtp, too.
>>>
>>> But of course it's simpler if we just build the plugin using the 
>>> future
>>> o.e.wtp name, and a lower version.
>>>
>>>
>>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>>> Hi All:
>>>>
>>>> wtp-dev mailing list seems to indicate its a bit too late to get 
>>>> such a
>>>> contribution into Mars. They did suggest it might be reasonable for 
>>>> SR1.
>>>>
>>>> With that in mind, we should discuss how to go about getting this 
>>>> into
>>>> JBT for our Mars release, while still allowing it to be removed /
>>>> overridden by the eventual contribution to SR1.
>>>>
>>>> As of now, it seems the thing most important to discuss is naming 
>>>> of the
>>>> plugin, to ensure that the name we use matches with the WTP one. 
>>>> The
>>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,  
>>>> it can
>>>> be added to WTP for Mars SR1 with a higher version, thus replacing 
>>>> ours.
>>>>
>>>> The issue at wtp can be discussed here:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>
>>>>
>>>> @Nick:  Any ideas on whether this plan makes sense?
>>>
>>> -- 
>>> Nick Boldt :: JBoss by Red Hat
>>> Productization Lead :: JBoss Tools & Dev Studio
>>> http://nick.divbyzero.com
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>> /max
>> http://about.me/maxandersen


/max
http://about.me/maxandersen


From manderse at redhat.com  Thu May 21 03:00:10 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Thu, 21 May 2015 03:00:10 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201505210700.t4L70AjX028253@int-mx11.intmail.prod.int.phx2.redhat.com>


This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks!

 
* No component for JBIDE-19819

https://issues.jboss.org/browse/JBIDE-19819
Summary: Installing JBT 4.3.0.Alpha2 on eclipse Mars M6 breaks icons

Assignee: None set - please fix.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 1 day, 14:03:27.958188

----------------------------



Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27

From manderse at redhat.com  Thu May 21 07:01:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 21 May 2015 13:01:34 +0200
Subject: [jbosstools-dev] antlr packages and lib not exported in
 Hibernate Tools 4.0.1
In-Reply-To: <CAFEyyCKj8tFSfObeK8O2nAULfhVrU652qjesbfuiGcm1spgtuA@mail.gmail.com>
References: <CAFEyyCJu+-LgoQ5HuCDhy9Kn9sPLSUB1+vOwoOD8-8BhLU=oQw@mail.gmail.com>
	<55353EFE.6040702@exadel.com>
	<A86EAF8E-5B33-4ABB-9C4A-F61DB208E120@redhat.com>
	<1B447044-6635-41D2-93C0-290914707E33@redhat.com>
	<CAFEyyCKj8tFSfObeK8O2nAULfhVrU652qjesbfuiGcm1spgtuA@mail.gmail.com>
Message-ID: <8112E03E-975F-4352-905F-4E6BA89D47BA@redhat.com>

On 12 May 2015, at 11:22, Bastian Ugimachi wrote:

> Sorry for responding lately. (Your last mail was the only one that 
> reached
> my mailbox for some reason...)
>
>
> 2015-04-30 13:10 GMT+02:00 Max Rydahl Andersen <manderse at redhat.com>:
>
>> Bastian - did you get your problem solved ?
>>
>>> On 20 Apr 2015, at 20:01, Alexey Kazakov wrote:
>>>
>>>> First at all, please create an issue in
>>>> https://issues.jboss.org/browse/JBIDE to solve this problem in the
>>>> next release.
>>>> A pull request for 
>>>> https://github.com/jbosstools/jbosstools-hibernate
>>>> would be useful too :)
>>>
>>> please note that we are really trying to limit exposing any of 
>>> hibernate
>>> internal runtime API's to support multiple versions of Hibernate. 
>>> Thus
>>> if this break that we won't be able to do it.
>>>
>>
>
> I strongly agree with that! On the other hand, the HqlParser (from 
> package
> org.hibernate.hql.ast) itself is exposed; wouldn't it then be 
> consquent to
> also expose its required libraries for external usage?

I would say its more a mistake we expose direct access to HqlParser - I 
guess
  we would need to repackage the hibernate libraries as osgi components 
to make
this more sharable...not something we've spent time on unfortunately :/

>>> What is your plugin trying to do that needs this level of access ?
>>>
>>
>
> My tool uses the HqlParser from the Eclipse Libs to get information 
> about
> the query's referred entities, referred fields etc. It uses these
> information for some further verification; e.g. whether named 
> parameters
> exist / are used correctly.

Okey - any reason why not adding this functionality to hibernate tools 
it self where
you can get access to these ?

/max
http://about.me/maxandersen

From nboldt at redhat.com  Thu May 21 19:10:06 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 21 May 2015 19:10:06 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <55550B6F.4080303@redhat.com>
References: <554B924B.6090505@redhat.com>
	<554BAFD7.7040403@exadel.com>	<554BBC20.4070902@redhat.com>
	<DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>
	<55550B6F.4080303@redhat.com>
Message-ID: <555E65CE.5040401@redhat.com>

Target platform 4.50.0.Beta1-SNAPSHOT has been updated to Mars M7.

The decision was made today to have JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1 
prereq JDK 8 as a Bundle-RequireExecutionEnvironment (BREE).

As such, Arquillian plugins that depend on Sapphire 9 have now been set 
to a BREE of JavaSE-1.8 [1]. See JBIDE-19753.

[1] 
https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9

Server Tools has also been updated to take advantage of the new 
tm.terminal.* 4.0 plugins in place of the old tm.terminal 3.1 plugin. 
See JBIDE-19776.

--

Next week, when it becomes available, we will start a new PR to update 
the target platform to Mars RC2.

Reminder that code freeze for Beta1 is in TWO WEEKS on June 4, so the 
finalized 4.50.0.Beta1 target platforms for JBT and JBDS need to be 
released by June 3 at the latest.

Stay tuned!

On 05/14/2015 04:54 PM, Nick Boldt wrote:
> Some more updates to the M7 TP, while we decide what to do about
> Sapphire / Java 8.
>
> * remove fest (it was commented out already)
>
> * add org.eclipse.tm.terminal.control.feature.feature.group
> (rse.terminals requires it); remove old org.junit
> 3.8.2.v3_8_2_v20130308-0410
>
> * add org.eclipse.egit.ui.importer 0.0.1.201505070847 (needed for
> easymport)
>
> * jbosstools-server requests that the new tm.terminal views/connectors
> be installed along with it, so add org.eclipse.tm.terminal.*,
> connector.local.feature and org.eclipse.cdt.core.native.feature
> (JBIDE-17686, JBIDE-19776)
>
> * Switch to Mockito 1.9.5.v20131024-0922 (from Locus 1.2.0.Final site)
>
> If you haven't tried the latest M7 TP, please do so from this PR:
>
> https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
>
> On 05/08/2015 04:02 AM, Max Rydahl Andersen wrote:
>> On 7 May 2015, at 21:25, Mickael Istria wrote:
>>
>>> On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
>>>>
>>>> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
>>>> Sapphire was updated in M7 and this version is not compatible with
>>>> Sapphire v.9.0.0.201408261741 which was included in Mars TP before
>>>> (M1-M6)
>>>> Batch and Arquillian tools require Sapphire. It's not a big deal for
>>>> us to migrate Batch and Arquillian to new Sapphire API.
>>>> But the problem is that the new Sapphire (M7) has
>>>> *RequiredExecutionEnvironment: JavaSE-1.8*
>>> Too bad this wasn't spotted earlier. Is anyone following the Sapphire
>>> mailing-list or bugzilla component?
>>
>>
>> Sapphire announced it here:
>> https://www.eclipse.org/forums/index.php/t/890531/ back in January and
>> yes, really bad we did not catch that.
>>
>> But we did monitor the release train but Sapphire did not put this
>> change until M7. Where it is IMO is too late as said over here
>> https://www.eclipse.org/forums/index.php/m/1694326
>>
>> But Konstantin from Sapphire seem to not care about that ;/
>>
>>>> If we can't require Java 8 for Batch and Arquillian then we have to
>>>> switch to Sapphire 8.2 from 9.0 in our TP.
>>>> Sapphire 8.2 supports Mars but Mars update site includes Sapphire
>>>> 9.0. only.
>>>> How are we going to deal with that?
>>> Well, Java 7 has reached end-of-life a few days ago, so I would
>>> support the idea of requiring Java 8 for those components. If they are
>>> part of JBDS default package, then it means that JBDS will also
>>> require Java 8.
>>> If we want to keep Java 7, we can simply include only Sapphire 8.2 in
>>> the target-platform and keep Sapphire 9.0 out. But I guess Sapphire
>>> 8.2 and 9.0 cannot be installed simultaneously; can they?
>>
>> Konstantin claims they can - as long as you don't include two colliding
>> features that requires them.
>>
>>> If not, then we need to make sure no other project that is important
>>> to us and that we want to work together with JBoss Tools relies on
>>> newer Sapphire.
>>> So is anyone aware of some other project that requires Sapphire and
>>> that we'd like to keep compatible with?
>>
>> I've raised question internally to see if any objections against raising
>> to Java 8 since Java 7 is EOL'ed now *and* it seems its usage is
>> declining faster than Java 6 did.
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Thu May 21 21:20:21 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 21 May 2015 21:20:21 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring JUnit
 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars M7)
Message-ID: <555E8455.8050908@redhat.com>

The following projects have plugins or features which depend on JUnit 3.8.

Can they be changed to use JUnit 4.12, which is the version included in 
the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?

* base
* bpel
* central
* forge
* hibernate
* javaee
* jst
* portlet
* vpe

Or do we need to find a way to include JUnit 3.8 as well as JUnit 4.12?

Details here: https://issues.jboss.org/browse/JBIDE-19836

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Fri May 22 11:16:26 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 22 May 2015 11:16:26 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
 JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars
 M7)
In-Reply-To: <555E8455.8050908@redhat.com>
References: <555E8455.8050908@redhat.com>
Message-ID: <555F484A.4090808@redhat.com>

Some PRs to consider, which fix MANIFEST.MF and feature.xml files to 
depend on 4.12.0 instead of 3.8.x:

https://github.com/jbosstools/jbosstools-forge/pull/140
https://github.com/jbosstools/jbosstools-vpe/pull/311
https://github.com/jbosstools/jbosstools-portlet/pull/33
https://github.com/jbosstools/jbosstools-jst/pull/487
https://github.com/jbosstools/jbosstools-javaee/pull/340
https://github.com/jbosstools/jbosstools-hibernate/pull/73
https://github.com/jbosstools/jbosstools-bpel/pull/25
https://github.com/jbosstools/jbosstools-base/pull/407

I've omitted changing anything in poms that declare a MAVEN dependency 
to JUnit 3.8, since that should still be resolved by Maven (not by p2).

Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.

On 05/21/2015 09:20 PM, Nick Boldt wrote:
> The following projects have plugins or features which depend on JUnit 3.8.
>
> Can they be changed to use JUnit 4.12, which is the version included in
> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
>
> * base
> * bpel
> * central
> * forge
> * hibernate
> * javaee
> * jst
> * portlet
> * vpe
>
> Or do we need to find a way to include JUnit 3.8 as well as JUnit 4.12?
>
> Details here: https://issues.jboss.org/browse/JBIDE-19836
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From ggastald at redhat.com  Fri May 22 11:17:43 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Fri, 22 May 2015 12:17:43 -0300
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
 JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars
 M7)
In-Reply-To: <555F484A.4090808@redhat.com>
References: <555E8455.8050908@redhat.com> <555F484A.4090808@redhat.com>
Message-ID: <555F4897.2080407@redhat.com>

Another hint as Nick proposed is to remove the JUnit version constraint. 
I'm doing that for Forge

On 05/22/2015 12:16 PM, Nick Boldt wrote:
> Some PRs to consider, which fix MANIFEST.MF and feature.xml files to
> depend on 4.12.0 instead of 3.8.x:
>
> https://github.com/jbosstools/jbosstools-forge/pull/140
> https://github.com/jbosstools/jbosstools-vpe/pull/311
> https://github.com/jbosstools/jbosstools-portlet/pull/33
> https://github.com/jbosstools/jbosstools-jst/pull/487
> https://github.com/jbosstools/jbosstools-javaee/pull/340
> https://github.com/jbosstools/jbosstools-hibernate/pull/73
> https://github.com/jbosstools/jbosstools-bpel/pull/25
> https://github.com/jbosstools/jbosstools-base/pull/407
>
> I've omitted changing anything in poms that declare a MAVEN dependency
> to JUnit 3.8, since that should still be resolved by Maven (not by p2).
>
> Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.
>
> On 05/21/2015 09:20 PM, Nick Boldt wrote:
>> The following projects have plugins or features which depend on JUnit 3.8.
>>
>> Can they be changed to use JUnit 4.12, which is the version included in
>> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
>>
>> * base
>> * bpel
>> * central
>> * forge
>> * hibernate
>> * javaee
>> * jst
>> * portlet
>> * vpe
>>
>> Or do we need to find a way to include JUnit 3.8 as well as JUnit 4.12?
>>
>> Details here: https://issues.jboss.org/browse/JBIDE-19836
>>


From manderse at redhat.com  Fri May 22 12:05:16 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 22 May 2015 12:05:16 -0400 (EDT)
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
	JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target
	platform w/ Mars M7)
In-Reply-To: <555F4897.2080407@redhat.com>
References: <555E8455.8050908@redhat.com> <555F484A.4090808@redhat.com>
	<555F4897.2080407@redhat.com>
Message-ID: <E77088DC-ED0D-4E23-B09C-3D0DF8608930@redhat.com>

Your junit tests does not use anything that requires junit 4 ?

You should at least set the minimum boundary. 

/max
http://about.me/maxandersen


> On 22 May 2015, at 17:17, George Gastaldi <ggastald at redhat.com> wrote:
> 
> Another hint as Nick proposed is to remove the JUnit version constraint. 
> I'm doing that for Forge
> 
>> On 05/22/2015 12:16 PM, Nick Boldt wrote:
>> Some PRs to consider, which fix MANIFEST.MF and feature.xml files to
>> depend on 4.12.0 instead of 3.8.x:
>> 
>> https://github.com/jbosstools/jbosstools-forge/pull/140
>> https://github.com/jbosstools/jbosstools-vpe/pull/311
>> https://github.com/jbosstools/jbosstools-portlet/pull/33
>> https://github.com/jbosstools/jbosstools-jst/pull/487
>> https://github.com/jbosstools/jbosstools-javaee/pull/340
>> https://github.com/jbosstools/jbosstools-hibernate/pull/73
>> https://github.com/jbosstools/jbosstools-bpel/pull/25
>> https://github.com/jbosstools/jbosstools-base/pull/407
>> 
>> I've omitted changing anything in poms that declare a MAVEN dependency
>> to JUnit 3.8, since that should still be resolved by Maven (not by p2).
>> 
>> Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.
>> 
>>> On 05/21/2015 09:20 PM, Nick Boldt wrote:
>>> The following projects have plugins or features which depend on JUnit 3.8.
>>> 
>>> Can they be changed to use JUnit 4.12, which is the version included in
>>> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
>>> 
>>> * base
>>> * bpel
>>> * central
>>> * forge
>>> * hibernate
>>> * javaee
>>> * jst
>>> * portlet
>>> * vpe
>>> 
>>> Or do we need to find a way to include JUnit 3.8 as well as JUnit 4.12?
>>> 
>>> Details here: https://issues.jboss.org/browse/JBIDE-19836
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From dgolovin at exadel.com  Fri May 22 12:09:57 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Fri, 22 May 2015 09:09:57 -0700
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
 JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars
 M7)
In-Reply-To: <E77088DC-ED0D-4E23-B09C-3D0DF8608930@redhat.com>
References: <555E8455.8050908@redhat.com> <555F484A.4090808@redhat.com>
	<555F4897.2080407@redhat.com>
	<E77088DC-ED0D-4E23-B09C-3D0DF8608930@redhat.com>
Message-ID: <CAJXFskYaS+YFjDE0oWhtb4yOh6VOjR7PNG8GHHGE4h78eOLAsw@mail.gmail.com>

i tested full build yesterday and only javaee requires to update some
features (see https://github.com/jbosstools/jbosstools-javaee/pull/339)
Everything else is fine.

On Fri, May 22, 2015 at 9:05 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> Your junit tests does not use anything that requires junit 4 ?
>
> You should at least set the minimum boundary.
>
> /max
> http://about.me/maxandersen
>
>
> > On 22 May 2015, at 17:17, George Gastaldi <ggastald at redhat.com> wrote:
> >
> > Another hint as Nick proposed is to remove the JUnit version constraint.
> > I'm doing that for Forge
> >
> >> On 05/22/2015 12:16 PM, Nick Boldt wrote:
> >> Some PRs to consider, which fix MANIFEST.MF and feature.xml files to
> >> depend on 4.12.0 instead of 3.8.x:
> >>
> >> https://github.com/jbosstools/jbosstools-forge/pull/140
> >> https://github.com/jbosstools/jbosstools-vpe/pull/311
> >> https://github.com/jbosstools/jbosstools-portlet/pull/33
> >> https://github.com/jbosstools/jbosstools-jst/pull/487
> >> https://github.com/jbosstools/jbosstools-javaee/pull/340
> >> https://github.com/jbosstools/jbosstools-hibernate/pull/73
> >> https://github.com/jbosstools/jbosstools-bpel/pull/25
> >> https://github.com/jbosstools/jbosstools-base/pull/407
> >>
> >> I've omitted changing anything in poms that declare a MAVEN dependency
> >> to JUnit 3.8, since that should still be resolved by Maven (not by p2).
> >>
> >> Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.
> >>
> >>> On 05/21/2015 09:20 PM, Nick Boldt wrote:
> >>> The following projects have plugins or features which depend on JUnit
> 3.8.
> >>>
> >>> Can they be changed to use JUnit 4.12, which is the version included in
> >>> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
> >>>
> >>> * base
> >>> * bpel
> >>> * central
> >>> * forge
> >>> * hibernate
> >>> * javaee
> >>> * jst
> >>> * portlet
> >>> * vpe
> >>>
> >>> Or do we need to find a way to include JUnit 3.8 as well as JUnit 4.12?
> >>>
> >>> Details here: https://issues.jboss.org/browse/JBIDE-19836
> >
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150522/3adde0e8/attachment.html 

From nboldt at redhat.com  Fri May 22 12:30:16 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 22 May 2015 12:30:16 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
 JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars
 M7)
In-Reply-To: <CAJXFskYaS+YFjDE0oWhtb4yOh6VOjR7PNG8GHHGE4h78eOLAsw@mail.gmail.com>
References: <555E8455.8050908@redhat.com>
	<555F484A.4090808@redhat.com>	<555F4897.2080407@redhat.com>	<E77088DC-ED0D-4E23-B09C-3D0DF8608930@redhat.com>
	<CAJXFskYaS+YFjDE0oWhtb4yOh6VOjR7PNG8GHHGE4h78eOLAsw@mail.gmail.com>
Message-ID: <555F5998.8030206@redhat.com>

You must not have run all the tests. coretests failed in Jenkins with 
this error:

[ERROR]   Missing requirement: 
org.jboss.tools.batch.test.feature.feature.group 
1.7.0.Beta1-v20150520-2011-B779 requires 'org.junit [3.8.1,4.0.0)' but 
it could not be found

https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.coretests-site_master/4370/console

Everything else is NOT fine. :D

On 05/22/2015 12:09 PM, Denis Golovin wrote:
> i tested full build yesterday and only javaee requires to update some
> features (see https://github.com/jbosstools/jbosstools-javaee/pull/339)
> Everything else is fine.
>
> On Fri, May 22, 2015 at 9:05 AM, Max Rydahl Andersen
> <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>
>     Your junit tests does not use anything that requires junit 4 ?
>
>     You should at least set the minimum boundary.
>
>     /max
>     http://about.me/maxandersen
>
>
>      > On 22 May 2015, at 17:17, George Gastaldi <ggastald at redhat.com
>     <mailto:ggastald at redhat.com>> wrote:
>      >
>      > Another hint as Nick proposed is to remove the JUnit version
>     constraint.
>      > I'm doing that for Forge
>      >
>      >> On 05/22/2015 12:16 PM, Nick Boldt wrote:
>      >> Some PRs to consider, which fix MANIFEST.MF and feature.xml files to
>      >> depend on 4.12.0 instead of 3.8.x:
>      >>
>      >> https://github.com/jbosstools/jbosstools-forge/pull/140
>      >> https://github.com/jbosstools/jbosstools-vpe/pull/311
>      >> https://github.com/jbosstools/jbosstools-portlet/pull/33
>      >> https://github.com/jbosstools/jbosstools-jst/pull/487
>      >> https://github.com/jbosstools/jbosstools-javaee/pull/340
>      >> https://github.com/jbosstools/jbosstools-hibernate/pull/73
>      >> https://github.com/jbosstools/jbosstools-bpel/pull/25
>      >> https://github.com/jbosstools/jbosstools-base/pull/407
>      >>
>      >> I've omitted changing anything in poms that declare a MAVEN
>     dependency
>      >> to JUnit 3.8, since that should still be resolved by Maven (not
>     by p2).
>      >>
>      >> Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.
>      >>
>      >>> On 05/21/2015 09:20 PM, Nick Boldt wrote:
>      >>> The following projects have plugins or features which depend on
>     JUnit 3.8.
>      >>>
>      >>> Can they be changed to use JUnit 4.12, which is the version
>     included in
>      >>> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
>      >>>
>      >>> * base
>      >>> * bpel
>      >>> * central
>      >>> * forge
>      >>> * hibernate
>      >>> * javaee
>      >>> * jst
>      >>> * portlet
>      >>> * vpe
>      >>>
>      >>> Or do we need to find a way to include JUnit 3.8 as well as
>     JUnit 4.12?
>      >>>
>      >>> Details here: https://issues.jboss.org/browse/JBIDE-19836
>      >
>      > _______________________________________________
>      > jbosstools-dev mailing list
>      > jbosstools-dev at lists.jboss.org
>     <mailto:jbosstools-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>     _______________________________________________
>     jbosstools-dev mailing list
>     jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From dgolovin at exadel.com  Fri May 22 13:30:51 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Fri, 22 May 2015 10:30:51 -0700
Subject: [jbosstools-dev] ACTION REQUIRED: Can we move up to requiring
 JUnit 4.12 instead of 3.8? (4.50.0.Beta1-SNAPSHOT target platform w/ Mars
 M7)
In-Reply-To: <555F5998.8030206@redhat.com>
References: <555E8455.8050908@redhat.com> <555F484A.4090808@redhat.com>
	<555F4897.2080407@redhat.com>
	<E77088DC-ED0D-4E23-B09C-3D0DF8608930@redhat.com>
	<CAJXFskYaS+YFjDE0oWhtb4yOh6VOjR7PNG8GHHGE4h78eOLAsw@mail.gmail.com>
	<555F5998.8030206@redhat.com>
Message-ID: <CAJXFskbFqqhjbO3ppOoyvy8vBYcHs3EqVW6LzETopLj9xg-DfQ@mail.gmail.com>

You are correct, I did not. But error you mention is exactly what I have
fixed :)
But you probably right about migration to exact version of JUnit, because
if we declare range [3.8.0,5.0.0) for instance, it means we have to in some
way check 3.8.0 works as well, since we are not going to do that lets move
up to [4.12.0, 5.0.0) or even to open range starting from 4.12.0.

Denis

On Fri, May 22, 2015 at 9:30 AM, Nick Boldt <nboldt at redhat.com> wrote:

> You must not have run all the tests. coretests failed in Jenkins with
> this error:
>
> [ERROR]   Missing requirement:
> org.jboss.tools.batch.test.feature.feature.group
> 1.7.0.Beta1-v20150520-2011-B779 requires 'org.junit [3.8.1,4.0.0)' but
> it could not be found
>
>
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build-sites.aggregate.coretests-site_master/4370/console
>
> Everything else is NOT fine. :D
>
> On 05/22/2015 12:09 PM, Denis Golovin wrote:
> > i tested full build yesterday and only javaee requires to update some
> > features (see https://github.com/jbosstools/jbosstools-javaee/pull/339)
> > Everything else is fine.
> >
> > On Fri, May 22, 2015 at 9:05 AM, Max Rydahl Andersen
> > <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
> >
> >     Your junit tests does not use anything that requires junit 4 ?
> >
> >     You should at least set the minimum boundary.
> >
> >     /max
> >     http://about.me/maxandersen
> >
> >
> >      > On 22 May 2015, at 17:17, George Gastaldi <ggastald at redhat.com
> >     <mailto:ggastald at redhat.com>> wrote:
> >      >
> >      > Another hint as Nick proposed is to remove the JUnit version
> >     constraint.
> >      > I'm doing that for Forge
> >      >
> >      >> On 05/22/2015 12:16 PM, Nick Boldt wrote:
> >      >> Some PRs to consider, which fix MANIFEST.MF and feature.xml
> files to
> >      >> depend on 4.12.0 instead of 3.8.x:
> >      >>
> >      >> https://github.com/jbosstools/jbosstools-forge/pull/140
> >      >> https://github.com/jbosstools/jbosstools-vpe/pull/311
> >      >> https://github.com/jbosstools/jbosstools-portlet/pull/33
> >      >> https://github.com/jbosstools/jbosstools-jst/pull/487
> >      >> https://github.com/jbosstools/jbosstools-javaee/pull/340
> >      >> https://github.com/jbosstools/jbosstools-hibernate/pull/73
> >      >> https://github.com/jbosstools/jbosstools-bpel/pull/25
> >      >> https://github.com/jbosstools/jbosstools-base/pull/407
> >      >>
> >      >> I've omitted changing anything in poms that declare a MAVEN
> >     dependency
> >      >> to JUnit 3.8, since that should still be resolved by Maven (not
> >     by p2).
> >      >>
> >      >> Lookin' at you, Central (Maven), JavaEE (CDI & JSF), and VPE.
> >      >>
> >      >>> On 05/21/2015 09:20 PM, Nick Boldt wrote:
> >      >>> The following projects have plugins or features which depend on
> >     JUnit 3.8.
> >      >>>
> >      >>> Can they be changed to use JUnit 4.12, which is the version
> >     included in
> >      >>> the latest 4.50.0.Beta1-SNAPSHOT target platform and Mars M7?
> >      >>>
> >      >>> * base
> >      >>> * bpel
> >      >>> * central
> >      >>> * forge
> >      >>> * hibernate
> >      >>> * javaee
> >      >>> * jst
> >      >>> * portlet
> >      >>> * vpe
> >      >>>
> >      >>> Or do we need to find a way to include JUnit 3.8 as well as
> >     JUnit 4.12?
> >      >>>
> >      >>> Details here: https://issues.jboss.org/browse/JBIDE-19836
> >      >
> >      > _______________________________________________
> >      > jbosstools-dev mailing list
> >      > jbosstools-dev at lists.jboss.org
> >     <mailto:jbosstools-dev at lists.jboss.org>
> >      > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> >
> >     _______________________________________________
> >     jbosstools-dev mailing list
> >     jbosstools-dev at lists.jboss.org <mailto:
> jbosstools-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> >
> >
> >
> >
> > _______________________________________________
> > jbosstools-dev mailing list
> > jbosstools-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> >
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150522/4a9dfe16/attachment-0001.html 

From dgolovin at exadel.com  Fri May 22 14:18:05 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Fri, 22 May 2015 11:18:05 -0700
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <555E65CE.5040401@redhat.com>
References: <554B924B.6090505@redhat.com> <554BAFD7.7040403@exadel.com>
	<554BBC20.4070902@redhat.com>
	<DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>
	<55550B6F.4080303@redhat.com> <555E65CE.5040401@redhat.com>
Message-ID: <CAJXFska5Qcs7ELp4zS3409dmRSUh1C_mo4nscVC=1kfDsJnQwQ@mail.gmail.com>

... and build fails ;(

INFO] [ERROR] Cannot resolve project dependencies:
[INFO] [ERROR]   Software being installed: org.jboss.tools.aerogear.thym
1.3.0.qualifier
[INFO] [ERROR]   Missing requirement: org.eclipse.thym.core
0.3.0.201504151706 requires 'bundle org.eclipse.core.expressions
[3.4.0,3.5.0)' but it could not be found
[INFO] [ERROR]   Cannot satisfy dependency: org.jboss.tools.aerogear.thym
1.3.0.qualifier depends on: bundle org.eclipse.thym.core 0.1.0



On Thu, May 21, 2015 at 4:10 PM, Nick Boldt <nboldt at redhat.com> wrote:

> Target platform 4.50.0.Beta1-SNAPSHOT has been updated to Mars M7.
>
> The decision was made today to have JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1
> prereq JDK 8 as a Bundle-RequireExecutionEnvironment (BREE).
>
> As such, Arquillian plugins that depend on Sapphire 9 have now been set
> to a BREE of JavaSE-1.8 [1]. See JBIDE-19753.
>
> [1]
>
> https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9
>
> Server Tools has also been updated to take advantage of the new
> tm.terminal.* 4.0 plugins in place of the old tm.terminal 3.1 plugin.
> See JBIDE-19776.
>
> --
>
> Next week, when it becomes available, we will start a new PR to update
> the target platform to Mars RC2.
>
> Reminder that code freeze for Beta1 is in TWO WEEKS on June 4, so the
> finalized 4.50.0.Beta1 target platforms for JBT and JBDS need to be
> released by June 3 at the latest.
>
> Stay tuned!
>
> On 05/14/2015 04:54 PM, Nick Boldt wrote:
> > Some more updates to the M7 TP, while we decide what to do about
> > Sapphire / Java 8.
> >
> > * remove fest (it was commented out already)
> >
> > * add org.eclipse.tm.terminal.control.feature.feature.group
> > (rse.terminals requires it); remove old org.junit
> > 3.8.2.v3_8_2_v20130308-0410
> >
> > * add org.eclipse.egit.ui.importer 0.0.1.201505070847 (needed for
> > easymport)
> >
> > * jbosstools-server requests that the new tm.terminal views/connectors
> > be installed along with it, so add org.eclipse.tm.terminal.*,
> > connector.local.feature and org.eclipse.cdt.core.native.feature
> > (JBIDE-17686, JBIDE-19776)
> >
> > * Switch to Mockito 1.9.5.v20131024-0922 (from Locus 1.2.0.Final site)
> >
> > If you haven't tried the latest M7 TP, please do so from this PR:
> >
> > https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
> >
> > On 05/08/2015 04:02 AM, Max Rydahl Andersen wrote:
> >> On 7 May 2015, at 21:25, Mickael Istria wrote:
> >>
> >>> On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
> >>>>
> >>>> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
> >>>> Sapphire was updated in M7 and this version is not compatible with
> >>>> Sapphire v.9.0.0.201408261741 which was included in Mars TP before
> >>>> (M1-M6)
> >>>> Batch and Arquillian tools require Sapphire. It's not a big deal for
> >>>> us to migrate Batch and Arquillian to new Sapphire API.
> >>>> But the problem is that the new Sapphire (M7) has
> >>>> *RequiredExecutionEnvironment: JavaSE-1.8*
> >>> Too bad this wasn't spotted earlier. Is anyone following the Sapphire
> >>> mailing-list or bugzilla component?
> >>
> >>
> >> Sapphire announced it here:
> >> https://www.eclipse.org/forums/index.php/t/890531/ back in January and
> >> yes, really bad we did not catch that.
> >>
> >> But we did monitor the release train but Sapphire did not put this
> >> change until M7. Where it is IMO is too late as said over here
> >> https://www.eclipse.org/forums/index.php/m/1694326
> >>
> >> But Konstantin from Sapphire seem to not care about that ;/
> >>
> >>>> If we can't require Java 8 for Batch and Arquillian then we have to
> >>>> switch to Sapphire 8.2 from 9.0 in our TP.
> >>>> Sapphire 8.2 supports Mars but Mars update site includes Sapphire
> >>>> 9.0. only.
> >>>> How are we going to deal with that?
> >>> Well, Java 7 has reached end-of-life a few days ago, so I would
> >>> support the idea of requiring Java 8 for those components. If they are
> >>> part of JBDS default package, then it means that JBDS will also
> >>> require Java 8.
> >>> If we want to keep Java 7, we can simply include only Sapphire 8.2 in
> >>> the target-platform and keep Sapphire 9.0 out. But I guess Sapphire
> >>> 8.2 and 9.0 cannot be installed simultaneously; can they?
> >>
> >> Konstantin claims they can - as long as you don't include two colliding
> >> features that requires them.
> >>
> >>> If not, then we need to make sure no other project that is important
> >>> to us and that we want to work together with JBoss Tools relies on
> >>> newer Sapphire.
> >>> So is anyone aware of some other project that requires Sapphire and
> >>> that we'd like to keep compatible with?
> >>
> >> I've raised question internally to see if any objections against raising
> >> to Java 8 since Java 7 is EOL'ed now *and* it seems its usage is
> >> declining faster than Java 6 did.
> >>
> >> /max
> >> http://about.me/maxandersen
> >> _______________________________________________
> >> jbosstools-dev mailing list
> >> jbosstools-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> >>
> >
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150522/9bbb4fe5/attachment.html 

From dgolovin at exadel.com  Fri May 22 14:31:28 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Fri, 22 May 2015 11:31:28 -0700
Subject: [jbosstools-dev] ACTION REQUIRED: Update target platform
 4.50.0.Beta1-SNAPSHOT to Mars M7
In-Reply-To: <CAJXFska5Qcs7ELp4zS3409dmRSUh1C_mo4nscVC=1kfDsJnQwQ@mail.gmail.com>
References: <554B924B.6090505@redhat.com> <554BAFD7.7040403@exadel.com>
	<554BBC20.4070902@redhat.com>
	<DD219C25-6B43-4F51-AE27-B3F933E6F5B2@redhat.com>
	<55550B6F.4080303@redhat.com> <555E65CE.5040401@redhat.com>
	<CAJXFska5Qcs7ELp4zS3409dmRSUh1C_mo4nscVC=1kfDsJnQwQ@mail.gmail.com>
Message-ID: <CAJXFskZHYQgC6ku5sRLcOZArtyuWBvKKEiYoFAfS46KQmiQ2Wg@mail.gmail.com>

False alarm, that was problem with my local settings.xml file.

On Fri, May 22, 2015 at 11:18 AM, Denis Golovin <dgolovin at exadel.com> wrote:

> ... and build fails ;(
>
> INFO] [ERROR] Cannot resolve project dependencies:
> [INFO] [ERROR]   Software being installed: org.jboss.tools.aerogear.thym
> 1.3.0.qualifier
> [INFO] [ERROR]   Missing requirement: org.eclipse.thym.core
> 0.3.0.201504151706 requires 'bundle org.eclipse.core.expressions
> [3.4.0,3.5.0)' but it could not be found
> [INFO] [ERROR]   Cannot satisfy dependency: org.jboss.tools.aerogear.thym
> 1.3.0.qualifier depends on: bundle org.eclipse.thym.core 0.1.0
>
>
>
> On Thu, May 21, 2015 at 4:10 PM, Nick Boldt <nboldt at redhat.com> wrote:
>
>> Target platform 4.50.0.Beta1-SNAPSHOT has been updated to Mars M7.
>>
>> The decision was made today to have JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1
>> prereq JDK 8 as a Bundle-RequireExecutionEnvironment (BREE).
>>
>> As such, Arquillian plugins that depend on Sapphire 9 have now been set
>> to a BREE of JavaSE-1.8 [1]. See JBIDE-19753.
>>
>> [1]
>>
>> https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9
>>
>> Server Tools has also been updated to take advantage of the new
>> tm.terminal.* 4.0 plugins in place of the old tm.terminal 3.1 plugin.
>> See JBIDE-19776.
>>
>> --
>>
>> Next week, when it becomes available, we will start a new PR to update
>> the target platform to Mars RC2.
>>
>> Reminder that code freeze for Beta1 is in TWO WEEKS on June 4, so the
>> finalized 4.50.0.Beta1 target platforms for JBT and JBDS need to be
>> released by June 3 at the latest.
>>
>> Stay tuned!
>>
>> On 05/14/2015 04:54 PM, Nick Boldt wrote:
>> > Some more updates to the M7 TP, while we decide what to do about
>> > Sapphire / Java 8.
>> >
>> > * remove fest (it was commented out already)
>> >
>> > * add org.eclipse.tm.terminal.control.feature.feature.group
>> > (rse.terminals requires it); remove old org.junit
>> > 3.8.2.v3_8_2_v20130308-0410
>> >
>> > * add org.eclipse.egit.ui.importer 0.0.1.201505070847 (needed for
>> > easymport)
>> >
>> > * jbosstools-server requests that the new tm.terminal views/connectors
>> > be installed along with it, so add org.eclipse.tm.terminal.*,
>> > connector.local.feature and org.eclipse.cdt.core.native.feature
>> > (JBIDE-17686, JBIDE-19776)
>> >
>> > * Switch to Mockito 1.9.5.v20131024-0922 (from Locus 1.2.0.Final site)
>> >
>> > If you haven't tried the latest M7 TP, please do so from this PR:
>> >
>> > https://github.com/jbosstools/jbosstools-target-platforms/pull/142/
>> >
>> > On 05/08/2015 04:02 AM, Max Rydahl Andersen wrote:
>> >> On 7 May 2015, at 21:25, Mickael Istria wrote:
>> >>
>> >>> On 05/07/2015 08:32 PM, Alexey Kazakov wrote:
>> >>>>
>> >>>> The new TP includes the updated Sapphire v. 9.0.0.201505051659.
>> >>>> Sapphire was updated in M7 and this version is not compatible with
>> >>>> Sapphire v.9.0.0.201408261741 which was included in Mars TP before
>> >>>> (M1-M6)
>> >>>> Batch and Arquillian tools require Sapphire. It's not a big deal for
>> >>>> us to migrate Batch and Arquillian to new Sapphire API.
>> >>>> But the problem is that the new Sapphire (M7) has
>> >>>> *RequiredExecutionEnvironment: JavaSE-1.8*
>> >>> Too bad this wasn't spotted earlier. Is anyone following the Sapphire
>> >>> mailing-list or bugzilla component?
>> >>
>> >>
>> >> Sapphire announced it here:
>> >> https://www.eclipse.org/forums/index.php/t/890531/ back in January and
>> >> yes, really bad we did not catch that.
>> >>
>> >> But we did monitor the release train but Sapphire did not put this
>> >> change until M7. Where it is IMO is too late as said over here
>> >> https://www.eclipse.org/forums/index.php/m/1694326
>> >>
>> >> But Konstantin from Sapphire seem to not care about that ;/
>> >>
>> >>>> If we can't require Java 8 for Batch and Arquillian then we have to
>> >>>> switch to Sapphire 8.2 from 9.0 in our TP.
>> >>>> Sapphire 8.2 supports Mars but Mars update site includes Sapphire
>> >>>> 9.0. only.
>> >>>> How are we going to deal with that?
>> >>> Well, Java 7 has reached end-of-life a few days ago, so I would
>> >>> support the idea of requiring Java 8 for those components. If they are
>> >>> part of JBDS default package, then it means that JBDS will also
>> >>> require Java 8.
>> >>> If we want to keep Java 7, we can simply include only Sapphire 8.2 in
>> >>> the target-platform and keep Sapphire 9.0 out. But I guess Sapphire
>> >>> 8.2 and 9.0 cannot be installed simultaneously; can they?
>> >>
>> >> Konstantin claims they can - as long as you don't include two colliding
>> >> features that requires them.
>> >>
>> >>> If not, then we need to make sure no other project that is important
>> >>> to us and that we want to work together with JBoss Tools relies on
>> >>> newer Sapphire.
>> >>> So is anyone aware of some other project that requires Sapphire and
>> >>> that we'd like to keep compatible with?
>> >>
>> >> I've raised question internally to see if any objections against
>> raising
>> >> to Java 8 since Java 7 is EOL'ed now *and* it seems its usage is
>> >> declining faster than Java 6 did.
>> >>
>> >> /max
>> >> http://about.me/maxandersen
>> >> _______________________________________________
>> >> jbosstools-dev mailing list
>> >> jbosstools-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> >>
>> >
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150522/a68e77cd/attachment-0001.html 

From manderse at redhat.com  Fri May 22 14:49:44 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 22 May 2015 20:49:44 +0200
Subject: [jbosstools-dev] Java 8 experiement for JBoss Tools 4.3/Developer
	studio 9
Message-ID: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>

Hey,

We are going to make Java 8 required for upcoming Beta1.

To see what kind of reaction we will get on moving to Java 8.

This does *not* mean you should add Java 8 features to the codebase.

We will still compile with Java 7 where we can, as we might be
required to support Java 7 before GA.

Thus don't get too excited - but at least be happy users
will run with a faster Java with better memory management!

/max
http://about.me/maxandersen

From ggastald at redhat.com  Fri May 22 14:51:40 2015
From: ggastald at redhat.com (George Gastaldi)
Date: Fri, 22 May 2015 15:51:40 -0300
Subject: [jbosstools-dev] Java 8 experiement for JBoss Tools
 4.3/Developer studio 9
In-Reply-To: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
Message-ID: <555F7ABC.7050206@redhat.com>

Forge is compiled against JDK 7 but it is fully Java 8 compatible.

On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
> Hey,
>
> We are going to make Java 8 required for upcoming Beta1.
>
> To see what kind of reaction we will get on moving to Java 8.
>
> This does *not* mean you should add Java 8 features to the codebase.
>
> We will still compile with Java 7 where we can, as we might be
> required to support Java 7 before GA.
>
> Thus don't get too excited - but at least be happy users
> will run with a faster Java with better memory management!
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From manderse at redhat.com  Sat May 23 04:01:38 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 23 May 2015 04:01:38 -0400 (EDT)
Subject: [jbosstools-dev] Java 8 experiement for JBoss Tools
	4.3/Developer studio 9
In-Reply-To: <555F7ABC.7050206@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
	<555F7ABC.7050206@redhat.com>
Message-ID: <700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>



> Forge is compiled against JDK 7 but it is fully Java 8 compatible.

Yes - not following what your point is here. That's how all parts of JBDS 8 and JBoss tools 4.2.x was. It's also what jbds 9 will be for now - but exploring if we must support java 7 or have to do tricks to have only certain parts of jbds 8 require java 8. 

Such as arquillian and batch Java EE tooling. 


>> On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
>> Hey,
>> 
>> We are going to make Java 8 required for upcoming Beta1.
>> 
>> To see what kind of reaction we will get on moving to Java 8.
>> 
>> This does *not* mean you should add Java 8 features to the codebase.
>> 
>> We will still compile with Java 7 where we can, as we might be
>> required to support Java 7 before GA.
>> 
>> Thus don't get too excited - but at least be happy users
>> will run with a faster Java with better memory management!
>> 
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From nboldt at redhat.com  Sat May 23 12:10:53 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Sat, 23 May 2015 12:10:53 -0400
Subject: [jbosstools-dev] Java 8 experiement for JBoss Tools
 4.3/Developer studio 9
In-Reply-To: <700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>	<555F7ABC.7050206@redhat.com>
	<700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>
Message-ID: <5560A68D.50001@redhat.com>

Just FYI:

If you DO introduce a Bundle-RequireExecutionEnvironment of JavaSE-1.8 
into a plugin, please make sure you also update your Jenkins job 
accordingly.

---

(Lengthy explanation follows.)

If BREE = JavaeSE-1.8, then you can't compile it & successfully run 
tests with JDK 7.

Since Arquillian depends on Sapphire 9 [0], which requires JDK 8, now 
too Arquillian requires JDK 8 to build. Its jobs have been updated.

[0] 
https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9

Note that anything that needs to INCLUDE these BREE=JavaSE-1.8 bundles 
must ALSO be built with JDK 8 or Tycho can't resolve the bundles at 
build time. I've updated the Arquillian, JBT aggregate, and JBDS jobs to 
use jdk1.8 instead of jdk1.7.

?

This commit [1] broke this build [2] but after updating the job config 
to use jdk1.8, it's back to blue [3].

[1] 
https://github.com/jbosstools/jbosstools-base/commit/700dbf9b166072d394c9c15baad7951a53da8e55
[2] 
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/715/
[3] 
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/ 
 >=716


On 05/23/2015 04:01 AM, Max Rydahl Andersen wrote:
>
>
>> Forge is compiled against JDK 7 but it is fully Java 8 compatible.
>
> Yes - not following what your point is here. That's how all parts of JBDS 8 and JBoss tools 4.2.x was. It's also what jbds 9 will be for now - but exploring if we must support java 7 or have to do tricks to have only certain parts of jbds 8 require java 8.
>
> Such as arquillian and batch Java EE tooling.
>
>
>>> On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
>>> Hey,
>>>
>>> We are going to make Java 8 required for upcoming Beta1.
>>>
>>> To see what kind of reaction we will get on moving to Java 8.
>>>
>>> This does *not* mean you should add Java 8 features to the codebase.
>>>
>>> We will still compile with Java 7 where we can, as we might be
>>> required to support Java 7 before GA.
>>>
>>> Thus don't get too excited - but at least be happy users
>>> will run with a faster Java with better memory management!
>>>
>>> /max
>>> http://about.me/maxandersen
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Sun May 24 01:51:32 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sun, 24 May 2015 07:51:32 +0200
Subject: [jbosstools-dev] Java 8 experiement for JBoss Tools
 4.3/Developer studio 9
In-Reply-To: <5560A68D.50001@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
	<555F7ABC.7050206@redhat.com>
	<700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>
	<5560A68D.50001@redhat.com>
Message-ID: <B7050414-CF4B-4351-A373-872FF2AEF551@redhat.com>

On 23 May 2015, at 18:10, Nick Boldt wrote:

> Just FYI:
>
> If you DO introduce a Bundle-RequireExecutionEnvironment of JavaSE-1.8 
> into a plugin, please make sure you also update your Jenkins job 
> accordingly.

crap, then tycho got picky ;/

tycho shouldn't be limiting its build options based on runtime execution 
environments.

if it is then the idea about changing foundation to require it to just 
make install fails on Java 7 was a Bad idea.

Anyone with a better idea on how we can make the installation require 
Java 8, but not require it at build time ?

/max

> ---
>
> (Lengthy explanation follows.)
>
> If BREE = JavaeSE-1.8, then you can't compile it & successfully run 
> tests with JDK 7.
>
> Since Arquillian depends on Sapphire 9 [0], which requires JDK 8, now 
> too Arquillian requires JDK 8 to build. Its jobs have been updated.
>
> [0] 
> https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9
>
> Note that anything that needs to INCLUDE these BREE=JavaSE-1.8 bundles 
> must ALSO be built with JDK 8 or Tycho can't resolve the bundles at 
> build time. I've updated the Arquillian, JBT aggregate, and JBDS jobs 
> to use jdk1.8 instead of jdk1.7.
>
> ?
>
> This commit [1] broke this build [2] but after updating the job config 
> to use jdk1.8, it's back to blue [3].
>
> [1] 
> https://github.com/jbosstools/jbosstools-base/commit/700dbf9b166072d394c9c15baad7951a53da8e55
> [2] 
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/715/
> [3] 
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/ 
>  >=716
>
>
> On 05/23/2015 04:01 AM, Max Rydahl Andersen wrote:
>>
>>
>>> Forge is compiled against JDK 7 but it is fully Java 8 compatible.
>>
>> Yes - not following what your point is here. That's how all parts of 
>> JBDS 8 and JBoss tools 4.2.x was. It's also what jbds 9 will be for 
>> now - but exploring if we must support java 7 or have to do tricks to 
>> have only certain parts of jbds 8 require java 8.
>>
>> Such as arquillian and batch Java EE tooling.
>>
>>
>>>> On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
>>>> Hey,
>>>>
>>>> We are going to make Java 8 required for upcoming Beta1.
>>>>
>>>> To see what kind of reaction we will get on moving to Java 8.
>>>>
>>>> This does *not* mean you should add Java 8 features to the 
>>>> codebase.
>>>>
>>>> We will still compile with Java 7 where we can, as we might be
>>>> required to support Java 7 before GA.
>>>>
>>>> Thus don't get too excited - but at least be happy users
>>>> will run with a faster Java with better memory management!
>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com


/max
http://about.me/maxandersen


From nboldt at redhat.com  Mon May 25 09:17:01 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Mon, 25 May 2015 09:17:01 -0400
Subject: [jbosstools-dev] Java 8 experiment for JBoss Tools
 4.3/Developer studio 9
In-Reply-To: <B7050414-CF4B-4351-A373-872FF2AEF551@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
	<555F7ABC.7050206@redhat.com>
	<700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>
	<5560A68D.50001@redhat.com>
	<B7050414-CF4B-4351-A373-872FF2AEF551@redhat.com>
Message-ID: <556320CD.70503@redhat.com>

Actually, I should clarify. Seems that the BUILD may be ok w/ a lower 
JDK than the BREE specifies, but Surefire TESTING will surely NOT fire 
with the lower one, because the lower runtime environment is not 
compatible. And any "installation-like" step (like installing plugins 
into an update site build) will likely fail too.

But to your question, "how we can make the installation require Java 8, 
but not require it at build time?"...

I counter: "Given JDK 8 is everywhere (RHEL6.6, 7.1, Fedora, Ubuntu, 
Windows8, OSX) why can't we just build with the new standard baseline? 
Why encourage people to build w/ the EOL'd JDK 7?"

N

On 05/24/2015 01:51 AM, Max Rydahl Andersen wrote:
> On 23 May 2015, at 18:10, Nick Boldt wrote:
>
>> Just FYI:
>>
>> If you DO introduce a Bundle-RequireExecutionEnvironment of JavaSE-1.8
>> into a plugin, please make sure you also update your Jenkins job
>> accordingly.
>
> crap, then tycho got picky ;/
>
> tycho shouldn't be limiting its build options based on runtime execution
> environments.
>
> if it is then the idea about changing foundation to require it to just
> make install fails on Java 7 was a Bad idea.
>
> Anyone with a better idea on how we can make the installation require
> Java 8, but not require it at build time ?
>
> /max
>
>> ---
>>
>> (Lengthy explanation follows.)
>>
>> If BREE = JavaeSE-1.8, then you can't compile it & successfully run
>> tests with JDK 7.
>>
>> Since Arquillian depends on Sapphire 9 [0], which requires JDK 8, now
>> too Arquillian requires JDK 8 to build. Its jobs have been updated.
>>
>> [0]
>> https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9
>>
>>
>> Note that anything that needs to INCLUDE these BREE=JavaSE-1.8 bundles
>> must ALSO be built with JDK 8 or Tycho can't resolve the bundles at
>> build time. I've updated the Arquillian, JBT aggregate, and JBDS jobs
>> to use jdk1.8 instead of jdk1.7.
>>
>> ?
>>
>> This commit [1] broke this build [2] but after updating the job config
>> to use jdk1.8, it's back to blue [3].
>>
>> [1]
>> https://github.com/jbosstools/jbosstools-base/commit/700dbf9b166072d394c9c15baad7951a53da8e55
>>
>> [2]
>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/715/
>>
>> [3]
>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/
>>  >=716
>>
>>
>> On 05/23/2015 04:01 AM, Max Rydahl Andersen wrote:
>>>
>>>
>>>> Forge is compiled against JDK 7 but it is fully Java 8 compatible.
>>>
>>> Yes - not following what your point is here. That's how all parts of
>>> JBDS 8 and JBoss tools 4.2.x was. It's also what jbds 9 will be for
>>> now - but exploring if we must support java 7 or have to do tricks to
>>> have only certain parts of jbds 8 require java 8.
>>>
>>> Such as arquillian and batch Java EE tooling.
>>>
>>>
>>>>> On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
>>>>> Hey,
>>>>>
>>>>> We are going to make Java 8 required for upcoming Beta1.
>>>>>
>>>>> To see what kind of reaction we will get on moving to Java 8.
>>>>>
>>>>> This does *not* mean you should add Java 8 features to the codebase.
>>>>>
>>>>> We will still compile with Java 7 where we can, as we might be
>>>>> required to support Java 7 before GA.
>>>>>
>>>>> Thus don't get too excited - but at least be happy users
>>>>> will run with a faster Java with better memory management!
>>>>>
>>>>> /max
>>>>> http://about.me/maxandersen
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>
>
> /max
> http://about.me/maxandersen

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Mon May 25 18:14:11 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 26 May 2015 00:14:11 +0200
Subject: [jbosstools-dev] Java 8 experiment for JBoss Tools
 4.3/Developer studio 9
In-Reply-To: <556320CD.70503@redhat.com>
References: <C0A84F0A-D54F-4A31-87D7-ECBD85C1BAC7@redhat.com>
	<555F7ABC.7050206@redhat.com>
	<700D6EB9-2559-480D-A278-5F7EB148C3AA@redhat.com>
	<5560A68D.50001@redhat.com>
	<B7050414-CF4B-4351-A373-872FF2AEF551@redhat.com>
	<556320CD.70503@redhat.com>
Message-ID: <EBF362D9-3EFB-4C32-AADC-FDCC6F434D7F@redhat.com>

On 25 May 2015, at 15:17, Nick Boldt wrote:

> Actually, I should clarify. Seems that the BUILD may be ok w/ a lower 
> JDK than the BREE specifies, but Surefire TESTING will surely NOT fire 
> with the lower one, because the lower runtime environment is not 
> compatible. And any "installation-like" step (like installing plugins 
> into an update site build) will likely fail too.
>
> But to your question, "how we can make the installation require Java 
> 8, but not require it at build time?"...
>
> I counter: "Given JDK 8 is everywhere (RHEL6.6, 7.1, Fedora, Ubuntu, 
> Windows8, OSX) why can't we just build with the new standard baseline? 
> Why encourage people to build w/ the EOL'd JDK 7?"

Because this is what we agreed on doing for Beta1 - build with Java 7 
and require Java 8 for the install to get feedback and then if no major 
impact upgrade build and code to require Java 8.

As I wrote in mail about this update:
"To developers reading this: We still need to be able to roll back to 
Java 7, thus do not go use lambdas etc. yet!"

That means our codebase is not to depend on Java 8 yet - it was *just* 
for installs for beta1.

/max

>
> N
>
> On 05/24/2015 01:51 AM, Max Rydahl Andersen wrote:
>> On 23 May 2015, at 18:10, Nick Boldt wrote:
>>
>>> Just FYI:
>>>
>>> If you DO introduce a Bundle-RequireExecutionEnvironment of 
>>> JavaSE-1.8
>>> into a plugin, please make sure you also update your Jenkins job
>>> accordingly.
>>
>> crap, then tycho got picky ;/
>>
>> tycho shouldn't be limiting its build options based on runtime 
>> execution
>> environments.
>>
>> if it is then the idea about changing foundation to require it to 
>> just
>> make install fails on Java 7 was a Bad idea.
>>
>> Anyone with a better idea on how we can make the installation require
>> Java 8, but not require it at build time ?
>>
>> /max
>>
>>> ---
>>>
>>> (Lengthy explanation follows.)
>>>
>>> If BREE = JavaeSE-1.8, then you can't compile it & successfully run
>>> tests with JDK 7.
>>>
>>> Since Arquillian depends on Sapphire 9 [0], which requires JDK 8, 
>>> now
>>> too Arquillian requires JDK 8 to build. Its jobs have been updated.
>>>
>>> [0]
>>> https://github.com/jbosstools/jbosstools-arquillian/commit/13932fd9b917aad99ef7da98ef1edc2c4eac25f9
>>>
>>>
>>> Note that anything that needs to INCLUDE these BREE=JavaSE-1.8 
>>> bundles
>>> must ALSO be built with JDK 8 or Tycho can't resolve the bundles at
>>> build time. I've updated the Arquillian, JBT aggregate, and JBDS 
>>> jobs
>>> to use jdk1.8 instead of jdk1.7.
>>>
>>> ?
>>>
>>> This commit [1] broke this build [2] but after updating the job 
>>> config
>>> to use jdk1.8, it's back to blue [3].
>>>
>>> [1]
>>> https://github.com/jbosstools/jbosstools-base/commit/700dbf9b166072d394c9c15baad7951a53da8e55
>>>
>>> [2]
>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/715/
>>>
>>> [3]
>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/jbosstools-base_master/
>>> >=716
>>>
>>>
>>> On 05/23/2015 04:01 AM, Max Rydahl Andersen wrote:
>>>>
>>>>
>>>>> Forge is compiled against JDK 7 but it is fully Java 8 compatible.
>>>>
>>>> Yes - not following what your point is here. That's how all parts 
>>>> of
>>>> JBDS 8 and JBoss tools 4.2.x was. It's also what jbds 9 will be for
>>>> now - but exploring if we must support java 7 or have to do tricks 
>>>> to
>>>> have only certain parts of jbds 8 require java 8.
>>>>
>>>> Such as arquillian and batch Java EE tooling.
>>>>
>>>>
>>>>>> On 05/22/2015 03:49 PM, Max Rydahl Andersen wrote:
>>>>>> Hey,
>>>>>>
>>>>>> We are going to make Java 8 required for upcoming Beta1.
>>>>>>
>>>>>> To see what kind of reaction we will get on moving to Java 8.
>>>>>>
>>>>>> This does *not* mean you should add Java 8 features to the 
>>>>>> codebase.
>>>>>>
>>>>>> We will still compile with Java 7 where we can, as we might be
>>>>>> required to support Java 7 before GA.
>>>>>>
>>>>>> Thus don't get too excited - but at least be happy users
>>>>>> will run with a faster Java with better memory management!
>>>>>>
>>>>>> /max
>>>>>> http://about.me/maxandersen
>>>>>> _______________________________________________
>>>>>> jbosstools-dev mailing list
>>>>>> jbosstools-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>
>>> --
>>> Nick Boldt :: JBoss by Red Hat
>>> Productization Lead :: JBoss Tools & Dev Studio
>>> http://nick.divbyzero.com
>>
>>
>> /max
>> http://about.me/maxandersen
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com


/max
http://about.me/maxandersen


From noreply at beechwoodvets.com  Tue May 26 03:18:26 2015
From: noreply at beechwoodvets.com (New-Canadian-Meds)
Date: Tue, 26 May 2015 11:18:26 +0400
Subject: [jbosstools-dev] If you are still hesitating whether to buy
	medications at our pharmacy, read our testimonials!
Message-ID: <401ACE3FFD1A3DBBFFD3E5D417A23824D51CE@beechwoodvets.com>

   

		Miler to know about parlors for individualized programs james
actually. Publicist, so awesome, is costly liang, et al pastor. 

		Me
		ds
		0f
		or
		0M
		en

Vi
Ci
Ci
Le
Pr
 ag
al
al
vi
op
 ra
is
is
tr
ec

 S
a 
ia

of

t 

Ta

bs

 $0
$1
$2
$2
$0
 .9
.6
.5
.5
.4
 9
5
0
0
5

		Me
		ds
		3f
		or
		2W
		om
		en

Ac
Cl
De
Fe
Fe
 om
om
fl
ma
ma
 pl
id
uc
le
le
 ia

an
 C
 V

ia
ia

li
gr

s 
a 

 $1
$0
$1
$1
$0
 .7
.4
.2
.1
.7
 5
5
5
1
2

 24
Fa
On
An /7
st
ly
on  c
 w
 r
ym us
or
el
ou to
ld
ia
s  me
wi
bl
de r 
de
e 
li su
 s
su
ve pp
hi
pp
ry or
pp
li
  t 
in
er

g 
s 

   S
 V
 N
 1 pe
is
o 
00 ci
a,
pr
%  al
Ma
es
Au  i
st
cr
th nt
er
ip
en er
ca
ti
ti ne
rd
on
c  t 
,E
 r
Me pr
ch
eq
ds ic
ec
ui
  es
k 
re

d

		>> Enter Here 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150526/6bd7fd2e/attachment.html 

From xcoulon at redhat.com  Tue May 26 04:34:45 2015
From: xcoulon at redhat.com (Xavier Coulon)
Date: Tue, 26 May 2015 10:34:45 +0200
Subject: [jbosstools-dev] Improvement for the N&N "Related JIRA" macro in
	the website
Message-ID: <102FFD9F-276E-4B9B-B355-4465FA81FACD@redhat.com>

Hello,

FYI, I just fixed https://issues.jboss.org/browse/JBIDE-19588 <https://issues.jboss.org/browse/JBIDE-19588> and took the opportunity to improve the "related_jira" macro that we use to link a N&N entry to one or more issues in JIRA. 
You may now include the title of the issue in the brackets as below:

related_jira::JBIDE-19113[Update of wildfly jars]

This will render as follow in the web page:

"Related JIRA: JBIDE-19113 - Update of wildfly jars <https://issues.jboss.org/browse/JBIDE-19113>"

If you don't specify any attribute in the macro, the link title will just be the issue number.

Best regards,
/Xavier



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150526/668f67a7/attachment.html 

From rstryker at redhat.com  Tue May 26 12:39:13 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Tue, 26 May 2015 12:39:13 -0400
Subject: [jbosstools-dev] Who would I ping for new sysprop to all runtime
	installer jars?
Message-ID: <5564A1B1.2050407@redhat.com>

https://issues.jboss.org/browse/JBIDE-19852

When using dl-runtimes to install DV or FSW, it runs the installer jar.  
The installer jar does not respect the installation path the user set in 
the dl-runtimes wizard. It can't, obviously, bc we never transmit it to 
the installer at all.

It'd be great if we could agree on some sysprop we can set when running 
java -jar dv-6.1-installer.jar such that the installer checks it for a 
default installation folder.

Any ideas who I would ping over getting something like that implemented 
on the runtimes side?

- Rob Stryker

From manderse at redhat.com  Tue May 26 14:31:31 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 26 May 2015 20:31:31 +0200
Subject: [jbosstools-dev] Who would I ping for new sysprop to all
 runtime installer jars?
In-Reply-To: <5564A1B1.2050407@redhat.com>
References: <5564A1B1.2050407@redhat.com>
Message-ID: <E8380E8B-62F8-45BC-9D6B-145075CBE7FC@redhat.com>

On 26 May 2015, at 18:39, Rob Stryker wrote:

> https://issues.jboss.org/browse/JBIDE-19852
>
> When using dl-runtimes to install DV or FSW, it runs the installer 
> jar.
> The installer jar does not respect the installation path the user set 
> in
> the dl-runtimes wizard. It can't, obviously, bc we never transmit it 
> to
> the installer at all.
>
> It'd be great if we could agree on some sysprop we can set when 
> running
> java -jar dv-6.1-installer.jar such that the installer checks it for a
> default installation folder.
>
> Any ideas who I would ping over getting something like that 
> implemented
> on the runtimes side?

I don't think you'll ever be able to find a global agreement on it.

But

A) start by opening feature request against the installer - in this case 
TEIID or Data Virtualisation product.

B) if the installer is a izpack based installer there might be ways to 
do it already: 
http://docs.codehaus.org/display/IZPACK/Unattended+Installations
    Try with java -DINSTALL_PATH=/opt/myplace -jar myinstaller.jar  to 
see if that works ?


/max
http://about.me/maxandersen

From rstryker at redhat.com  Tue May 26 16:46:36 2015
From: rstryker at redhat.com (Rob Stryker)
Date: Tue, 26 May 2015 16:46:36 -0400
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <DBCBE830-F2D2-496B-B840-DE4AA68D50D6@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
	<5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
	<555CCF31.4030600@redhat.com>
	<DBCBE830-F2D2-496B-B840-DE4AA68D50D6@redhat.com>
Message-ID: <5564DBAC.20804@redhat.com>

Questions on Docker / WTP aside, the topic at hand here is how to get it 
into one of our builds until they either accept it or reject it in SR1?

Max has already commented that org.eclipse.wst.server.launchbar seems an 
appropriate name. The next questions are:

1) Where it should live for now?
    a) I put it in jbosstools-server/wtp or some similar existing repo
    b) I put it in a temporary github repository and we simply pull it in?

2) Does it need a feature?

3) Should the feature have an o.j.t. name? Or an o.e.wst.server name?

The questions here are significant, though.  Does it make sense that 
jbosstools-server/wtp have deps on CDT and o.e.remote, perhaps in a 
temporary fashion? Is it reasonable to have org.eclipse plugins and 
features inside repositories that currently hold org.jboss.* bundles? Or 
does it make more sense for them to live somewhere else, such as in 1b), 
a temporary github external repo?

Max:  it seems you don't want to give any guidance until you've seen it 
in action, but you also don't seem to have the time to play with it... 
so I'm left a bit confused as to what *I* can do to get this to move 
forward, aside from nagging you relentlessly until you either set up an 
environment to look at it or give me specific instructions as to what I 
should be doing.


On 05/20/2015 05:49 PM, Max Rydahl Andersen wrote:
> On 20 May 2015, at 20:15, Rob Stryker wrote:
>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>
>> > Have wtp-dev suggested a name for it ?
>>
>> No, so far there are no comments on the bugzilla. I suggest you 
>> comment there if you so choose.
>>
>> >  btw. does the launchbar work with local java apps and units too ?
>>
>> I probably need more of an explanation as to what you're asking, but, 
>> yes, it works for POJP and other launch configs as well. I've 
>> successfully seen MyMainClass in the list and run them.
>
> How does that work ? ..what is selected on the right side for that ?
>
>> But running a simple MyMainClass on some remote server doesn't work, 
>> if thats your question. Is that something you'd like to see?
>
> Well, since we are looking at having Docker integrated being able to 
> run on java app on a docker container would be a usecase to look at
> if this could fit in here.
>
> /max
>
>> On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
>>> Rob,
>>>
>>> Have wtp-dev suggested a name for it ?
>>>
>>> btw. does the launchbar work with local java apps and units too ?
>>>
>>> I just realised we've been focusing purely on remote/server runs - but
>>> local runs should work too.
>>>
>>> /max
>>>
>>>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems 
>>>> reasonable.
>>>>
>>>> You don't technically need to have the same IU names to allow a 
>>>> seamless
>>>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>>>
>>>> We've seen multiple instances where a JBoss project moved to Eclipse,
>>>> and we were able to support the IU rename using a p2.inf instruction.
>>>>
>>>> Here's what we did to rename from com.jboss.jbds to 
>>>> com.jboss.devstudio:
>>>>
>>>> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5 
>>>>
>>>>
>>>> We've done similar with m2e-wtp, too.
>>>>
>>>> But of course it's simpler if we just build the plugin using the 
>>>> future
>>>> o.e.wtp name, and a lower version.
>>>>
>>>>
>>>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>>>> Hi All:
>>>>>
>>>>> wtp-dev mailing list seems to indicate its a bit too late to get 
>>>>> such a
>>>>> contribution into Mars. They did suggest it might be reasonable 
>>>>> for SR1.
>>>>>
>>>>> With that in mind, we should discuss how to go about getting this 
>>>>> into
>>>>> JBT for our Mars release, while still allowing it to be removed /
>>>>> overridden by the eventual contribution to SR1.
>>>>>
>>>>> As of now, it seems the thing most important to discuss is naming 
>>>>> of the
>>>>> plugin, to ensure that the name we use matches with the WTP one. The
>>>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,  
>>>>> it can
>>>>> be added to WTP for Mars SR1 with a higher version, thus replacing 
>>>>> ours.
>>>>>
>>>>> The issue at wtp can be discussed here:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>>
>>>>>
>>>>> @Nick:  Any ideas on whether this plan makes sense?
>>>>
>>>> -- 
>>>> Nick Boldt :: JBoss by Red Hat
>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>> http://nick.divbyzero.com
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>>
>>> /max
>>> http://about.me/maxandersen
>
>
> /max
> http://about.me/maxandersen


From nboldt at redhat.com  Tue May 26 17:43:23 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 26 May 2015 17:43:23 -0400
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <5564DBAC.20804@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
	<5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
	<555CCF31.4030600@redhat.com>
	<DBCBE830-F2D2-496B-B840-DE4AA68D50D6@redhat.com>
	<5564DBAC.20804@redhat.com>
Message-ID: <5564E8FB.50600@redhat.com>

I would vote for the creation of these two artifacts:

* 
jbosstools-server/wtp/features/org.jboss.tools.wst.server.launchbar.feature, 
and

* jbosstools-server/wtp/plugins/org.jboss.tools.wst.server.launchbar

--

If it's accepted to Eclipse WTP, it would be refactored like we've done 
for m2e-wtp, Thym, and other projects.

Then we'd clean out the plugin from jbosstools-server, and our feature 
could simply be a wrapper to install the org.eclipse.wst version, so 
that users would be able to upgrade seamlessly from 
o.j.t.wst.server.launchbar to o.e.wst.server.launchbar.

Or we could use a p2.inf instruction to make their feature be the update 
to ours, replacing ours entirely.

Either way, at that point we'd also add their feature/plugin to our TP 
and therefore be able to include it in ours builds.

But all of those steps are moot until their accept it; in the meantime, 
we should build them as org.jboss.tools artifacts.

On 05/26/2015 04:46 PM, Rob Stryker wrote:
> Questions on Docker / WTP aside, the topic at hand here is how to get it
> into one of our builds until they either accept it or reject it in SR1?
>
> Max has already commented that org.eclipse.wst.server.launchbar seems an
> appropriate name. The next questions are:
>
> 1) Where it should live for now?
>     a) I put it in jbosstools-server/wtp or some similar existing repo
>     b) I put it in a temporary github repository and we simply pull it in?
>
> 2) Does it need a feature?
>
> 3) Should the feature have an o.j.t. name? Or an o.e.wst.server name?
>
> The questions here are significant, though.  Does it make sense that
> jbosstools-server/wtp have deps on CDT and o.e.remote, perhaps in a
> temporary fashion? Is it reasonable to have org.eclipse plugins and
> features inside repositories that currently hold org.jboss.* bundles? Or
> does it make more sense for them to live somewhere else, such as in 1b),
> a temporary github external repo?
>
> Max:  it seems you don't want to give any guidance until you've seen it
> in action, but you also don't seem to have the time to play with it...
> so I'm left a bit confused as to what *I* can do to get this to move
> forward, aside from nagging you relentlessly until you either set up an
> environment to look at it or give me specific instructions as to what I
> should be doing.
>
>
> On 05/20/2015 05:49 PM, Max Rydahl Andersen wrote:
>> On 20 May 2015, at 20:15, Rob Stryker wrote:
>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>
>>> > Have wtp-dev suggested a name for it ?
>>>
>>> No, so far there are no comments on the bugzilla. I suggest you
>>> comment there if you so choose.
>>>
>>> >  btw. does the launchbar work with local java apps and units too ?
>>>
>>> I probably need more of an explanation as to what you're asking, but,
>>> yes, it works for POJP and other launch configs as well. I've
>>> successfully seen MyMainClass in the list and run them.
>>
>> How does that work ? ..what is selected on the right side for that ?
>>
>>> But running a simple MyMainClass on some remote server doesn't work,
>>> if thats your question. Is that something you'd like to see?
>>
>> Well, since we are looking at having Docker integrated being able to
>> run on java app on a docker container would be a usecase to look at
>> if this could fit in here.
>>
>> /max
>>
>>> On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
>>>> Rob,
>>>>
>>>> Have wtp-dev suggested a name for it ?
>>>>
>>>> btw. does the launchbar work with local java apps and units too ?
>>>>
>>>> I just realised we've been focusing purely on remote/server runs - but
>>>> local runs should work too.
>>>>
>>>> /max
>>>>
>>>>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems
>>>>> reasonable.
>>>>>
>>>>> You don't technically need to have the same IU names to allow a
>>>>> seamless
>>>>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>>>>
>>>>> We've seen multiple instances where a JBoss project moved to Eclipse,
>>>>> and we were able to support the IU rename using a p2.inf instruction.
>>>>>
>>>>> Here's what we did to rename from com.jboss.jbds to
>>>>> com.jboss.devstudio:
>>>>>
>>>>> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5
>>>>>
>>>>>
>>>>> We've done similar with m2e-wtp, too.
>>>>>
>>>>> But of course it's simpler if we just build the plugin using the
>>>>> future
>>>>> o.e.wtp name, and a lower version.
>>>>>
>>>>>
>>>>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>>>>> Hi All:
>>>>>>
>>>>>> wtp-dev mailing list seems to indicate its a bit too late to get
>>>>>> such a
>>>>>> contribution into Mars. They did suggest it might be reasonable
>>>>>> for SR1.
>>>>>>
>>>>>> With that in mind, we should discuss how to go about getting this
>>>>>> into
>>>>>> JBT for our Mars release, while still allowing it to be removed /
>>>>>> overridden by the eventual contribution to SR1.
>>>>>>
>>>>>> As of now, it seems the thing most important to discuss is naming
>>>>>> of the
>>>>>> plugin, to ensure that the name we use matches with the WTP one. The
>>>>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,
>>>>>> it can
>>>>>> be added to WTP for Mars SR1 with a higher version, thus replacing
>>>>>> ours.
>>>>>>
>>>>>> The issue at wtp can be discussed here:
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>>>
>>>>>>
>>>>>> @Nick:  Any ideas on whether this plan makes sense?
>>>>>
>>>>> --
>>>>> Nick Boldt :: JBoss by Red Hat
>>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>>> http://nick.divbyzero.com
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>
>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>
>>
>> /max
>> http://about.me/maxandersen
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 27 03:53:14 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 09:53:14 +0200
Subject: [jbosstools-dev] Regarding launchbar contribution
In-Reply-To: <5564E8FB.50600@redhat.com>
References: <555BA3E6.4080008@redhat.com> <555BA71C.1060506@redhat.com>
	<5C4F4FAD-A29B-44B3-8CE5-6CAF19DD95A2@redhat.com>
	<555CCF31.4030600@redhat.com>
	<DBCBE830-F2D2-496B-B840-DE4AA68D50D6@redhat.com>
	<5564DBAC.20804@redhat.com> <5564E8FB.50600@redhat.com>
Message-ID: <331A9453-92AA-47F1-A4A0-A90BF465450B@redhat.com>

On 26 May 2015, at 23:43, Nick Boldt wrote:

> I would vote for the creation of these two artifacts:
>
> * 
> jbosstools-server/wtp/features/org.jboss.tools.wst.server.launchbar.feature, 
> and
>
> * jbosstools-server/wtp/plugins/org.jboss.tools.wst.server.launchbar

Last night I was talking with Rob on Skype (would be so much easier if 
we used irc so I could link to the conversation ;)
and we came to the same conclusion but we called it

org.jboss.tools.wtp.launchbar instead. Simpler and actually using wtp 
not wst in name (I assume that was a typo ;)

And yes, since this feature is completely isolated from the user - there 
are nothing persisted, everything is "throwaways" we should
be able to trivially remove this once/if/when WTP adds support for this.

I also said since launchbar is an optional thing and something you need 
to manually enable we could just as well include
it in our server tools and not make it complicated and put it in 
central.

/max
>
> --
>
> If it's accepted to Eclipse WTP, it would be refactored like we've 
> done for m2e-wtp, Thym, and other projects.
>
> Then we'd clean out the plugin from jbosstools-server, and our feature 
> could simply be a wrapper to install the org.eclipse.wst version, so 
> that users would be able to upgrade seamlessly from 
> o.j.t.wst.server.launchbar to o.e.wst.server.launchbar.
>
> Or we could use a p2.inf instruction to make their feature be the 
> update to ours, replacing ours entirely.
>
> Either way, at that point we'd also add their feature/plugin to our TP 
> and therefore be able to include it in ours builds.
>
> But all of those steps are moot until their accept it; in the 
> meantime, we should build them as org.jboss.tools artifacts.
>
> On 05/26/2015 04:46 PM, Rob Stryker wrote:
>> Questions on Docker / WTP aside, the topic at hand here is how to get 
>> it
>> into one of our builds until they either accept it or reject it in 
>> SR1?
>>
>> Max has already commented that org.eclipse.wst.server.launchbar seems 
>> an
>> appropriate name. The next questions are:
>>
>> 1) Where it should live for now?
>> a) I put it in jbosstools-server/wtp or some similar existing repo
>> b) I put it in a temporary github repository and we simply pull it 
>> in?
>>
>> 2) Does it need a feature?
>>
>> 3) Should the feature have an o.j.t. name? Or an o.e.wst.server name?
>>
>> The questions here are significant, though.  Does it make sense that
>> jbosstools-server/wtp have deps on CDT and o.e.remote, perhaps in a
>> temporary fashion? Is it reasonable to have org.eclipse plugins and
>> features inside repositories that currently hold org.jboss.* bundles? 
>> Or
>> does it make more sense for them to live somewhere else, such as in 
>> 1b),
>> a temporary github external repo?
>>
>> Max:  it seems you don't want to give any guidance until you've seen 
>> it
>> in action, but you also don't seem to have the time to play with 
>> it...
>> so I'm left a bit confused as to what *I* can do to get this to move
>> forward, aside from nagging you relentlessly until you either set up 
>> an
>> environment to look at it or give me specific instructions as to what 
>> I
>> should be doing.
>>
>>
>> On 05/20/2015 05:49 PM, Max Rydahl Andersen wrote:
>>> On 20 May 2015, at 20:15, Rob Stryker wrote:
>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>
>>>> > Have wtp-dev suggested a name for it ?
>>>>
>>>> No, so far there are no comments on the bugzilla. I suggest you
>>>> comment there if you so choose.
>>>>
>>>> >  btw. does the launchbar work with local java apps and units too 
>>>> ?
>>>>
>>>> I probably need more of an explanation as to what you're asking, 
>>>> but,
>>>> yes, it works for POJP and other launch configs as well. I've
>>>> successfully seen MyMainClass in the list and run them.
>>>
>>> How does that work ? ..what is selected on the right side for that ?
>>>
>>>> But running a simple MyMainClass on some remote server doesn't 
>>>> work,
>>>> if thats your question. Is that something you'd like to see?
>>>
>>> Well, since we are looking at having Docker integrated being able to
>>> run on java app on a docker container would be a usecase to look at
>>> if this could fit in here.
>>>
>>> /max
>>>
>>>> On 05/20/2015 03:37 AM, Max Rydahl Andersen wrote:
>>>>> Rob,
>>>>>
>>>>> Have wtp-dev suggested a name for it ?
>>>>>
>>>>> btw. does the launchbar work with local java apps and units too ?
>>>>>
>>>>> I just realised we've been focusing purely on remote/server runs - 
>>>>> but
>>>>> local runs should work too.
>>>>>
>>>>> /max
>>>>>
>>>>>> Since JBT 4.3.0.Final is slated for after Mars SR1, this seems
>>>>>> reasonable.
>>>>>>
>>>>>> You don't technically need to have the same IU names to allow a
>>>>>> seamless
>>>>>> upgrade from o.j.t.whatever to o.eclipse.wtp.whatever.
>>>>>>
>>>>>> We've seen multiple instances where a JBoss project moved to 
>>>>>> Eclipse,
>>>>>> and we were able to support the IU rename using a p2.inf 
>>>>>> instruction.
>>>>>>
>>>>>> Here's what we did to rename from com.jboss.jbds to
>>>>>> com.jboss.devstudio:
>>>>>>
>>>>>> https://github.com/jbdevstudio/jbdevstudio-product/blob/jbosstools-4.2.x/features/com.jboss.devstudio.core.feature/p2.inf#L1-L5
>>>>>>
>>>>>>
>>>>>> We've done similar with m2e-wtp, too.
>>>>>>
>>>>>> But of course it's simpler if we just build the plugin using the
>>>>>> future
>>>>>> o.e.wtp name, and a lower version.
>>>>>>
>>>>>>
>>>>>> On 05/19/2015 04:58 PM, Rob Stryker wrote:
>>>>>>> Hi All:
>>>>>>>
>>>>>>> wtp-dev mailing list seems to indicate its a bit too late to get
>>>>>>> such a
>>>>>>> contribution into Mars. They did suggest it might be reasonable
>>>>>>> for SR1.
>>>>>>>
>>>>>>> With that in mind, we should discuss how to go about getting 
>>>>>>> this
>>>>>>> into
>>>>>>> JBT for our Mars release, while still allowing it to be removed 
>>>>>>> /
>>>>>>> overridden by the eventual contribution to SR1.
>>>>>>>
>>>>>>> As of now, it seems the thing most important to discuss is 
>>>>>>> naming
>>>>>>> of the
>>>>>>> plugin, to ensure that the name we use matches with the WTP one. 
>>>>>>> The
>>>>>>> idea seems to be that if we release this plugin as 0.9.0 in JBT,
>>>>>>> it can
>>>>>>> be added to WTP for Mars SR1 with a higher version, thus 
>>>>>>> replacing
>>>>>>> ours.
>>>>>>>
>>>>>>> The issue at wtp can be discussed here:
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467604
>>>>>>>
>>>>>>>
>>>>>>> @Nick:  Any ideas on whether this plan makes sense?
>>>>>>
>>>>>> --
>>>>>> Nick Boldt :: JBoss by Red Hat
>>>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>>>> http://nick.divbyzero.com
>>>>>> _______________________________________________
>>>>>> jbosstools-dev mailing list
>>>>>> jbosstools-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>
>>>>>
>>>>> /max
>>>>> http://about.me/maxandersen
>>>
>>>
>>> /max
>>> http://about.me/maxandersen
>>
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com


/max
http://about.me/maxandersen


From mmalina at redhat.com  Wed May 27 04:51:17 2015
From: mmalina at redhat.com (Martin Malina)
Date: Wed, 27 May 2015 10:51:17 +0200
Subject: [jbosstools-dev] Who would I ping for new sysprop to all
	runtime installer jars?
In-Reply-To: <E8380E8B-62F8-45BC-9D6B-145075CBE7FC@redhat.com>
References: <5564A1B1.2050407@redhat.com>
	<E8380E8B-62F8-45BC-9D6B-145075CBE7FC@redhat.com>
Message-ID: <B98C6706-A665-4AEE-9619-910F008C821C@redhat.com>


> On 26. 5. 2015, at 20:31, Max Rydahl Andersen <manderse at redhat.com> wrote:
> 
> On 26 May 2015, at 18:39, Rob Stryker wrote:
> 
>> https://issues.jboss.org/browse/JBIDE-19852
>> 
>> When using dl-runtimes to install DV or FSW, it runs the installer 
>> jar.
>> The installer jar does not respect the installation path the user set 
>> in
>> the dl-runtimes wizard. It can't, obviously, bc we never transmit it 
>> to
>> the installer at all.
>> 
>> It'd be great if we could agree on some sysprop we can set when 
>> running
>> java -jar dv-6.1-installer.jar such that the installer checks it for a
>> default installation folder.
>> 
>> Any ideas who I would ping over getting something like that 
>> implemented
>> on the runtimes side?
> 
> I don't think you'll ever be able to find a global agreement on it.
> 
> But
> 
> A) start by opening feature request against the installer - in this case 
> TEIID or Data Virtualisation product.
> 
> B) if the installer is a izpack based installer there might be ways to 
> do it already: 
> http://docs.codehaus.org/display/IZPACK/Unattended+Installations
>    Try with java -DINSTALL_PATH=/opt/myplace -jar myinstaller.jar  to 
> see if that works ?
> 

Unfortunately it doesn't work.

For JBDS installer jar, running
java -jar installer.jar -options-template myinstaller.properties
generates the property file, but it's empty.

For DV, running the same command, the resulting property file includes "INSTALL_PATH=" which should indicate that you can set this property as Max suggested.

But running the installer with
java -DINSTALL_PATH=/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 -jar jboss-dv-installer-6.1.0.redhat-3.jar
it will still offer this as the default path:
/Users/rasp/DV-6.1.0/jboss-eap-6.3

So no luck here.

-Martin

> 
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev



From manderse at redhat.com  Wed May 27 07:11:08 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 13:11:08 +0200
Subject: [jbosstools-dev] Who would I ping for new sysprop to all
 runtime installer jars?
In-Reply-To: <B98C6706-A665-4AEE-9619-910F008C821C@redhat.com>
References: <5564A1B1.2050407@redhat.com>
	<E8380E8B-62F8-45BC-9D6B-145075CBE7FC@redhat.com>
	<B98C6706-A665-4AEE-9619-910F008C821C@redhat.com>
Message-ID: <5F0A5801-386E-48C6-8A3E-AC18D245E229@redhat.com>

On 27 May 2015, at 10:51, Martin Malina wrote:

>> On 26. 5. 2015, at 20:31, Max Rydahl Andersen <manderse at redhat.com> 
>> wrote:
>>
>> On 26 May 2015, at 18:39, Rob Stryker wrote:
>>
>>> https://issues.jboss.org/browse/JBIDE-19852
>>>
>>> When using dl-runtimes to install DV or FSW, it runs the installer
>>> jar.
>>> The installer jar does not respect the installation path the user 
>>> set
>>> in
>>> the dl-runtimes wizard. It can't, obviously, bc we never transmit it
>>> to
>>> the installer at all.
>>>
>>> It'd be great if we could agree on some sysprop we can set when
>>> running
>>> java -jar dv-6.1-installer.jar such that the installer checks it for 
>>> a
>>> default installation folder.
>>>
>>> Any ideas who I would ping over getting something like that
>>> implemented
>>> on the runtimes side?
>>
>> I don't think you'll ever be able to find a global agreement on it.
>>
>> But
>>
>> A) start by opening feature request against the installer - in this 
>> case
>> TEIID or Data Virtualisation product.
>>
>> B) if the installer is a izpack based installer there might be ways 
>> to
>> do it already:
>> http://docs.codehaus.org/display/IZPACK/Unattended+Installations
>> Try with java -DINSTALL_PATH=/opt/myplace -jar myinstaller.jar  to
>> see if that works ?
>>
>
> Unfortunately it doesn't work.
>
> For JBDS installer jar, running
> java -jar installer.jar -options-template myinstaller.properties
> generates the property file, but it's empty.
>
> For DV, running the same command, the resulting property file includes 
> "INSTALL_PATH=" which should indicate that you can set this property 
> as Max suggested.
>
> But running the installer with
> java -DINSTALL_PATH=/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 -jar 
> jboss-dv-installer-6.1.0.redhat-3.jar
> it will still offer this as the default path:
> /Users/rasp/DV-6.1.0/jboss-eap-6.3
>
> So no luck here.

sounds like a bug we should fix on both sides ;)

care to open them ?

/max
http://about.me/maxandersen

From mmalina at redhat.com  Wed May 27 08:26:04 2015
From: mmalina at redhat.com (Martin Malina)
Date: Wed, 27 May 2015 14:26:04 +0200
Subject: [jbosstools-dev] Who would I ping for new sysprop to all
	runtime installer jars?
In-Reply-To: <5F0A5801-386E-48C6-8A3E-AC18D245E229@redhat.com>
References: <5564A1B1.2050407@redhat.com>
	<E8380E8B-62F8-45BC-9D6B-145075CBE7FC@redhat.com>
	<B98C6706-A665-4AEE-9619-910F008C821C@redhat.com>
	<5F0A5801-386E-48C6-8A3E-AC18D245E229@redhat.com>
Message-ID: <F5039A29-FFB3-454A-9E40-57A0190A3468@redhat.com>


> On 27. 5. 2015, at 13:11, Max Rydahl Andersen <manderse at redhat.com> wrote:
> 
> On 27 May 2015, at 10:51, Martin Malina wrote:
> 
>>> On 26. 5. 2015, at 20:31, Max Rydahl Andersen <manderse at redhat.com> wrote:
>>> 
>>> On 26 May 2015, at 18:39, Rob Stryker wrote:
>>> 
>>>> https://issues.jboss.org/browse/JBIDE-19852
>>>> 
>>>> When using dl-runtimes to install DV or FSW, it runs the installer
>>>> jar.
>>>> The installer jar does not respect the installation path the user set
>>>> in
>>>> the dl-runtimes wizard. It can't, obviously, bc we never transmit it
>>>> to
>>>> the installer at all.
>>>> 
>>>> It'd be great if we could agree on some sysprop we can set when
>>>> running
>>>> java -jar dv-6.1-installer.jar such that the installer checks it for a
>>>> default installation folder.
>>>> 
>>>> Any ideas who I would ping over getting something like that
>>>> implemented
>>>> on the runtimes side?
>>> 
>>> I don't think you'll ever be able to find a global agreement on it.
>>> 
>>> But
>>> 
>>> A) start by opening feature request against the installer - in this case
>>> TEIID or Data Virtualisation product.
>>> 
>>> B) if the installer is a izpack based installer there might be ways to
>>> do it already:
>>> http://docs.codehaus.org/display/IZPACK/Unattended+Installations
>>> Try with java -DINSTALL_PATH=/opt/myplace -jar myinstaller.jar  to
>>> see if that works ?
>>> 
>> 
>> Unfortunately it doesn't work.
>> 
>> For JBDS installer jar, running
>> java -jar installer.jar -options-template myinstaller.properties
>> generates the property file, but it's empty.
>> 
>> For DV, running the same command, the resulting property file includes "INSTALL_PATH=" which should indicate that you can set this property as Max suggested.
>> 
>> But running the installer with
>> java -DINSTALL_PATH=/Users/rasp/jbossqa/runtimes/jboss-eap-6.3.0 -jar jboss-dv-installer-6.1.0.redhat-3.jar
>> it will still offer this as the default path:
>> /Users/rasp/DV-6.1.0/jboss-eap-6.3
>> 
>> So no luck here.
> 
> sounds like a bug we should fix on both sides ;)
> 
> care to open them ?

OK, I created these:
https://issues.jboss.org/browse/JBDS-3446 for JBDS (although we're not gonna install JBDS from within JBDS, it may still be a good thing to have there)
https://bugzilla.redhat.com/show_bug.cgi?id=1225450 for JBoss DV
https://bugzilla.redhat.com/show_bug.cgi?id=1225457 for JBoss FSW

-Martin

> /max
> http://about.me/maxandersen



From nboldt at redhat.com  Wed May 27 13:26:01 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 27 May 2015 13:26:01 -0400
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui and
 o.e.remote.core/ui to JBT/JBDS target platforms 4.50.0.Beta1-SNAPSHOT
In-Reply-To: <55103347.1060505@redhat.com>
References: <55103347.1060505@redhat.com>
Message-ID: <5565FE29.3090806@redhat.com>

We need to add 4 plugins to the target platform.

https://issues.jboss.org/browse/JBIDE-19879
https://github.com/jbosstools/jbosstools-target-platforms/pull/145

This is in support of the new Launchbar stuff planned for Beta1. If 
there are no violent objections to this change, it'll be pushed in the 
next 24hrs or so.

--

To those that read all the way to the bottom of my emails, please note 
too that there will be a much larger change coming in the next couple 
days: updating the target platform to include Mars RC2 bits (currently 
M7 bits are in there).

Reminder of upcoming dates:

2015/05/28: Mars RC2 EPP bundles available

2015/06/03: 4.50.0.Beta1 target platform release day

2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day

2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day

2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the QE 
staging done on Friday instead of the weekend, if possible)

2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins



-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com



From nboldt at redhat.com  Wed May 27 13:27:11 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 27 May 2015 13:27:11 -0400
Subject: [jbosstools-dev] REMINDER: JBT 4.3 / JBDS 9.0 Beta1 Code Freeze is
	next week!
Message-ID: <5565FE6F.4000802@redhat.com>

Reminder of upcoming dates:

2015/05/28: Mars RC2 EPP bundles available

2015/06/03: 4.50.0.Beta1 target platform release day

2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day

2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day

2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day

PLEASE NOTE: I'd like to get the QE staging done on *Friday* instead of 
the weekend, if possible.

2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 27 14:04:04 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 14:04:04 -0400 (EDT)
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui
	and o.e.remote.core/ui to JBT/JBDS target platforms
	4.50.0.Beta1-SNAPSHOT
In-Reply-To: <5565FE29.3090806@redhat.com>
References: <55103347.1060505@redhat.com> <5565FE29.3090806@redhat.com>
Message-ID: <BE2FEDAD-A50F-4DB3-90AD-B6CACA629448@redhat.com>

How can we include the launchbar stuff when this is not going to be available before eclipse Mars SR1? Or has that changed ?

/max
http://about.me/maxandersen


> On 27 May 2015, at 19:26, Nick Boldt <nboldt at redhat.com> wrote:
> 
> We need to add 4 plugins to the target platform.
> 
> https://issues.jboss.org/browse/JBIDE-19879
> https://github.com/jbosstools/jbosstools-target-platforms/pull/145
> 
> This is in support of the new Launchbar stuff planned for Beta1. If 
> there are no violent objections to this change, it'll be pushed in the 
> next 24hrs or so.
> 
> --
> 
> To those that read all the way to the bottom of my emails, please note 
> too that there will be a much larger change coming in the next couple 
> days: updating the target platform to include Mars RC2 bits (currently 
> M7 bits are in there).
> 
> Reminder of upcoming dates:
> 
> 2015/05/28: Mars RC2 EPP bundles available
> 
> 2015/06/03: 4.50.0.Beta1 target platform release day
> 
> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day
> 
> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day
> 
> 2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the QE 
> staging done on Friday instead of the weekend, if possible)
> 
> 2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins
> 
> 
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> 
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From manderse at redhat.com  Wed May 27 14:05:10 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 14:05:10 -0400 (EDT)
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui
	and o.e.remote.core/ui to JBT/JBDS target platforms
	4.50.0.Beta1-SNAPSHOT
In-Reply-To: <5565FE29.3090806@redhat.com>
References: <55103347.1060505@redhat.com> <5565FE29.3090806@redhat.com>
Message-ID: <74C0BE2D-0D89-420E-840C-C729ABE4B560@redhat.com>

Hmm - I'm on phone but I was pretty sure rob or I commented on jira launchbar required SR1 ?!?

/max
http://about.me/maxandersen


> On 27 May 2015, at 19:26, Nick Boldt <nboldt at redhat.com> wrote:
> 
> We need to add 4 plugins to the target platform.
> 
> https://issues.jboss.org/browse/JBIDE-19879
> https://github.com/jbosstools/jbosstools-target-platforms/pull/145
> 
> This is in support of the new Launchbar stuff planned for Beta1. If 
> there are no violent objections to this change, it'll be pushed in the 
> next 24hrs or so.
> 
> --
> 
> To those that read all the way to the bottom of my emails, please note 
> too that there will be a much larger change coming in the next couple 
> days: updating the target platform to include Mars RC2 bits (currently 
> M7 bits are in there).
> 
> Reminder of upcoming dates:
> 
> 2015/05/28: Mars RC2 EPP bundles available
> 
> 2015/06/03: 4.50.0.Beta1 target platform release day
> 
> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day
> 
> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day
> 
> 2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the QE 
> staging done on Friday instead of the weekend, if possible)
> 
> 2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins
> 
> 
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> 
> 
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


From nboldt at redhat.com  Wed May 27 14:33:44 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 27 May 2015 14:33:44 -0400
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui
 and o.e.remote.core/ui to JBT/JBDS target platforms 4.50.0.Beta1-SNAPSHOT
In-Reply-To: <74C0BE2D-0D89-420E-840C-C729ABE4B560@redhat.com>
References: <55103347.1060505@redhat.com> <5565FE29.3090806@redhat.com>
	<74C0BE2D-0D89-420E-840C-C729ABE4B560@redhat.com>
Message-ID: <55660E08.5030309@redhat.com>

Rob said:

"It's in SR1. The plugins are also in M7... the problem is the API 
changed a lot over the past few weeks, so the code I have does not work 
with what's in M7." -- 
https://issues.jboss.org/browse/JBIDE-19711?focusedCommentId=13071508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071508

Below you'll note I said we're moving up to SR2 later this week. That PR 
will also include the addition of these 4 plugins.

On 05/27/2015 02:05 PM, Max Rydahl Andersen wrote:
> Hmm - I'm on phone but I was pretty sure rob or I commented on jira launchbar required SR1 ?!?
>
> /max
> http://about.me/maxandersen
>
>
>> On 27 May 2015, at 19:26, Nick Boldt <nboldt at redhat.com> wrote:
>>
>> We need to add 4 plugins to the target platform.
>>
>> https://issues.jboss.org/browse/JBIDE-19879
>> https://github.com/jbosstools/jbosstools-target-platforms/pull/145
>>
>> This is in support of the new Launchbar stuff planned for Beta1. If
>> there are no violent objections to this change, it'll be pushed in the
>> next 24hrs or so.
>>
>> --
>>
>> To those that read all the way to the bottom of my emails, please note
>> too that there will be a much larger change coming in the next couple
>> days: updating the target platform to include Mars RC2 bits (currently
>> M7 bits are in there).
>>
>> Reminder of upcoming dates:
>>
>> 2015/05/28: Mars RC2 EPP bundles available
>>
>> 2015/06/03: 4.50.0.Beta1 target platform release day
>>
>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day
>>
>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day
>>
>> 2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the QE
>> staging done on Friday instead of the weekend, if possible)
>>
>> 2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins
>>
>>
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 27 15:12:48 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 21:12:48 +0200
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui
 and o.e.remote.core/ui to JBT/JBDS target platforms 4.50.0.Beta1-SNAPSHOT
In-Reply-To: <55660E08.5030309@redhat.com>
References: <55103347.1060505@redhat.com> <5565FE29.3090806@redhat.com>
	<74C0BE2D-0D89-420E-840C-C729ABE4B560@redhat.com>
	<55660E08.5030309@redhat.com>
Message-ID: <F85D2172-7044-4487-AA9B-60B1B344BE2D@redhat.com>

On 27 May 2015, at 20:33, Nick Boldt wrote:

> Rob said:
>
> "It's in SR1. The plugins are also in M7... the problem is the API 
> changed a lot over the past few weeks, so the code I have does not 
> work with what's in M7." -- 
> https://issues.jboss.org/browse/JBIDE-19711?focusedCommentId=13071508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071508
>
> Below you'll note I said we're moving up to SR2 later this week. That 
> PR will also include the addition of these 4 plugins.

eh what ?

SR1 is being released in September. SR2 is in March next year.

Did you both actually mean RC1 and RC2 ?

/max

> On 05/27/2015 02:05 PM, Max Rydahl Andersen wrote:
>> Hmm - I'm on phone but I was pretty sure rob or I commented on jira 
>> launchbar required SR1 ?!?
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>> On 27 May 2015, at 19:26, Nick Boldt <nboldt at redhat.com> wrote:
>>>
>>> We need to add 4 plugins to the target platform.
>>>
>>> https://issues.jboss.org/browse/JBIDE-19879
>>> https://github.com/jbosstools/jbosstools-target-platforms/pull/145
>>>
>>> This is in support of the new Launchbar stuff planned for Beta1. If
>>> there are no violent objections to this change, it'll be pushed in 
>>> the
>>> next 24hrs or so.
>>>
>>> --
>>>
>>> To those that read all the way to the bottom of my emails, please 
>>> note
>>> too that there will be a much larger change coming in the next 
>>> couple
>>> days: updating the target platform to include Mars RC2 bits 
>>> (currently
>>> M7 bits are in there).
>>>
>>> Reminder of upcoming dates:
>>>
>>> 2015/05/28: Mars RC2 EPP bundles available
>>>
>>> 2015/06/03: 4.50.0.Beta1 target platform release day
>>>
>>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day
>>>
>>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day
>>>
>>> 2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the 
>>> QE
>>> staging done on Friday instead of the weekend, if possible)
>>>
>>> 2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins
>>>
>>>
>>>
>>> --
>>> Nick Boldt :: JBoss by Red Hat
>>> Productization Lead :: JBoss Tools & Dev Studio
>>> http://nick.divbyzero.com
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com


/max
http://about.me/maxandersen


From nboldt at redhat.com  Wed May 27 16:14:04 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 27 May 2015 16:14:04 -0400
Subject: [jbosstools-dev] Proposal to add org.eclipse.launchbar.core/ui
 and o.e.remote.core/ui to JBT/JBDS target platforms 4.50.0.Beta1-SNAPSHOT
In-Reply-To: <F85D2172-7044-4487-AA9B-60B1B344BE2D@redhat.com>
References: <55103347.1060505@redhat.com> <5565FE29.3090806@redhat.com>
	<74C0BE2D-0D89-420E-840C-C729ABE4B560@redhat.com>
	<55660E08.5030309@redhat.com>
	<F85D2172-7044-4487-AA9B-60B1B344BE2D@redhat.com>
Message-ID: <5566258C.6030903@redhat.com>

Yes, RC1.

On 05/27/2015 03:12 PM, Max Rydahl Andersen wrote:
> On 27 May 2015, at 20:33, Nick Boldt wrote:
>
>> Rob said:
>>
>> "It's in SR1. The plugins are also in M7... the problem is the API
>> changed a lot over the past few weeks, so the code I have does not
>> work with what's in M7." --
>> https://issues.jboss.org/browse/JBIDE-19711?focusedCommentId=13071508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071508
>>
>>
>> Below you'll note I said we're moving up to SR2 later this week. That
>> PR will also include the addition of these 4 plugins.
>
> eh what ?
>
> SR1 is being released in September. SR2 is in March next year.
>
> Did you both actually mean RC1 and RC2 ?
>
> /max
>
>> On 05/27/2015 02:05 PM, Max Rydahl Andersen wrote:
>>> Hmm - I'm on phone but I was pretty sure rob or I commented on jira
>>> launchbar required SR1 ?!?
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>>
>>>> On 27 May 2015, at 19:26, Nick Boldt <nboldt at redhat.com> wrote:
>>>>
>>>> We need to add 4 plugins to the target platform.
>>>>
>>>> https://issues.jboss.org/browse/JBIDE-19879
>>>> https://github.com/jbosstools/jbosstools-target-platforms/pull/145
>>>>
>>>> This is in support of the new Launchbar stuff planned for Beta1. If
>>>> there are no violent objections to this change, it'll be pushed in the
>>>> next 24hrs or so.
>>>>
>>>> --
>>>>
>>>> To those that read all the way to the bottom of my emails, please note
>>>> too that there will be a much larger change coming in the next couple
>>>> days: updating the target platform to include Mars RC2 bits (currently
>>>> M7 bits are in there).
>>>>
>>>> Reminder of upcoming dates:
>>>>
>>>> 2015/05/28: Mars RC2 EPP bundles available
>>>>
>>>> 2015/06/03: 4.50.0.Beta1 target platform release day
>>>>
>>>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 code freeze day
>>>>
>>>> 2015/06/04: 4.3.0.Beta1 / 9.0.0.Beta1 N&N complete day
>>>>
>>>> 2015/06/05: 4.3.0.Beta1 / 9.0.0.Beta1 build day (I'd like to get the QE
>>>> staging done on Friday instead of the weekend, if possible)
>>>>
>>>> 2015/06/08: 4.3.0.Beta1 / 9.0.0.Beta1 QE / testing begins
>>>>
>>>>
>>>>
>>>> --
>>>> Nick Boldt :: JBoss by Red Hat
>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>> http://nick.divbyzero.com
>>>>
>>>>
>>>> _______________________________________________
>>>> jbosstools-dev mailing list
>>>> jbosstools-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>
>
> /max
> http://about.me/maxandersen

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From manderse at redhat.com  Wed May 27 18:02:35 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 28 May 2015 00:02:35 +0200
Subject: [jbosstools-dev] Jira Pullrequest workflow improvements
Message-ID: <9263AF53-C959-4C30-9B1A-5A47CFEBFD5E@redhat.com>

Hi,

Just to let all know that JBIDE and JBDS (and all other projects using 
git PR workflow
or CDW v1) on jira have had a nice change[1] in behaviour yesterday.

For a while now you had to manually set the pull request status by 
attaching git pull requests into the field.

![](cid:80B19500-4B38-4071-B048-984117FA6BAA at redhat.com 
"_JBIDE-19820__Batch_feature_makes_wildfly_import_way_slower_-_JBoss_Issue_Tracker.png")

Now as can see on JBIDE-19857[2] this status change happens 
automatically when jira detects a PR with proper jira reference and it 
shows up in the Development section of jira.

![](cid:60745CA1-0402-4C69-83A8-203A99573A5B at redhat.com 
"_JBIDE-19857__Create_New_and_Noteworthy_for_4_3_0_Beta1_-_JBoss_Issue_Tracker.png")

The upside here is you don't have to set that status and we can now 
query on "pull request sent",
downside is that it does take jira 30 minutes or so to notice it.

Thus if it is urgent you get the PR noticed then the old way is still to 
be preferred.

[1] https://issues.jboss.org/browse/ORG-2458
[2] 
https://issues.jboss.org/browse/JBIDE-19857?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel

/max
http://about.me/maxandersen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _JBIDE-19820__Batch_feature_makes_wildfly_import_way_slower_-_JBoss_Issue_Tracker.png
Type: image/png
Size: 101771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150528/a9351210/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _JBIDE-19857__Create_New_and_Noteworthy_for_4_3_0_Beta1_-_JBoss_Issue_Tracker.png
Type: image/png
Size: 20113 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150528/a9351210/attachment-0003.png 

From pleacu at redhat.com  Wed May 27 22:37:42 2015
From: pleacu at redhat.com (Paul Leacu)
Date: Wed, 27 May 2015 22:37:42 -0400 (EDT)
Subject: [jbosstools-dev] Proposed change for JBTIS target platform -
	4.3.0.Alpha2b
In-Reply-To: <1011736713.1365778.1432062642069.JavaMail.zimbra@redhat.com>
Message-ID: <1504785918.5323988.1432780662273.JavaMail.zimbra@redhat.com>


  Greetings -
      A proposal to change the Mars JBTIS 4.3.0 target platform is described here:

   https://issues.jboss.org/browse/JBTIS-439
   https://issues.jboss.org/browse/JBTIS-442

   PR:  https://github.com/jbosstools/jbosstools-integration-stack/pull/366

   Synopsis:

   1. Fuse Data Transformation tooling relies on XMLBeans to generate an XML schema from an XML instance document in order to support the generation of model classes for XML source/target.
   2. Sync with the 4.50.0.Alpha2 JBoss Tools core TP.

   When the 4.50.0.Beta1 is released then a beta JBTIS TP will be released to resync with Eclipse Mars.

   Please respond by 12:00 EDT on Thursday, May 28 to the specified Jira if there are any issues.

   Thanks,
         --paull

From mistria at redhat.com  Thu May 28 04:40:44 2015
From: mistria at redhat.com (Mickael Istria)
Date: Thu, 28 May 2015 10:40:44 +0200
Subject: [jbosstools-dev] Proposed changes to target platform
 4.50.0.Beta1-SNAPSHOT: Mars RC2 & LaunchBar
Message-ID: <5566D48C.3000609@redhat.com>

Here is a proposal for a change to the JBoss Tools and Red Hat JBoss 
Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
https://github.com/jbosstools/jbosstools-target-platforms/pull/146

It consists in the following change(s):
* JBIDE-19776: Mars RC2
* JBIDE-19879: LaunchBar and dependencies

p2diff reports: 
https://issues.jboss.org/browse/JBIDE-19776?focusedCommentId=13071774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071774 
(nothing alarming)

Please review the above PR(s), as it will be applied very soon. You can 
use the following to build & test the target-platform locally against 
your component(s).

Build target-platform:
$ cd /path/to/jbosstools-target-platforms/jbosstools/multiple
$ git fetch origin pull/146/head && git checkout FETCH_HEAD
$ mvn clean install

Then, to test the new "multiple" target platform against your 
component's build:
$ cd /path/to/your/jbosstools-component
$ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT 
-Dtpc.targetKind=multiple

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150528/e2c754e5/attachment.html 

From nboldt at redhat.com  Thu May 28 11:14:00 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 28 May 2015 11:14:00 -0400
Subject: [jbosstools-dev] Proposed changes to target platform
 4.50.0.Beta1-SNAPSHOT: Mars RC2 & LaunchBar
In-Reply-To: <5566D48C.3000609@redhat.com>
References: <5566D48C.3000609@redhat.com>
Message-ID: <556730B8.5080606@redhat.com>

Found a newer version of e4.ui today, so I've updated the PR. The p2diff 
as produced in JBIDE-19776 remains the same, as this change [1] only 
affects the version of 2 plugins.

[1] 
https://github.com/nickboldt/jbosstools-target-platforms/commit/dab7c31ec5775709484e58a28f3b45777ac3e1b5

I hope to be able to *merge this tomorrow* into the 4.50.x branch so we 
can get it built before the weekend, well in advance of next week's code 
freeze.

If you have any concerns, please raise them ASAP.

On 05/28/2015 04:40 AM, Mickael Istria wrote:
> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
> Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
> https://github.com/jbosstools/jbosstools-target-platforms/pull/146
>
> It consists in the following change(s):
> * JBIDE-19776: Mars RC2
> * JBIDE-19879: LaunchBar dependencies (only new 4 plugins from Mars repo)
>
> p2diff reports:
> https://issues.jboss.org/browse/JBIDE-19776?focusedCommentId=13071774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071774
> (nothing alarming)
>
> Please review the above PR(s), as it will be applied very soon. You can
> use the following to build & test the target-platform locally against
> your component(s).
>
> Build target-platform:
> $ cd /path/to/jbosstools-target-platforms/jbosstools/multiple
> $ git fetch origin pull/146/head && git checkout FETCH_HEAD
> $ mvn clean install
>
> Then, to test the new "multiple" target platform against your
> component's build:
> $ cd /path/to/your/jbosstools-component
> $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT
> -Dtpc.targetKind=multiple
>
> --
> 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>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nickboldt at gmail.com  Thu May 28 13:49:05 2015
From: nickboldt at gmail.com (Nick Boldt)
Date: Thu, 28 May 2015 13:49:05 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: test-drive Tycho 0.23.0
In-Reply-To: <F8F18CC0DECD384BAC6FBAD1A7C49A48996B6E72@DEWDFEMB18B.global.corp.sap>
References: <F8F18CC0DECD384BAC6FBAD1A7C49A48996B6E72@DEWDFEMB18B.global.corp.sap>
Message-ID: <55675511.50408@gmail.com>

Soon, Tycho 0.23.0 will be available.

If possible, I'd like to build JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1 using 
Tycho 0.23.0.

If you add the code below to your settings.xml, then build with 
-DtychoVersion=0.23.0, you'll be able to see if anything breaks w/ Tycho 
0.23.0.

If it does, please open a JIRA.

Thanks!


-------- Forwarded Message --------
Subject: [tycho-user] Tycho 0.23.0 staged
Date: Thu, 28 May 2015 16:07:55 +0000
From: Sievers, Jan <jan.sievers at sap.com>
Reply-To: Tycho user list <tycho-user at eclipse.org>
To: Tycho user list (tycho-user at eclipse.org) <tycho-user at eclipse.org>
CC: Tycho developers list (tycho-dev at eclipse.org) <tycho-dev at eclipse.org>

Tycho milestone release 0.23.0 has been staged.

For details of new features and bugfixes, see release notes [1].
Please help by testing the staged milestone build. To use it, change 
your tycho version to 0.23.0 and add snippet [2] to your pom.

NOTE: if you build products for MacOSX against p2 repositories older 
than eclipse Mars, there is a known bug [3]

We plan to promote this release in one week unless major regressions are 
found.

Regards,
Tycho team

[1] http://wiki.eclipse.org/Tycho/Release_Notes/0.23
[2]
<pluginRepositories>
  <pluginRepository>
   <id>tycho-staged</id>
   
<url>https://oss.sonatype.org/content/repositories/orgeclipsetycho-1021/</url>
  </pluginRepository>
</pluginRepositories>

[3] https://wiki.eclipse.org/Tycho/Release_Notes/0.23#p2

_______________________________________________
tycho-user mailing list
tycho-user at eclipse.org
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user



From nboldt at redhat.com  Thu May 28 15:43:55 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 28 May 2015 15:43:55 -0400
Subject: [jbosstools-dev] Proposed changes to target platform
 4.50.0.Beta1-SNAPSHOT: Mars RC2 & LaunchBar
In-Reply-To: <556730B8.5080606@redhat.com>
References: <5566D48C.3000609@redhat.com> <556730B8.5080606@redhat.com>
Message-ID: <55676FFB.2080609@redhat.com>

Xavier has reported we are missing some IUs from Jetty for LiveReload.

Here's the PR:

https://github.com/jbosstools/jbosstools-target-platforms/pull/147


On 05/28/2015 11:14 AM, Nick Boldt wrote:
> Found a newer version of e4.ui today, so I've updated the PR. The p2diff
> as produced in JBIDE-19776 remains the same, as this change [1] only
> affects the version of 2 plugins.
>
> [1]
> https://github.com/nickboldt/jbosstools-target-platforms/commit/dab7c31ec5775709484e58a28f3b45777ac3e1b5
>
>
> I hope to be able to *merge this tomorrow* into the 4.50.x branch so we
> can get it built before the weekend, well in advance of next week's code
> freeze.
>
> If you have any concerns, please raise them ASAP.
>
> On 05/28/2015 04:40 AM, Mickael Istria wrote:
>> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
>> Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
>> https://github.com/jbosstools/jbosstools-target-platforms/pull/146
>>
>> It consists in the following change(s):
>> * JBIDE-19776: Mars RC2
>> * JBIDE-19879: LaunchBar dependencies (only new 4 plugins from Mars repo)
>>
>> p2diff reports:
>> https://issues.jboss.org/browse/JBIDE-19776?focusedCommentId=13071774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071774
>>
>> (nothing alarming)
>>
>> Please review the above PR(s), as it will be applied very soon. You can
>> use the following to build & test the target-platform locally against
>> your component(s).
>>
>> Build target-platform:
>> $ cd /path/to/jbosstools-target-platforms/jbosstools/multiple
>> $ git fetch origin pull/146/head && git checkout FETCH_HEAD
>> $ mvn clean install
>>
>> Then, to test the new "multiple" target platform against your
>> component's build:
>> $ cd /path/to/your/jbosstools-component
>> $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT
>> -Dtpc.targetKind=multiple
>>
>> --
>> 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>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From xcoulon at redhat.com  Thu May 28 16:57:50 2015
From: xcoulon at redhat.com (Xavier Coulon)
Date: Thu, 28 May 2015 22:57:50 +0200
Subject: [jbosstools-dev] Proposed changes to target platform
	4.50.0.Beta1-SNAPSHOT: Mars RC2 & LaunchBar
In-Reply-To: <55676FFB.2080609@redhat.com>
References: <5566D48C.3000609@redhat.com> <556730B8.5080606@redhat.com>
	<55676FFB.2080609@redhat.com>
Message-ID: <BCBCCDF7-C205-44CF-8412-5D6E671ADC44@redhat.com>

Thanks, Nick !

Best regards,
/Xavier



> On 28 May 2015, at 21:43, Nick Boldt <nboldt at redhat.com> wrote:
> 
> Xavier has reported we are missing some IUs from Jetty for LiveReload.
> 
> Here's the PR:
> 
> https://github.com/jbosstools/jbosstools-target-platforms/pull/147
> 
> 
> On 05/28/2015 11:14 AM, Nick Boldt wrote:
>> Found a newer version of e4.ui today, so I've updated the PR. The p2diff
>> as produced in JBIDE-19776 remains the same, as this change [1] only
>> affects the version of 2 plugins.
>> 
>> [1]
>> https://github.com/nickboldt/jbosstools-target-platforms/commit/dab7c31ec5775709484e58a28f3b45777ac3e1b5
>> 
>> 
>> I hope to be able to *merge this tomorrow* into the 4.50.x branch so we
>> can get it built before the weekend, well in advance of next week's code
>> freeze.
>> 
>> If you have any concerns, please raise them ASAP.
>> 
>> On 05/28/2015 04:40 AM, Mickael Istria wrote:
>>> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
>>> Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
>>> https://github.com/jbosstools/jbosstools-target-platforms/pull/146
>>> 
>>> It consists in the following change(s):
>>> * JBIDE-19776: Mars RC2
>>> * JBIDE-19879: LaunchBar dependencies (only new 4 plugins from Mars repo)
>>> 
>>> p2diff reports:
>>> https://issues.jboss.org/browse/JBIDE-19776?focusedCommentId=13071774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071774
>>> 
>>> (nothing alarming)
>>> 
>>> Please review the above PR(s), as it will be applied very soon. You can
>>> use the following to build & test the target-platform locally against
>>> your component(s).
>>> 
>>> Build target-platform:
>>> $ cd /path/to/jbosstools-target-platforms/jbosstools/multiple
>>> $ git fetch origin pull/146/head && git checkout FETCH_HEAD
>>> $ mvn clean install
>>> 
>>> Then, to test the new "multiple" target platform against your
>>> component's build:
>>> $ cd /path/to/your/jbosstools-component
>>> $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT
>>> -Dtpc.targetKind=multiple
>>> 
>>> --
>>> 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>
>>> 
>>> 
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> 
>> 
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150528/f64dc4e1/attachment-0001.html 

From manderse at redhat.com  Thu May 28 19:40:48 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 29 May 2015 01:40:48 +0200
Subject: [jbosstools-dev] ACTION REQUIRED: test-drive Tycho 0.23.0
In-Reply-To: <55675511.50408@gmail.com>
References: <F8F18CC0DECD384BAC6FBAD1A7C49A48996B6E72@DEWDFEMB18B.global.corp.sap>
	<55675511.50408@gmail.com>
Message-ID: <8A06C6CA-C8C1-41C3-97E6-2621D2300166@redhat.com>

I thought we already were using Tyco 0.23, at least for the eclipse 
product build?

One gotcha is that https://wiki.eclipse.org/Tycho/Release_Notes/0.23#p2 
might break
Integration Stack if they build against non-Mars. So just something for 
IS to be aware of
if they need to override it until tycho 0.24 is out.

/max

> Soon, Tycho 0.23.0 will be available.
>
> If possible, I'd like to build JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1 
> using
> Tycho 0.23.0.
>
> If you add the code below to your settings.xml, then build with
> -DtychoVersion=0.23.0, you'll be able to see if anything breaks w/ 
> Tycho
> 0.23.0.
>
> If it does, please open a JIRA.
>
> Thanks!
>
>
> -------- Forwarded Message --------
> Subject: [tycho-user] Tycho 0.23.0 staged
> Date: Thu, 28 May 2015 16:07:55 +0000
> From: Sievers, Jan <jan.sievers at sap.com>
> Reply-To: Tycho user list <tycho-user at eclipse.org>
> To: Tycho user list (tycho-user at eclipse.org) <tycho-user at eclipse.org>
> CC: Tycho developers list (tycho-dev at eclipse.org) 
> <tycho-dev at eclipse.org>
>
> Tycho milestone release 0.23.0 has been staged.
>
> For details of new features and bugfixes, see release notes [1].
> Please help by testing the staged milestone build. To use it, change
> your tycho version to 0.23.0 and add snippet [2] to your pom.
>
> NOTE: if you build products for MacOSX against p2 repositories older
> than eclipse Mars, there is a known bug [3]
>
> We plan to promote this release in one week unless major regressions 
> are
> found.
>
> Regards,
> Tycho team
>
> [1] http://wiki.eclipse.org/Tycho/Release_Notes/0.23
> [2]
> <pluginRepositories>
> <pluginRepository>
> <id>tycho-staged</id>
>
> <url>https://oss.sonatype.org/content/repositories/orgeclipsetycho-1021/</url>
> </pluginRepository>
> </pluginRepositories>
>
> [3] https://wiki.eclipse.org/Tycho/Release_Notes/0.23#p2
>
> _______________________________________________
> tycho-user mailing list
> tycho-user at eclipse.org
> To change your delivery options, retrieve your password, or 
> unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tycho-user
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen

From nboldt at redhat.com  Thu May 28 19:57:57 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 28 May 2015 19:57:57 -0400
Subject: [jbosstools-dev] ACTION REQUIRED: test-drive Tycho 0.23.0
In-Reply-To: <8A06C6CA-C8C1-41C3-97E6-2621D2300166@redhat.com>
References: <F8F18CC0DECD384BAC6FBAD1A7C49A48996B6E72@DEWDFEMB18B.global.corp.sap>	<55675511.50408@gmail.com>
	<8A06C6CA-C8C1-41C3-97E6-2621D2300166@redhat.com>
Message-ID: <5567AB85.9070807@redhat.com>

Yes, we switched to Tycho 0.23.0-SNAPSHOT for JBDS product build on 
April 24:

https://github.com/jbdevstudio/jbdevstudio-product/commit/bd5456c5a89eec705178d5e376a5bc41395f8436#diff-600376dffeb79835ede4a0b285078036R54

But for the rest of JBT, we're still on 0.22.0:

https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L23


On 05/28/2015 07:40 PM, Max Rydahl Andersen wrote:
> I thought we already were using Tyco 0.23, at least for the eclipse
> product build?
>
> One gotcha is that https://wiki.eclipse.org/Tycho/Release_Notes/0.23#p2
> might break
> Integration Stack if they build against non-Mars. So just something for
> IS to be aware of
> if they need to override it until tycho 0.24 is out.
>
> /max
>
>> Soon, Tycho 0.23.0 will be available.
>>
>> If possible, I'd like to build JBT 4.3.0.Beta1 / JBDS 9.0.0.Beta1
>> using
>> Tycho 0.23.0.
>>
>> If you add the code below to your settings.xml, then build with
>> -DtychoVersion=0.23.0, you'll be able to see if anything breaks w/
>> Tycho
>> 0.23.0.
>>
>> If it does, please open a JIRA.
>>
>> Thanks!
>>
>>
>> -------- Forwarded Message --------
>> Subject: [tycho-user] Tycho 0.23.0 staged
>> Date: Thu, 28 May 2015 16:07:55 +0000
>> From: Sievers, Jan <jan.sievers at sap.com>
>> Reply-To: Tycho user list <tycho-user at eclipse.org>
>> To: Tycho user list (tycho-user at eclipse.org) <tycho-user at eclipse.org>
>> CC: Tycho developers list (tycho-dev at eclipse.org)
>> <tycho-dev at eclipse.org>
>>
>> Tycho milestone release 0.23.0 has been staged.
>>
>> For details of new features and bugfixes, see release notes [1].
>> Please help by testing the staged milestone build. To use it, change
>> your tycho version to 0.23.0 and add snippet [2] to your pom.
>>
>> NOTE: if you build products for MacOSX against p2 repositories older
>> than eclipse Mars, there is a known bug [3]
>>
>> We plan to promote this release in one week unless major regressions
>> are
>> found.
>>
>> Regards,
>> Tycho team
>>
>> [1] http://wiki.eclipse.org/Tycho/Release_Notes/0.23
>> [2]
>> <pluginRepositories>
>> <pluginRepository>
>> <id>tycho-staged</id>
>>
>> <url>https://oss.sonatype.org/content/repositories/orgeclipsetycho-1021/</url>
>> </pluginRepository>
>> </pluginRepositories>
>>
>> [3] https://wiki.eclipse.org/Tycho/Release_Notes/0.23#p2
>>
>> _______________________________________________
>> tycho-user mailing list
>> tycho-user at eclipse.org
>> To change your delivery options, retrieve your password, or
>> unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/tycho-user
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> /max
> http://about.me/maxandersen
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

From nboldt at redhat.com  Sat May 30 12:39:18 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Sat, 30 May 2015 12:39:18 -0400
Subject: [jbosstools-dev] Proposed changes to target platform
 4.50.0.Beta1-SNAPSHOT: Mars RC2 & LaunchBar
In-Reply-To: <55676FFB.2080609@redhat.com>
References: <5566D48C.3000609@redhat.com> <556730B8.5080606@redhat.com>
	<55676FFB.2080609@redhat.com>
Message-ID: <5569E7B6.4020001@redhat.com>

Fred reported we had old versions of m2e-wtp and m2e-mavenarchiver 
included in the proposal Beta1-SNAPSHOT TP.

So, PR 146 has been updated to include new bits from:

http://download.jboss.org/jbosstools/updates/requirements/m2e-wtp/1.2.0.20150526-1758/

http://download.jboss.org/jbosstools/updates/requirements/m2eclipse-mavenarchiver/0.17.0.201502101659/

Ref: https://issues.jboss.org/browse/JBIDE-19776
TP: https://github.com/jbosstools/jbosstools-target-platforms/pull/146

On 05/28/2015 03:43 PM, Nick Boldt wrote:
> Xavier has reported we are missing some IUs from Jetty for LiveReload.
>
> Here's the PR:
>
> https://github.com/jbosstools/jbosstools-target-platforms/pull/147
>
>
> On 05/28/2015 11:14 AM, Nick Boldt wrote:
>> Found a newer version of e4.ui today, so I've updated the PR. The p2diff
>> as produced in JBIDE-19776 remains the same, as this change [1] only
>> affects the version of 2 plugins.
>>
>> [1]
>> https://github.com/nickboldt/jbosstools-target-platforms/commit/dab7c31ec5775709484e58a28f3b45777ac3e1b5
>>
>>
>>
>> I hope to be able to *merge this tomorrow* into the 4.50.x branch so we
>> can get it built before the weekend, well in advance of next week's code
>> freeze.
>>
>> If you have any concerns, please raise them ASAP.
>>
>> On 05/28/2015 04:40 AM, Mickael Istria wrote:
>>> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
>>> Developer Studio 4.50.0.Beta1-SNAPSHOT target platforms.
>>> https://github.com/jbosstools/jbosstools-target-platforms/pull/146
>>>
>>> It consists in the following change(s):
>>> * JBIDE-19776: Mars RC2
>>> * JBIDE-19879: LaunchBar dependencies (only new 4 plugins from Mars
>>> repo)
>>>
>>> p2diff reports:
>>> https://issues.jboss.org/browse/JBIDE-19776?focusedCommentId=13071774&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13071774
>>>
>>>
>>> (nothing alarming)
>>>
>>> Please review the above PR(s), as it will be applied very soon. You can
>>> use the following to build & test the target-platform locally against
>>> your component(s).
>>>
>>> Build target-platform:
>>> $ cd /path/to/jbosstools-target-platforms/jbosstools/multiple
>>> $ git fetch origin pull/146/head && git checkout FETCH_HEAD
>>> $ mvn clean install
>>>
>>> Then, to test the new "multiple" target platform against your
>>> component's build:
>>> $ cd /path/to/your/jbosstools-component
>>> $ mvn clean verify -Dtpc.version=4.50.0.Beta1-SNAPSHOT
>>> -Dtpc.targetKind=multiple
>>>
>>> --
>>> 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>
>>>
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>
>

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com