From manderse at redhat.com  Tue Dec  1 05:34:18 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 01 Dec 2015 11:34:18 +0100
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
Message-ID: <8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>

On 30 Nov 2015, at 21:55, Nick Boldt wrote:

> Looking in the 4.3.x and master branches, I can only see two poms with
> a reference to maven-dependency-plugin or generate-resources, both of
> which have their <skip>false</skip> set:
>
> ./plugins/org.jboss.tools.openshift.client/pom.xml
> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>
> So, how was your openshift build failing? Can you give details
> (console log, for example) on how `mvn clean install -DskipTests=true`
> failed?

yes, the build did not work when you run with -DskipTests=true.

I have to run it with just "mvn clean install" to work, just doing "mvn 
clean install -DskipTests=true" resulted in failure to build related to 
the openshift java client updates.

anyway, lets just fix the issue that requires us to litter 
<skip>false</skip>
into components builds. Please.

/max

>
>
> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
> <manderse at redhat.com> wrote:
>> on this note - I just spent half the day figuring out why
>> jbosstools-openshift
>> was not building when I did "mvn clean install -DskipTests=true".
>>
>> Turns out I'm hit with this exact issue - that skipTest is for reason 
>> I
>> never understood
>> is used to turn off download for testing dependencies by turning of 
>> download
>> of all dependencies.
>>
>> We need to stop adding workaround for this into our projects and 
>> instead
>> have those few projects
>> that have large dependencies to use another mechanism to turn of 
>> download.
>>
>> /max
>>
>> Only one I don't know about is swtbot.test.skip.
>>
>> The others I don't see how to remove nor why since they all play a 
>> part.
>>
>> This sounds more like should fix how the skip's works rather than 
>> remove
>> them.
>>
>> The issue in JBIDE-15330 seem to because of the many time pointed out 
>> bad
>> assumption that skipTest
>> should mean you don't want dependencies to be downloaded.
>>
>> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>>
>> The issue is <skipRequirements>${skipTests}</skipRequirements>
>> and then skipRequirements are used to disable all basic dependency 
>> fetching
>> which is simply a wrong/bad assumption.
>>
>> /max
>>
>> If your project needs to download upstream libraries/runtimes/jars
>> using something like maven-dependency-plugin, and you have not set
>> <skip>false</skip> for those plugins' builds, eg.,
>> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
>> should do so.
>>
>> This is because I'd like to remove some of the obsolete skip*
>> variables we have in the parent pom, and you don't want your builds 
>> to
>> fail when skipping tests, as livereload used to before
>> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>>
>> Here are all the skip-related variables in our parent pom [1]:
>>
>> <swtbot.test.skip>true</swtbot.test.skip>
>> <skipRequirements>${skipTests}</skipRequirements>
>> <skipPrivateRequirements>true</skipPrivateRequirements>
>> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
>> and
>> skipTestsOrITests (which is true when skipTests or skipITests is 
>> true).
>>
>> [1]
>> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>>
>> Which of those are no longer used, that can be safely removed? Are
>> skipTestsWithPrivateRequirements and skipRequirements used for the
>> same purposes as skipITests?
>>
>> Thanks,
>>
>> --
>> 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_______________________________________________
>> 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


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151201/4b5970e9/attachment.html 

From mmalina at redhat.com  Tue Dec  1 11:12:58 2015
From: mmalina at redhat.com (Martin Malina)
Date: Tue, 1 Dec 2015 17:12:58 +0100
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
	maven-dependency-plugin to download upstream requirements
	into your build / removing redundant skip*Requirements
	variables from parent pom
In-Reply-To: <0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
Message-ID: <E8F23B83-BE67-4572-AF94-7275C136B148@redhat.com>

We (QA) used to use swtbot.test.skip in the past, but we abandoned it earlier this year:
https://github.com/jbosstools/jbosstools-integration-tests/commit/517bc6938bb1cbe616a2abeb25b383da3d6c4dda

So we're fine with removing it. But I don't know if some developers use it for their tests in their repos.

-Martin


> On 26. 11. 2015, at 0:00, Max Rydahl Andersen <manderse at redhat.com> wrote:
> 
> Only one I don't know about is swtbot.test.skip.
> 
> The others I don't see how to remove nor why since they all play a part.
> 
> This sounds more like should fix how the skip's works rather than remove them.
> 
> The issue in JBIDE-15330 seem to because of the many time pointed out bad assumption that skipTest 
> should mean you don't want dependencies to be downloaded.
> 
> Reported here https://issues.jboss.org/browse/JBIDE-15332 <https://issues.jboss.org/browse/JBIDE-15332> in 2013.
> 
> The issue is <skipRequirements>${skipTests}</skipRequirements>
> and then skipRequirements are used to disable all basic dependency fetching
> which is simply a wrong/bad assumption.
> 
> /max
> 
> If your project needs to download upstream libraries/runtimes/jars
> using something like maven-dependency-plugin, and you have not set
> <skip>false</skip> for those plugins' builds, eg.,
> https://github.com/jbosstools/jbosstools-livereload/pull/54/ <https://github.com/jbosstools/jbosstools-livereload/pull/54/> you
> should do so.
> 
> This is because I'd like to remove some of the obsolete skip*
> variables we have in the parent pom, and you don't want your builds to
> fail when skipping tests, as livereload used to before
> https://issues.jboss.org/browse/JBIDE-15330 <https://issues.jboss.org/browse/JBIDE-15330> was fixed.
> 
> Here are all the skip-related variables in our parent pom [1]:
> 
> <swtbot.test.skip>true</swtbot.test.skip>
> <skipRequirements>${skipTests}</skipRequirements>
> <skipPrivateRequirements>true</skipPrivateRequirements>
> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
> and
> skipTestsOrITests (which is true when skipTests or skipITests is true).
> 
> [1] https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml <https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml>
> Which of those are no longer used, that can be safely removed? Are
> skipTestsWithPrivateRequirements and skipRequirements used for the
> same purposes as skipITests?
> 
> Thanks,
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com <http://nick.divbyzero.com/>
> 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 <https://lists.jboss.org/mailman/listinfo/jbosstools-dev>
> /max
> http://about.me/maxandersen <http://about.me/maxandersen>_______________________________________________
> 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/20151201/d83c5af4/attachment-0001.html 

From dgolovin at exadel.com  Tue Dec  1 20:57:35 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 02 Dec 2015 01:57:35 +0000
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
Message-ID: <CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>

On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>
> Looking in the 4.3.x and master branches, I can only see two poms with
> a reference to maven-dependency-plugin or generate-resources, both of
> which have their <skip>false</skip> set:
>
> ./plugins/org.jboss.tools.openshift.client/pom.xml
> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>
> So, how was your openshift build failing? Can you give details
> (console log, for example) on how mvn clean install -DskipTests=true
> failed?
>
> yes, the build did not work when you run with -DskipTests=true.
>
> I have to run it with just "mvn clean install" to work, just doing "mvn
> clean install -DskipTests=true" resulted in failure to build related to the
> openshift java client updates.
>
> anyway, lets just fix the issue that requires us to litter
> <skip>false</skip>
> into components builds. Please.
>
I cannot replicate that. I was always running full build with

mvn clean install -DskipTests=true

before and after branching of 4.3.x and builds were always fine. I remember
to have problems when new code pushed in tooling referencing resent changes
in client jar, which is not available from maven repository.

nightly full build from master is still available from wonka and it's been
running without any problems for a couple weeks.

what kind of failure you have for openshift build from 4.3.x branch?

Denis


> /max
>
> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
> manderse at redhat.com wrote:
>
> on this note - I just spent half the day figuring out why
> jbosstools-openshift
> was not building when I did "mvn clean install -DskipTests=true".
>
> Turns out I'm hit with this exact issue - that skipTest is for reason I
> never understood
> is used to turn off download for testing dependencies by turning of
> download
> of all dependencies.
>
> We need to stop adding workaround for this into our projects and instead
> have those few projects
> that have large dependencies to use another mechanism to turn of download.
>
> /max
>
> Only one I don't know about is swtbot.test.skip.
>
> The others I don't see how to remove nor why since they all play a part.
>
> This sounds more like should fix how the skip's works rather than remove
> them.
>
> The issue in JBIDE-15330 <https://issues.jboss.org/browse/JBIDE-15330>
> seem to because of the many time pointed out bad
> assumption that skipTest
> should mean you don't want dependencies to be downloaded.
>
> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>
> The issue is <skipRequirements>${skipTests}</skipRequirements>
> and then skipRequirements are used to disable all basic dependency fetching
> which is simply a wrong/bad assumption.
>
> /max
>
> If your project needs to download upstream libraries/runtimes/jars
> using something like maven-dependency-plugin, and you have not set
> <skip>false</skip> for those plugins' builds, eg.,
> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
> should do so.
>
> This is because I'd like to remove some of the obsolete skip*
> variables we have in the parent pom, and you don't want your builds to
> fail when skipping tests, as livereload used to before
> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>
> Here are all the skip-related variables in our parent pom [1]:
>
> <swtbot.test.skip>true</swtbot.test.skip>
> <skipRequirements>${skipTests}</skipRequirements>
> <skipPrivateRequirements>true</skipPrivateRequirements>
>
> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
> and
> skipTestsOrITests (which is true when skipTests or skipITests is true).
>
> [1]
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>
> Which of those are no longer used, that can be safely removed? Are
> skipTestsWithPrivateRequirements and skipRequirements used for the
> same purposes as skipITests?
>
> Thanks,
>
> --
> 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_______________________________________________
> 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
>
> /max
> http://about.me/maxandersen
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151202/4dc1227e/attachment.html 

From dgolovin at exadel.com  Tue Dec  1 21:44:55 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 02 Dec 2015 02:44:55 +0000
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
Message-ID: <CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>

There are several kinds of downloaded resources throughout jbosstools:
1. *Runtimes* required during test execution (seam, as and etc)
2. *Compile time libraries* required for compilations
3. *Test project libraries* included into test projects

(1) is defines test environment and should be skipped for download if tests
skipped
(2) and (3) should be never skipped.

Now to handle (1) we use three different maven plugins declared in parent
pom (see parent/pom.xml line 504
<https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L504>
):

   - maven-dependency-plugin - to download some early versions of jboss-as
   from maven repo
   - download-maven-plugin - to download jboss-as from specified url
   - maven-download-plugin - to download seam distributions from specified
   url

To handle (2) and (3) only maven-dependency-plugin is used.

I think at this time obviously we have to change
maven-dependency-plugin declaration
in parent/pom.xml#build/pluginManagement to never skip downloading
dependencies, because it is most common use case. After it is done we can
remove unnecessary <skip>false</skip> throughout the projects.

If there are libs for (2) and (3) downloaded from external URL using
download-maven-plugin/maven-download-plugin we should probably move them to
locus.

Denis

On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin <dgolovin at exadel.com> wrote:

> On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>
>> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>>
>> Looking in the 4.3.x and master branches, I can only see two poms with
>> a reference to maven-dependency-plugin or generate-resources, both of
>> which have their <skip>false</skip> set:
>>
>> ./plugins/org.jboss.tools.openshift.client/pom.xml
>> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>>
>> So, how was your openshift build failing? Can you give details
>> (console log, for example) on how mvn clean install -DskipTests=true
>> failed?
>>
>> yes, the build did not work when you run with -DskipTests=true.
>>
>> I have to run it with just "mvn clean install" to work, just doing "mvn
>> clean install -DskipTests=true" resulted in failure to build related to the
>> openshift java client updates.
>>
>> anyway, lets just fix the issue that requires us to litter
>> <skip>false</skip>
>> into components builds. Please.
>>
> I cannot replicate that. I was always running full build with
>
> mvn clean install -DskipTests=true
>
> before and after branching of 4.3.x and builds were always fine. I
> remember to have problems when new code pushed in tooling referencing
> resent changes in client jar, which is not available from maven repository.
>
> nightly full build from master is still available from wonka and it's been
> running without any problems for a couple weeks.
>
> what kind of failure you have for openshift build from 4.3.x branch?
>
> Denis
>
>
>> /max
>>
>> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
>> manderse at redhat.com wrote:
>>
>> on this note - I just spent half the day figuring out why
>> jbosstools-openshift
>> was not building when I did "mvn clean install -DskipTests=true".
>>
>> Turns out I'm hit with this exact issue - that skipTest is for reason I
>> never understood
>> is used to turn off download for testing dependencies by turning of
>> download
>> of all dependencies.
>>
>> We need to stop adding workaround for this into our projects and instead
>> have those few projects
>> that have large dependencies to use another mechanism to turn of download.
>>
>> /max
>>
>> Only one I don't know about is swtbot.test.skip.
>>
>> The others I don't see how to remove nor why since they all play a part.
>>
>> This sounds more like should fix how the skip's works rather than remove
>> them.
>>
>> The issue in JBIDE-15330 <https://issues.jboss.org/browse/JBIDE-15330>
>> seem to because of the many time pointed out bad
>> assumption that skipTest
>> should mean you don't want dependencies to be downloaded.
>>
>> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>>
>> The issue is <skipRequirements>${skipTests}</skipRequirements>
>> and then skipRequirements are used to disable all basic dependency
>> fetching
>> which is simply a wrong/bad assumption.
>>
>> /max
>>
>> If your project needs to download upstream libraries/runtimes/jars
>> using something like maven-dependency-plugin, and you have not set
>> <skip>false</skip> for those plugins' builds, eg.,
>> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
>> should do so.
>>
>> This is because I'd like to remove some of the obsolete skip*
>> variables we have in the parent pom, and you don't want your builds to
>> fail when skipping tests, as livereload used to before
>> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>>
>> Here are all the skip-related variables in our parent pom [1]:
>>
>> <swtbot.test.skip>true</swtbot.test.skip>
>> <skipRequirements>${skipTests}</skipRequirements>
>> <skipPrivateRequirements>true</skipPrivateRequirements>
>>
>> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
>> and
>> skipTestsOrITests (which is true when skipTests or skipITests is true).
>>
>> [1]
>> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>>
>> Which of those are no longer used, that can be safely removed? Are
>> skipTestsWithPrivateRequirements and skipRequirements used for the
>> same purposes as skipITests?
>>
>> Thanks,
>>
>> --
>> 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_______________________________________________
>> 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
>>
>> /max
>> http://about.me/maxandersen
>>
>> CONFIDENTIALITY NOTICE: This email and files attached to it are
>> confidential. If you are not the intended recipient you are hereby notified
>> that using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email.
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151202/a2f81657/attachment-0001.html 

From alkazako at redhat.com  Tue Dec  1 22:13:43 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Tue, 1 Dec 2015 22:13:43 -0500
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
Message-ID: <565E61E7.4070600@redhat.com>



On 12/01/2015 09:44 PM, Denis Golovin wrote:
> There are several kinds of downloaded resources throughout jbosstools:
> 1. *Runtimes* required during test execution (seam, as and etc)
> 2. *Compile time libraries* required for compilations
> 3. *Test project libraries* included into test projects
>
> (1) is defines test environment and should be skipped for download if 
> tests skipped
> (2) and (3) should be never skipped.
Why do you need (3) if you not executing tests?

Thanks.

>
> Now to handle (1) we use three different maven plugins declared in 
> parent pom (see parent/pom.xml line 504 
> <https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L504>):
>
>   * maven-dependency-plugin - to download some early versions of
>     jboss-as from maven repo
>   * download-maven-plugin - to download jboss-as from specified url
>   * maven-download-plugin - to download seam distributions from
>     specified url
>
> To handle (2) and (3) only maven-dependency-plugin is used.
> I think at this time obviously we have to change 
> maven-dependency-plugin declaration in 
> parent/pom.xml#build/pluginManagement to never skip downloading 
> dependencies, because it is most common use case. After it is done we 
> can remove unnecessary <skip>false</skip> throughout the projects.
>
> If there are libs for (2) and (3) downloaded from external URL using 
> download-maven-plugin/maven-download-plugin we should probably move 
> them to locus.
>
> Denis
>
> On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin <dgolovin at exadel.com 
> <mailto:dgolovin at exadel.com>> wrote:
>
>     On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen
>     <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>
>         On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>
>             Looking in the 4.3.x and master branches, I can only see
>             two poms with
>             a reference to maven-dependency-plugin or
>             generate-resources, both of
>             which have their <skip>false</skip> set:
>
>             ./plugins/org.jboss.tools.openshift.client/pom.xml
>             ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>
>             So, how was your openshift build failing? Can you give details
>             (console log, for example) on how |mvn clean install
>             -DskipTests=true|
>             failed?
>
>         yes, the build did not work when you run with -DskipTests=true.
>
>         I have to run it with just "mvn clean install" to work, just
>         doing "mvn clean install -DskipTests=true" resulted in failure
>         to build related to the openshift java client updates.
>
>         anyway, lets just fix the issue that requires us to litter
>         <skip>false</skip>
>         into components builds. Please.
>
>     I cannot replicate that. I was always running full build with
>
>     mvn clean install -DskipTests=true
>
>     before and after branching of 4.3.x and builds were always fine. I
>     remember to have problems when new code pushed in tooling
>     referencing resent changes in client jar, which is not available
>     from maven repository.
>
>     nightly full build from master is still available from wonka and
>     it's been running without any problems for a couple weeks.
>
>     what kind of failure you have for openshift build from 4.3.x branch?
>
>     Denis
>
>         /max
>
>             On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
>             manderse at redhat.com <mailto:manderse at redhat.com> wrote:
>
>                 on this note - I just spent half the day figuring out why
>                 jbosstools-openshift
>                 was not building when I did "mvn clean install
>                 -DskipTests=true".
>
>                 Turns out I'm hit with this exact issue - that
>                 skipTest is for reason I
>                 never understood
>                 is used to turn off download for testing dependencies
>                 by turning of download
>                 of all dependencies.
>
>                 We need to stop adding workaround for this into our
>                 projects and instead
>                 have those few projects
>                 that have large dependencies to use another mechanism
>                 to turn of download.
>
>                 /max
>
>                 Only one I don't know about is swtbot.test.skip.
>
>                 The others I don't see how to remove nor why since
>                 they all play a part.
>
>                 This sounds more like should fix how the skip's works
>                 rather than remove
>                 them.
>
>                 The issue in JBIDE-15330
>                 <https://issues.jboss.org/browse/JBIDE-15330> seem to
>                 because of the many time pointed out bad
>                 assumption that skipTest
>                 should mean you don't want dependencies to be downloaded.
>
>                 Reported here
>                 https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>
>                 The issue is
>                 <skipRequirements>${skipTests}</skipRequirements>
>                 and then skipRequirements are used to disable all
>                 basic dependency fetching
>                 which is simply a wrong/bad assumption.
>
>                 /max
>
>                 If your project needs to download upstream
>                 libraries/runtimes/jars
>                 using something like maven-dependency-plugin, and you
>                 have not set
>                 <skip>false</skip> for those plugins' builds, eg.,
>                 https://github.com/jbosstools/jbosstools-livereload/pull/54/
>                 you
>                 should do so.
>
>                 This is because I'd like to remove some of the
>                 obsolete skip*
>                 variables we have in the parent pom, and you don't
>                 want your builds to
>                 fail when skipping tests, as livereload used to before
>                 https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>
>                 Here are all the skip-related variables in our parent
>                 pom [1]:
>
>                 <swtbot.test.skip>true</swtbot.test.skip>
>                 <skipRequirements>${skipTests}</skipRequirements>
>                 <skipPrivateRequirements>true</skipPrivateRequirements>
>                 <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
>                 and
>                 skipTestsOrITests (which is true when skipTests or
>                 skipITests is true).
>
>                 [1]
>                 https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>
>                 Which of those are no longer used, that can be safely
>                 removed? Are
>                 skipTestsWithPrivateRequirements and skipRequirements
>                 used for the
>                 same purposes as skipITests?
>
>                 Thanks,
>
>                 --
>                 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
>                 <mailto: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
>                 <mailto: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
>
>         /max
>         http://about.me/maxandersen
>
>
>         CONFIDENTIALITY NOTICE: This email and files attached to it
>         are confidential. If you are not the intended recipient you
>         are hereby notified that using, copying, distributing or
>         taking any action in reliance on the contents of this
>         information is strictly prohibited. If you have received this
>         email in error please notify the sender and delete this email.
>
>         _______________________________________________
>         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
>
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are 
> confidential. If you are not the intended recipient you are hereby 
> notified that using, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited. 
> If you have received this email in error please notify the sender and 
> delete this email.
>
>
>
> _______________________________________________
> 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/20151201/ed157865/attachment-0001.html 

From dgolovin at exadel.com  Tue Dec  1 22:23:30 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 02 Dec 2015 03:23:30 +0000
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <565E61E7.4070600@redhat.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
	<565E61E7.4070600@redhat.com>
Message-ID: <CAJXFskY0LvLcdCJt5eg+rheb6oX6pXwjk7NrP9EwL3zfVM87hQ@mail.gmail.com>

Because test projects included into test bundles.

On Tue, Dec 1, 2015, 7:14 PM Alexey Kazakov <alkazako at redhat.com> wrote:

>
>
> On 12/01/2015 09:44 PM, Denis Golovin wrote:
>
> There are several kinds of downloaded resources throughout jbosstools:
> 1. *Runtimes* required during test execution (seam, as and etc)
> 2. *Compile time libraries* required for compilations
> 3. *Test project libraries* included into test projects
>
> (1) is defines test environment and should be skipped for download if
> tests skipped
> (2) and (3) should be never skipped.
>
> Why do you need (3) if you not executing tests?
>
> Thanks.
>
>
>
> Now to handle (1) we use three different maven plugins declared in parent
> pom (see parent/pom.xml line 504
> <https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml#L504>
> ):
>
>    - maven-dependency-plugin - to download some early versions of
>    jboss-as from maven repo
>    - download-maven-plugin - to download jboss-as from specified url
>    - maven-download-plugin - to download seam distributions from
>    specified url
>
> To handle (2) and (3) only maven-dependency-plugin is used.
> I think at this time obviously we have to change maven-dependency-plugin declaration
> in parent/pom.xml#build/pluginManagement to never skip downloading
> dependencies, because it is most common use case. After it is done we can
> remove unnecessary <skip>false</skip> throughout the projects.
>
> If there are libs for (2) and (3) downloaded from external URL using
> download-maven-plugin/maven-download-plugin we should probably move them to
> locus.
>
> Denis
>
> On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin <dgolovin at exadel.com> wrote:
>
>> On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen <manderse at redhat.com>
>> wrote:
>>
>>> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>>>
>>> Looking in the 4.3.x and master branches, I can only see two poms with
>>> a reference to maven-dependency-plugin or generate-resources, both of
>>> which have their <skip>false</skip> set:
>>>
>>> ./plugins/org.jboss.tools.openshift.client/pom.xml
>>> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>>>
>>> So, how was your openshift build failing? Can you give details
>>> (console log, for example) on how mvn clean install -DskipTests=true
>>> failed?
>>>
>>> yes, the build did not work when you run with -DskipTests=true.
>>>
>>> I have to run it with just "mvn clean install" to work, just doing "mvn
>>> clean install -DskipTests=true" resulted in failure to build related to the
>>> openshift java client updates.
>>>
>>> anyway, lets just fix the issue that requires us to litter
>>> <skip>false</skip>
>>> into components builds. Please.
>>>
>> I cannot replicate that. I was always running full build with
>>
>> mvn clean install -DskipTests=true
>>
>> before and after branching of 4.3.x and builds were always fine. I
>> remember to have problems when new code pushed in tooling referencing
>> resent changes in client jar, which is not available from maven repository.
>>
>> nightly full build from master is still available from wonka and it's
>> been running without any problems for a couple weeks.
>>
>> what kind of failure you have for openshift build from 4.3.x branch?
>>
>> Denis
>>
>>
>>> /max
>>>
>>> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
>>> manderse at redhat.com wrote:
>>>
>>> on this note - I just spent half the day figuring out why
>>> jbosstools-openshift
>>> was not building when I did "mvn clean install -DskipTests=true".
>>>
>>> Turns out I'm hit with this exact issue - that skipTest is for reason I
>>> never understood
>>> is used to turn off download for testing dependencies by turning of
>>> download
>>> of all dependencies.
>>>
>>> We need to stop adding workaround for this into our projects and instead
>>> have those few projects
>>> that have large dependencies to use another mechanism to turn of
>>> download.
>>>
>>> /max
>>>
>>> Only one I don't know about is swtbot.test.skip.
>>>
>>> The others I don't see how to remove nor why since they all play a part.
>>>
>>> This sounds more like should fix how the skip's works rather than remove
>>> them.
>>>
>>> The issue in JBIDE-15330 <https://issues.jboss.org/browse/JBIDE-15330>
>>> seem to because of the many time pointed out bad
>>> assumption that skipTest
>>> should mean you don't want dependencies to be downloaded.
>>>
>>> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>>>
>>> The issue is <skipRequirements>${skipTests}</skipRequirements>
>>> and then skipRequirements are used to disable all basic dependency
>>> fetching
>>> which is simply a wrong/bad assumption.
>>>
>>> /max
>>>
>>> If your project needs to download upstream libraries/runtimes/jars
>>> using something like maven-dependency-plugin, and you have not set
>>> <skip>false</skip> for those plugins' builds, eg.,
>>> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
>>> should do so.
>>>
>>> This is because I'd like to remove some of the obsolete skip*
>>> variables we have in the parent pom, and you don't want your builds to
>>> fail when skipping tests, as livereload used to before
>>> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>>>
>>> Here are all the skip-related variables in our parent pom [1]:
>>>
>>> <swtbot.test.skip>true</swtbot.test.skip>
>>> <skipRequirements>${skipTests}</skipRequirements>
>>> <skipPrivateRequirements>true</skipPrivateRequirements>
>>>
>>> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
>>> and
>>> skipTestsOrITests (which is true when skipTests or skipITests is true).
>>>
>>> [1]
>>> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>>>
>>> Which of those are no longer used, that can be safely removed? Are
>>> skipTestsWithPrivateRequirements and skipRequirements used for the
>>> same purposes as skipITests?
>>>
>>> Thanks,
>>>
>>> --
>>> 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_______________________________________________
>>> 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
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>> CONFIDENTIALITY NOTICE: This email and files attached to it are
>>> confidential. If you are not the intended recipient you are hereby notified
>>> that using, copying, distributing or taking any action in reliance on the
>>> contents of this information is strictly prohibited. If you have received
>>> this email in error please notify the sender and delete this email.
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
>
> _______________________________________________
> jbosstools-dev mailing listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151202/8c996ca5/attachment-0001.html 

From manderse at redhat.com  Wed Dec  2 04:21:46 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 02 Dec 2015 10:21:46 +0100
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
Message-ID: <C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>

Nice writeup.

> I think at this time obviously we have to change
> maven-dependency-plugin declaration
> in parent/pom.xml#build/pluginManagement to never skip downloading
> dependencies, because it is most common use case. After it is done we 
> can
> remove unnecessary <skip>false</skip> throughout the projects.

Yes - your conclusion matches mine on the jira and what mistria 
suggestion for fixes
and with my updates handles.

Can you make it happen ? :)

> If there are libs for (2) and (3) downloaded from external URL using
> download-maven-plugin/maven-download-plugin we should probably move 
> them to
> locus.

Main problem I know is forge, hibernate and openshift afaik.

forge and openshift would not be able to move very fast if we moved 
their libs for Locus.

Hibernate - we don't actually want/intend to expose the internal apis of 
hibernate so not
sure if pushing all variations of hibernate into Locus is such a good 
idea....but it could
be considered.

One thing that might be worth looking for are those bundling mockito or 
other testing libs
that we might already have put into locus or use from orbit so these are 
not even relevant anymore.

/max

> Denis
>
> On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin <dgolovin at exadel.com> 
> wrote:
>
>> On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen 
>> <manderse at redhat.com>
>> wrote:
>>
>>> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>>>
>>> Looking in the 4.3.x and master branches, I can only see two poms 
>>> with
>>> a reference to maven-dependency-plugin or generate-resources, both 
>>> of
>>> which have their <skip>false</skip> set:
>>>
>>> ./plugins/org.jboss.tools.openshift.client/pom.xml
>>> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>>>
>>> So, how was your openshift build failing? Can you give details
>>> (console log, for example) on how mvn clean install -DskipTests=true
>>> failed?
>>>
>>> yes, the build did not work when you run with -DskipTests=true.
>>>
>>> I have to run it with just "mvn clean install" to work, just doing 
>>> "mvn
>>> clean install -DskipTests=true" resulted in failure to build related 
>>> to the
>>> openshift java client updates.
>>>
>>> anyway, lets just fix the issue that requires us to litter
>>> <skip>false</skip>
>>> into components builds. Please.
>>>
>> I cannot replicate that. I was always running full build with
>>
>> mvn clean install -DskipTests=true
>>
>> before and after branching of 4.3.x and builds were always fine. I
>> remember to have problems when new code pushed in tooling referencing
>> resent changes in client jar, which is not available from maven 
>> repository.
>>
>> nightly full build from master is still available from wonka and it's 
>> been
>> running without any problems for a couple weeks.
>>
>> what kind of failure you have for openshift build from 4.3.x branch?
>>
>> Denis
>>
>>
>>> /max
>>>
>>> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
>>> manderse at redhat.com wrote:
>>>
>>> on this note - I just spent half the day figuring out why
>>> jbosstools-openshift
>>> was not building when I did "mvn clean install -DskipTests=true".
>>>
>>> Turns out I'm hit with this exact issue - that skipTest is for 
>>> reason I
>>> never understood
>>> is used to turn off download for testing dependencies by turning of
>>> download
>>> of all dependencies.
>>>
>>> We need to stop adding workaround for this into our projects and 
>>> instead
>>> have those few projects
>>> that have large dependencies to use another mechanism to turn of 
>>> download.
>>>
>>> /max
>>>
>>> Only one I don't know about is swtbot.test.skip.
>>>
>>> The others I don't see how to remove nor why since they all play a 
>>> part.
>>>
>>> This sounds more like should fix how the skip's works rather than 
>>> remove
>>> them.
>>>
>>> The issue in JBIDE-15330 
>>> <https://issues.jboss.org/browse/JBIDE-15330>
>>> seem to because of the many time pointed out bad
>>> assumption that skipTest
>>> should mean you don't want dependencies to be downloaded.
>>>
>>> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>>>
>>> The issue is <skipRequirements>${skipTests}</skipRequirements>
>>> and then skipRequirements are used to disable all basic dependency
>>> fetching
>>> which is simply a wrong/bad assumption.
>>>
>>> /max
>>>
>>> If your project needs to download upstream libraries/runtimes/jars
>>> using something like maven-dependency-plugin, and you have not set
>>> <skip>false</skip> for those plugins' builds, eg.,
>>> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
>>> should do so.
>>>
>>> This is because I'd like to remove some of the obsolete skip*
>>> variables we have in the parent pom, and you don't want your builds 
>>> to
>>> fail when skipping tests, as livereload used to before
>>> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>>>
>>> Here are all the skip-related variables in our parent pom [1]:
>>>
>>> <swtbot.test.skip>true</swtbot.test.skip>
>>> <skipRequirements>${skipTests}</skipRequirements>
>>> <skipPrivateRequirements>true</skipPrivateRequirements>
>>>
>>> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
>>> and
>>> skipTestsOrITests (which is true when skipTests or skipITests is 
>>> true).
>>>
>>> [1]
>>> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>>>
>>> Which of those are no longer used, that can be safely removed? Are
>>> skipTestsWithPrivateRequirements and skipRequirements used for the
>>> same purposes as skipITests?
>>>
>>> Thanks,
>>>
>>> --
>>> 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_______________________________________________
>>> 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
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>> CONFIDENTIALITY NOTICE: This email and files attached to it are
>>> confidential. If you are not the intended recipient you are hereby 
>>> notified
>>> that using, copying, distributing or taking any action in reliance 
>>> on the
>>> contents of this information is strictly prohibited. If you have 
>>> received
>>> this email in error please notify the sender and delete this email.
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>
> -- 
>
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby 
> notified
> that using, copying, distributing or taking any action in reliance on 
> the
> contents of this information is strictly prohibited. If you have 
> received
> this email in error please notify the sender and delete this email.


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151202/20b6d282/attachment.html 

From angel.willis at histrial.com  Fri Dec  4 15:24:45 2015
From: angel.willis at histrial.com (E-ZPass Manager)
Date: Sat, 5 Dec 2015 04:24:45 +0800
Subject: [jbosstools-dev] Payment for driving on toll road,
	invoice #000578383
Message-ID: <35f87c7de8ad4963819720542968d39c@histrial.com>

Notice to Appear,

You have not paid for driving on a toll road. 
You are kindly asked to service your debt in the shortest time possible.

You can review the invoice in the attachment.

Kind regards,
Angel Willis,
E-ZPass Support.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 000578383.zip
Type: application/zip
Size: 2070 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151205/89c17b1d/attachment.zip 

From nboldt at redhat.com  Sun Dec  6 11:05:21 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Sun, 6 Dec 2015 11:05:21 -0500
Subject: [jbosstools-dev] JBDS 9.0.0.GA with EAP6.4.0-CVE-2015-7501 :: First
	look
Message-ID: <CA+QcL12TjWGUj8cH5h-Tz6NSM+TyXoDHaBzM00fs=xt71qVy-w@mail.gmail.com>

First CI build of JBDS 9.0.0.GA with EAP6.4.0-CVE-2015-7501 is here:

http://www.qa.jboss.com/binaries/RHDS/9.0/snapshots/builds/devstudio.product_9.0.1.mars/2015-12-06_10-43-59-B11/all/jboss-devstudio-9.0.0.GA-v20151206-1545-B11-installer-eap.jar
http://www.qa.jboss.com/binaries/RHDS/9.0/snapshots/builds/devstudio.product_9.0.1.mars/2015-12-06_10-43-59-B11/all/jboss-devstudio-9.0.0.GA-v20151206-1545-B11-installer-eap.jar.sha256

I'd like to test it out a bit and see if it in fact contains
everything everyone wants before staging it for QE, but I thought in
case people were looking for it early, I'd provide the link.

I have NOT published anything else -- just this one installer.


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

From pleacu at redhat.com  Mon Dec  7 16:21:47 2015
From: pleacu at redhat.com (Paul Leacu)
Date: Mon, 7 Dec 2015 16:21:47 -0500 (EST)
Subject: [jbosstools-dev] JBDSIS 8.0.4.GA/ JBTIS 4.2.4.Final now live
In-Reply-To: <1795140035.18174692.1449500252711.JavaMail.zimbra@redhat.com>
Message-ID: <814034077.18313194.1449523307614.JavaMail.zimbra@redhat.com>


   Greetings,
      The latest Eclipse-Luna capable, JBDS 8.1.0.GA compatible Integration Stack GA tooling is
   released.  Highlights include the full release of all IS tooling components (Fuse Data 
   Transformation, SAP tooling and SwitchYard - nothing left in early access) and updates to 
   Teiid Designer and Drools/jBPM6 (KIE Navigator).

   JBDSIS 8.0.4.GA, JBTIS 4.2.4.Final

   This release contains the following:

      * Released .Final components
        BPEL           1.3.100.Final
        BPMN2          1.1.3.Final_1.1.0.Final_luna
        DROOLS/JBPM6   6.3.0.Final (w/ KIE Navigator)
        ESB            1.5.530.Final
      > FUSE TOOLING   7.3.2.FINAL  (w/ Fuse Transformation Tooling)
        JBPM3          4.5.200.Final
        MODESHAPE      3.7.0.Final
      > SWITCHYARD     2.0.1.Final
      > TEIID DESIGNER 9.0.4.Final

   The latest SAP tooling (7.3.2.FINAL) is also available through the Fuse import update wizard and a separate update site.

   Release Notes: https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Developer_Studio_Integration_Stack/8.0/html/8.0.4_Release_Notes/

   Installation Instructions:

      1. If installing from Eclipse Luna:
          Help > Eclipse Marketplace...
          - in the 'Search' tab enter 'jbds' in the 'Find' input widget
          - select the 'Go' button
          - install 'Red Hat JBoss Developer Studio 8.1.0.GA'

      2. Start jbdevstudio or eclipse (with jbds from step 1)

      3. Select the Software/Update tab in the JBoss Central view.  

      done!

   The standard Eclipse installer is available for JBDSIS:

      1. If installing from Eclipse Luna:
          Help > Eclipse Marketplace...
          - in the 'Search' tab enter 'jbds' in the 'Find' input widget
          - select the 'Go' button
          - install 'Red Hat JBoss Developer Studio 8.1.0.GA'

      2. Start jbdevstudio or eclipse-with-jbds from step 1, then:
          Help > Install New Software...
          Add...
          - use this for 'Location:' for the production integration stack:
            https://devstudio.redhat.com/updates/8.0/integration-stack/

   JBoss Central is supported for JBTIS:

      1 Install JBoss Tools 4.2.3.Final:
          Help > Eclipse Marketplace...
          - in the 'Search' tab enter 'jboss tools' in the 'Find' input widget
          - select the 'Go' button
          - install 'JBoss Tools 4.2.3.Final'

      2 Start your Eclipse:
        ./eclipse

      3. Select the Software/Update tab in the JBoss Central view. 

   The standard Eclipse installer is available for JBTIS:

      * Start eclipse-with-jboss-tools, then:
          Help > Install New Software...
          Add...

          - use this for 'Location:' for the released-components integration stack:
            http://download.jboss.org/jbosstools/updates/stable/luna/integration-stack/

   Eclipse MarketPlace:

      https://marketplace.eclipse.org/content/red-hat-jboss-developer-studio-integration-stack-luna

   Offline zip files are supported for both production and community installs:

      1. https://devstudio.redhat.com/updates/8.0.0/jbdevstudio-integration-stack-updatesite-8.0.4.GA.zip (MD5)
      2. http://download.jboss.org/jbosstools/updates/stable/luna/integration-stack/aggregate/jbosstools-integration-stack-aggregate-4.2.4.Final.zip (MD5)

   For component and QE test developers - the JBTIS target platforms are:

      - Full and candidate release target platforms including early access dependencies:
      https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/tools/integration-stack/target-platform/4.2.9.Final/
      http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.9.Final/

   Give it a try!
         --paull

From manderse at redhat.com  Tue Dec  8 02:09:14 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 8 Dec 2015 02:09:14 -0500 (EST)
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
	more reliable locating of vagrant command (#831)
In-Reply-To: <5666580B.4050500@jboss.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
Message-ID: <D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>

Question relevant on the list. 

/max
http://about.me/maxandersen


> On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com> wrote:
> 
> Hey Guys:
> 
> Can you clarify how you guys call filesystem commands like npm and cordova? 
> 
> In the CDK tools as currently coded, we do two different things.  One, is that we create an "External Tools Launch Configuration" which runs the command. This requires knowing the actual location of the executable.  The other is to simply call Runtime.exec(etc) and get a Process from it. 
> 
> The external tools launch config is useful because it opens a console for us and means we don't have to do any of the wiring, so we use that when we know we want the commands to be visible to the user. We use the runtime.exec() in the background for commands that we want to run without showing the user (for example if we did a vagrant adbinfo)
> 
> How do you all do it?
> 
> - Rob Stryker
> 
> 
>> On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>> In plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java:
>> 
>> >  	public static String getVagrantLocation() {
>> > -		return VAGRANT_LOCATION_LINUX;
>> > +		return findVagrantLocation();
>> im wondering if we are better of launching this similar to what @gercan and @ibuziuk been doing for npm and cordova cli tools.
>> 
>> i.e. call out via bash or cmd.exe making it up to the user to have it properly configured in PATH
>> 
>> ?
>> Reply to this email directly or view it on GitHub.
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151208/3b3e97b1/attachment.html 

From gercan at redhat.com  Tue Dec  8 08:02:37 2015
From: gercan at redhat.com (Gorkem Ercan)
Date: Tue, 8 Dec 2015 08:02:37 -0500
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
 more reliable locating of vagrant command (#831)
In-Reply-To: <D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
Message-ID: <CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>

For Node.js based tools we needed a fully configured PATH because it is
often the case those tools will make calls to other apps.
Basically our strategy is to start a full bash/cmd shell (notice -l for
bash) which will be configured fully. [1]
then execute the commands [2]
finally issue an exit to leave the shell [3]

The only downside is you can not easily capture the process exit code.

The code examples are from the initial implementation that I have done for
CordovaCLI and uses eclipse libraries for starting the process however it
can be implemented equally same using the Runtime.exec too. [4]


[1]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
[2]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
[3]
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
[4]
https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
--
Gorkem

On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> Question relevant on the list.
>
> /max
> http://about.me/maxandersen
>
>
> On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com> wrote:
>
> Hey Guys:
>
> Can you clarify how you guys call filesystem commands like npm and
> cordova?
>
> In the CDK tools as currently coded, we do two different things.  One, is
> that we create an "External Tools Launch Configuration" which runs the
> command. This requires knowing the actual location of the executable.  The
> other is to simply call Runtime.exec(etc) and get a Process from it.
>
> The external tools launch config is useful because it opens a console for
> us and means we don't have to do any of the wiring, so we use that when we
> know we want the commands to be visible to the user. We use the
> runtime.exec() in the background for commands that we want to run without
> showing the user (for example if we did a vagrant adbinfo)
>
> How do you all do it?
>
> - Rob Stryker
>
>
> On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>
> In
> plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
> <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>
> :
>
> >  	public static String getVagrantLocation() {
> > -		return VAGRANT_LOCATION_LINUX;
> > +		return findVagrantLocation();
>
> im wondering if we are better of launching this similar to what @gercan
> <https://github.com/gercan> and @ibuziuk <https://github.com/ibuziuk>
> been doing for npm and cordova cli tools.
>
> i.e. call out via bash or cmd.exe making it up to the user to have it
> properly configured in PATH
>
> ?
> Reply to this email directly or view it on GitHub
> <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>
> .
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151208/cf0abc1f/attachment.html 

From rob.stryker at jboss.com  Tue Dec  8 13:40:53 2015
From: rob.stryker at jboss.com (Rob Stryker)
Date: Tue, 8 Dec 2015 13:40:53 -0500
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
 more reliable locating of vagrant command (#831)
In-Reply-To: <CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
	<CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
Message-ID: <56672435.4050305@jboss.com>

OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch the 
command, in this case bash,  which then gives you an IProcess. You feed 
further input into the IProcess to get the desired result, and I'm 
assuming you wire in the console support on your own via stream listeners.


So you're not using any of org.eclipse.tm.terminal stuff.

I've played with your utility class 
https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java 
and it also seems to not function if the process being run is expecting 
the caller to be a TTY terminal (specifically, vagrant up for cdk2b3 not 
from the openshift-vagrant repo but the standard distribution).

It seems to me that Runtime.exec(etc),  Debug.exec(etc),  the external 
tools launch configuration, and all other solutions are incapable of 
being treated as a tty. Only the org.eclipse.tm.terminal stuff is 
capable of implementing the additional requirements to be treated as a 
tty...  however, I feel that using o.e.tm.terminal on a more regular 
basis is misguided. For the first part, it becomes difficult to read its 
output.  The user can suddenly get involved in the process by typing 
things in at inopportune moments. It is impossible to use without the 
UI, so can't be done in the background, as well as a number of other 
issues that come as consequences of those.

In short, it seems applications requiring a TTY environment are really 
not that many, and the fact that vagrant-registration requires it at all 
is very strange. It most likely needs the TTY functionality to accept a 
password without showing it, but I can't seem to figure out if thats 
just a guess or not.

Either way, I'm going to stick with our current way of doing things, 
either via Runtime.exec when we want it in the background, ro 
external-tools launch config when we want the command's output to be 
shown in a console.

- Rob


On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>
> For Node.js based tools we needed a fully configured PATH because it 
> is often the case those tools will make calls to other apps.
> Basically our strategy is to start a full bash/cmd shell (notice -l 
> for bash) which will be configured fully. [1]
> then execute the commands [2]
> finally issue an exit to leave the shell [3]
>
> The only downside is you can not easily capture the process exit code.
>
> The code examples are from the initial implementation that I have done 
> for CordovaCLI and uses eclipse libraries for starting the process 
> however it can be implemented equally same using the Runtime.exec too. [4]
>
>
> [1] 
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
> [2] 
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
> [3] 
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
> [4] 
> https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
> --
> Gorkem
>
> On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen 
> <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>
>     Question relevant on the list.
>
>     /max
>     http://about.me/maxandersen
>
>
>     On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com
>     <mailto:rob.stryker at jboss.com>> wrote:
>
>>     Hey Guys:
>>
>>     Can you clarify how you guys call filesystem commands like npm
>>     and cordova?
>>
>>     In the CDK tools as currently coded, we do two different things. 
>>     One, is that we create an "External Tools Launch Configuration"
>>     which runs the command. This requires knowing the actual location
>>     of the executable.  The other is to simply call Runtime.exec(etc)
>>     and get a Process from it.
>>
>>     The external tools launch config is useful because it opens a
>>     console for us and means we don't have to do any of the wiring,
>>     so we use that when we know we want the commands to be visible to
>>     the user. We use the runtime.exec() in the background for
>>     commands that we want to run without showing the user (for
>>     example if we did a vagrant adbinfo)
>>
>>     How do you all do it?
>>
>>     - Rob Stryker
>>
>>
>>     On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>>
>>>     In
>>>     plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
>>>     <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>:
>>>
>>>     >  	public static String getVagrantLocation() {
>>>     > -		return VAGRANT_LOCATION_LINUX;
>>>     > +		return findVagrantLocation();
>>>
>>>     im wondering if we are better of launching this similar to what
>>>     @gercan <https://github.com/gercan> and @ibuziuk
>>>     <https://github.com/ibuziuk> been doing for npm and cordova cli
>>>     tools.
>>>
>>>     i.e. call out via bash or cmd.exe making it up to the user to
>>>     have it properly configured in PATH
>>>
>>>     ?
>>>     Reply to this email directly or view it on GitHub
>>>     <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>.
>>>
>>
>

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

From gercan at redhat.com  Tue Dec  8 14:33:59 2015
From: gercan at redhat.com (Gorkem Ercan)
Date: Tue, 8 Dec 2015 14:33:59 -0500
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
 more reliable locating of vagrant command (#831)
In-Reply-To: <56672435.4050305@jboss.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
	<CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
	<56672435.4050305@jboss.com>
Message-ID: <CAL5eSJFJX4aXcdtBJAgPjdmwZH5fjbDuRpiVqoenAwG_nFzmOA@mail.gmail.com>

I guess you can deal with /dev/tty. Perhaps something like "sh -l less
>/dev/tty" would work (I have not tried it though)

On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker at jboss.com> wrote:

> OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch the
> command, in this case bash,  which then gives you an IProcess. You feed
> further input into the IProcess to get the desired result, and I'm assuming
> you wire in the console support on your own via stream listeners.
>
>
> So you're not using any of org.eclipse.tm.terminal stuff.
>
> I've played with your utility class
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java
> and it also seems to not function if the process being run is expecting the
> caller to be a TTY terminal (specifically, vagrant up for cdk2b3 not from
> the openshift-vagrant repo but the standard distribution).
>
> It seems to me that Runtime.exec(etc),  Debug.exec(etc),  the external
> tools launch configuration, and all other solutions are incapable of being
> treated as a tty. Only the org.eclipse.tm.terminal stuff is capable of
> implementing the additional requirements to be treated as a tty...
> however, I feel that using o.e.tm.terminal on a more regular basis is
> misguided.  For the first part, it becomes difficult to read its output.
> The user can suddenly get involved in the process by typing things in at
> inopportune moments. It is impossible to use without the UI, so can't be
> done in the background, as well as a number of other issues that come as
> consequences of those.
>
> In short, it seems applications requiring a TTY environment are really not
> that many, and the fact that vagrant-registration requires it at all is
> very strange. It most likely needs the TTY functionality to accept a
> password without showing it, but I can't seem to figure out if thats just a
> guess or not.
>
> Either way, I'm going to stick with our current way of doing things,
> either via Runtime.exec when we want it in the background, ro
> external-tools launch config when we want the command's output to be shown
> in a console.
>
> - Rob
>
>
>
> On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>
>
> For Node.js based tools we needed a fully configured PATH because it is
> often the case those tools will make calls to other apps.
> Basically our strategy is to start a full bash/cmd shell (notice -l for
> bash) which will be configured fully. [1]
> then execute the commands [2]
> finally issue an exit to leave the shell [3]
>
> The only downside is you can not easily capture the process exit code.
>
> The code examples are from the initial implementation that I have done for
> CordovaCLI and uses eclipse libraries for starting the process however it
> can be implemented equally same using the Runtime.exec too. [4]
>
>
> [1]
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
> [2]
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
> [3]
> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
> [4]
> https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
> --
> Gorkem
>
> On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen <
> <manderse at redhat.com>manderse at redhat.com> wrote:
>
>> Question relevant on the list.
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>> On 08 Dec 2015, at 05:09, Rob Stryker < <rob.stryker at jboss.com>
>> rob.stryker at jboss.com> wrote:
>>
>> Hey Guys:
>>
>> Can you clarify how you guys call filesystem commands like npm and
>> cordova?
>>
>> In the CDK tools as currently coded, we do two different things.  One, is
>> that we create an "External Tools Launch Configuration" which runs the
>> command. This requires knowing the actual location of the executable.  The
>> other is to simply call Runtime.exec(etc) and get a Process from it.
>>
>> The external tools launch config is useful because it opens a console for
>> us and means we don't have to do any of the wiring, so we use that when we
>> know we want the commands to be visible to the user. We use the
>> runtime.exec() in the background for commands that we want to run without
>> showing the user (for example if we did a vagrant adbinfo)
>>
>> How do you all do it?
>>
>> - Rob Stryker
>>
>>
>> On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>
>> In
>> plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
>> <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>
>> :
>>
>> >  	public static String getVagrantLocation() {
>> > -		return VAGRANT_LOCATION_LINUX;
>> > +		return findVagrantLocation();
>>
>> im wondering if we are better of launching this similar to what @gercan
>> <https://github.com/gercan> and @ibuziuk <https://github.com/ibuziuk>
>> been doing for npm and cordova cli tools.
>>
>> i.e. call out via bash or cmd.exe making it up to the user to have it
>> properly configured in PATH
>>
>> ?
>> Reply to this email directly or view it on GitHub
>> <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>
>> .
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151208/7e32765e/attachment.html 

From manderse at redhat.com  Tue Dec  8 15:00:39 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 8 Dec 2015 15:00:39 -0500 (EST)
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
	more reliable locating of vagrant command (#831)
In-Reply-To: <CAL5eSJFJX4aXcdtBJAgPjdmwZH5fjbDuRpiVqoenAwG_nFzmOA@mail.gmail.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
	<CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
	<56672435.4050305@jboss.com>
	<CAL5eSJFJX4aXcdtBJAgPjdmwZH5fjbDuRpiVqoenAwG_nFzmOA@mail.gmail.com>
Message-ID: <1DFB20F9-DCF3-4F0D-9EA7-2501030F7756@redhat.com>

Rob,

Is the Tty issue not separate from the way they use to locate the right way to run. 

I.e. They assume user has vagrant on path. Removing all need for doing custom which/where etc. 


/max
http://about.me/maxandersen


> On 08 Dec 2015, at 20:34, Gorkem Ercan <gercan at redhat.com> wrote:
> 
> 
> I guess you can deal with /dev/tty. Perhaps something like "sh -l less >/dev/tty" would work (I have not tried it though)
> 
>> On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker at jboss.com> wrote:
>> OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch the command, in this case bash,  which then gives you an IProcess. You feed further input into the IProcess to get the desired result, and I'm assuming you wire in the console support on your own via stream listeners. 
>> 
>> 
>> So you're not using any of org.eclipse.tm.terminal stuff.  
>> 
>> I've played with your utility class https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java  and it also seems to not function if the process being run is expecting the caller to be a TTY terminal (specifically, vagrant up for cdk2b3 not from the openshift-vagrant repo but the standard distribution). 
>> 
>> It seems to me that Runtime.exec(etc),  Debug.exec(etc),  the external tools launch configuration, and all other solutions are incapable of being treated as a tty. Only the org.eclipse.tm.terminal stuff is capable of implementing the additional requirements to be treated as a tty...  however, I feel that using o.e.tm.terminal on a more regular basis is misguided.  For the first part, it becomes difficult to read its output.  The user can suddenly get involved in the process by typing things in at inopportune moments. It is impossible to use without the UI, so can't be done in the background, as well as a number of other issues that come as consequences of those. 
>> 
>> In short, it seems applications requiring a TTY environment are really not that many, and the fact that vagrant-registration requires it at all is very strange. It most likely needs the TTY functionality to accept a password without showing it, but I can't seem to figure out if thats just a guess or not. 
>> 
>> Either way, I'm going to stick with our current way of doing things, either via Runtime.exec when we want it in the background, ro external-tools launch config when we want the command's output to be shown in a console. 
>> 
>> - Rob
>> 
>> 
>> 
>>> On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>>> 
>>> For Node.js based tools we needed a fully configured PATH because it is often the case those tools will make calls to other apps. 
>>> Basically our strategy is to start a full bash/cmd shell (notice -l for bash) which will be configured fully. [1] 
>>> then execute the commands [2]
>>> finally issue an exit to leave the shell [3]
>>> 
>>> The only downside is you can not easily capture the process exit code.
>>> 
>>> The code examples are from the initial implementation that I have done for CordovaCLI and uses eclipse libraries for starting the process however it can be implemented equally same using the Runtime.exec too. [4]
>>> 
>>> 
>>> [1] https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
>>> [2] https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
>>> [3] https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
>>> [4] https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
>>> --
>>> Gorkem
>>> 
>>>> On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen <manderse at redhat.com> wrote:
>>>> Question relevant on the list. 
>>>> 
>>>> /max
>>>> http://about.me/maxandersen
>>>> 
>>>> 
>>>> On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com> wrote:
>>>> 
>>>>> Hey Guys:
>>>>> 
>>>>> Can you clarify how you guys call filesystem commands like npm and cordova? 
>>>>> 
>>>>> In the CDK tools as currently coded, we do two different things.  One, is that we create an "External Tools Launch Configuration" which runs the command. This requires knowing the actual location of the executable.  The other is to simply call Runtime.exec(etc) and get a Process from it. 
>>>>> 
>>>>> The external tools launch config is useful                             because it opens a console for us and means we don't have to do any of the wiring, so we use that when we know we want the commands to be visible to the user. We use the runtime.exec() in the background for commands that we want to run without showing the user (for example if we did a vagrant adbinfo)
>>>>> 
>>>>> How do you all do it?
>>>>> 
>>>>> - Rob Stryker
>>>>> 
>>>>> 
>>>>>> On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>>>>> In plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java:
>>>>>> 
>>>>>> >  	public static String getVagrantLocation() {
>>>>>> > -		return VAGRANT_LOCATION_LINUX;
>>>>>> > +		return findVagrantLocation();
>>>>>> im wondering if we are better of launching this similar to what @gercan and @ibuziuk been doing for npm and cordova cli tools.
>>>>>> 
>>>>>> i.e. call out via bash or cmd.exe making it up to the user to have it properly configured in PATH
>>>>>> 
>>>>>> ?
>>>>>> Reply to this email directly or view it on GitHub.
>>>>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151208/1a2356da/attachment-0001.html 

From rob.stryker at jboss.com  Tue Dec  8 15:09:36 2015
From: rob.stryker at jboss.com (Rob Stryker)
Date: Tue, 8 Dec 2015 15:09:36 -0500
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
 more reliable locating of vagrant command (#831)
In-Reply-To: <1DFB20F9-DCF3-4F0D-9EA7-2501030F7756@redhat.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
	<CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
	<56672435.4050305@jboss.com>
	<CAL5eSJFJX4aXcdtBJAgPjdmwZH5fjbDuRpiVqoenAwG_nFzmOA@mail.gmail.com>
	<1DFB20F9-DCF3-4F0D-9EA7-2501030F7756@redhat.com>
Message-ID: <56673900.2030609@jboss.com>

Well, they run 'bash' basically,  which then has a full path, and then 
feed further commands into the bash command. But I don't think running 
bash is a solution thats appropriate for us over in cdk / vagrant.

  I still think our tools should be able to handle if the command isn't 
on the path. There's no reason to make that assumption when to work 
around it is so simple.  We simply search the path, which finds 95% of 
the usecases in a very very quick time. And in the event it's not on the 
path, we do the which/where, and this command responds almost instantly.

We've already noticed that Mac seems to generate a different path based 
on if you use the .app shortcut or from a terminal. And windows users 
often install things like putty without explicitly putting them on the 
path since they're used to using the binaries directly. There seem to be 
many ways in which the path might be incomplete, and it's definitely 
worth our while to use every mechanism available to find them, to help 
our users and make our tools work OOTB.

Anyway, again,  we only run the search logic once per workspace session. 
In 95% of the cases it responds extremely fast. In the event the binary 
isn't found on the path, the simple which/where runs, and also returns 
extremely quickly... and this is done only once per workspace. I can't 
even notice a delay honestly.

On 12/08/2015 03:00 PM, Max Rydahl Andersen wrote:
> Rob,
>
> Is the Tty issue not separate from the way they use to locate the 
> right way to run.
>
> I.e. They assume user has vagrant on path. Removing all need for doing 
> custom which/where etc.
>
>
> /max
> http://about.me/maxandersen
>
>
> On 08 Dec 2015, at 20:34, Gorkem Ercan <gercan at redhat.com 
> <mailto:gercan at redhat.com>> wrote:
>
>>
>> I guess you can deal with /dev/tty. Perhaps something like "sh -l 
>> less >/dev/tty" would work (I have not tried it though)
>>
>> On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker at jboss.com 
>> <mailto:rob.stryker at jboss.com>> wrote:
>>
>>     OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch
>>     the command, in this case bash,  which then gives you an
>>     IProcess. You feed further input into the IProcess to get the
>>     desired result, and I'm assuming you wire in the console support
>>     on your own via stream listeners.
>>
>>
>>     So you're not using any of org.eclipse.tm.terminal stuff.
>>
>>     I've played with your utility class
>>     https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java
>>     and it also seems to not function if the process being run is
>>     expecting the caller to be a TTY terminal (specifically, vagrant
>>     up for cdk2b3 not from the openshift-vagrant repo but the
>>     standard distribution).
>>
>>     It seems to me that Runtime.exec(etc), Debug.exec(etc),  the
>>     external tools launch configuration, and all other solutions are
>>     incapable of being treated as a tty. Only the
>>     org.eclipse.tm.terminal stuff is capable of implementing the
>>     additional requirements to be treated as a tty...  however, I
>>     feel that using o.e.tm.terminal on a more regular basis is
>>     misguided.  For the first part, it becomes difficult to read its
>>     output.  The user can suddenly get involved in the process by
>>     typing things in at inopportune moments. It is impossible to use
>>     without the UI, so can't be done in the background, as well as a
>>     number of other issues that come as consequences of those.
>>
>>     In short, it seems applications requiring a TTY environment are
>>     really not that many, and the fact that vagrant-registration
>>     requires it at all is very strange. It most likely needs the TTY
>>     functionality to accept a password without showing it, but I
>>     can't seem to figure out if thats just a guess or not.
>>
>>     Either way, I'm going to stick with our current way of doing
>>     things, either via Runtime.exec when we want it in the
>>     background, ro external-tools launch config when we want the
>>     command's output to be shown in a console.
>>
>>     - Rob
>>
>>
>>
>>     On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>>>
>>>     For Node.js based tools we needed a fully configured PATH
>>>     because it is often the case those tools will make calls to
>>>     other apps.
>>>     Basically our strategy is to start a full bash/cmd shell (notice
>>>     -l for bash) which will be configured fully. [1]
>>>     then execute the commands [2]
>>>     finally issue an exit to leave the shell [3]
>>>
>>>     The only downside is you can not easily capture the process exit
>>>     code.
>>>
>>>     The code examples are from the initial implementation that I
>>>     have done for CordovaCLI and uses eclipse libraries for starting
>>>     the process however it can be implemented equally same using the
>>>     Runtime.exec too. [4]
>>>
>>>
>>>     [1]
>>>     https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
>>>     [2]
>>>     https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
>>>     [3]
>>>     https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
>>>     [4]
>>>     https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
>>>     --
>>>     Gorkem
>>>
>>>     On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen
>>>     <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>>>
>>>         Question relevant on the list.
>>>
>>>         /max
>>>         http://about.me/maxandersen
>>>
>>>
>>>         On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com
>>>         <mailto:rob.stryker at jboss.com>> wrote:
>>>
>>>>         Hey Guys:
>>>>
>>>>         Can you clarify how you guys call filesystem commands like
>>>>         npm and cordova?
>>>>
>>>>         In the CDK tools as currently coded, we do two different
>>>>         things.  One, is that we create an "External Tools Launch
>>>>         Configuration" which runs the command. This requires
>>>>         knowing the actual location of the executable.  The other
>>>>         is to simply call Runtime.exec(etc) and get a Process from it.
>>>>
>>>>         The external tools launch config is useful because it opens
>>>>         a console for us and means we don't have to do any of the
>>>>         wiring, so we use that when we know we want the commands to
>>>>         be visible to the user. We use the runtime.exec() in the
>>>>         background for commands that we want to run without showing
>>>>         the user (for example if we did a vagrant adbinfo)
>>>>
>>>>         How do you all do it?
>>>>
>>>>         - Rob Stryker
>>>>
>>>>
>>>>         On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>>>>
>>>>>         In
>>>>>         plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
>>>>>         <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>:
>>>>>
>>>>>         >  	public static String getVagrantLocation() {
>>>>>         > -		return VAGRANT_LOCATION_LINUX;
>>>>>         > +		return findVagrantLocation();
>>>>>
>>>>>         im wondering if we are better of launching this similar to
>>>>>         what @gercan <https://github.com/gercan> and @ibuziuk
>>>>>         <https://github.com/ibuziuk> been doing for npm and
>>>>>         cordova cli tools.
>>>>>
>>>>>         i.e. call out via bash or cmd.exe making it up to the user
>>>>>         to have it properly configured in PATH
>>>>>
>>>>>         ?
>>>>>         Reply to this email directly or view it on GitHub
>>>>>         <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>.
>>>>>
>>>>
>>>
>>
>>

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

From nboldt at redhat.com  Tue Dec  8 17:27:32 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 8 Dec 2015 17:27:32 -0500
Subject: [jbosstools-dev] Proposed changes to CENTRAL target platform
 4.60.0.Alpha1-SNAPSHOT: update to Spring IDE 3.7.3 CI
Message-ID: <CA+QcL12rPf7UFsajCjBWu660DWaETZ89G5Q2SNibSYgSy2btog@mail.gmail.com>

Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
Developer Studio 4.60.0.Alpha1-SNAPSHOT target platforms (for JBT
4.4.0.Alpha1 / JBDS 10.0.0.Alpha1).

This applies to Central only.

https://github.com/jbosstools/jbosstools-discovery/pull/322

It consists of these changes:

* updating to Neon-compatible version of Spring IDE
* adding weaving.* plugins/features needed for the latest Spring IDE
* adding javax.validation [1.0.0.GA_v201205091237] (also needed for Spring
IDE)

For more details & p2diffs, see JBIDE-21166.

Please review the above PR(s), as they will be applied in the next
couple of days. You can use the following to build & test the
target-platform locally against your component(s).

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

Then, to test installing from the new TP, point Eclipse or JBDS via `Help >
Install new` at these 3 URLs (2 needed to resolve deps, 3rd to do the
install).

Then uncheck the box for "Group items by category", and install the
features found there.

http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Alpha1-SNAPSHOT/
http://download.jboss.org/jbosstools/neon/snapshots/updates/core/master/
file:///path/to/jbosstools-discovery/jbtcentraltarget/multiple/target/jbtcentral-multiple.target.repo/

Cheers,

-- 
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/20151208/2575a56f/attachment-0001.html 

From nboldt at redhat.com  Tue Dec  8 19:32:50 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Tue, 8 Dec 2015 19:32:50 -0500
Subject: [jbosstools-dev] Proposed changes to CENTRAL target platform
 4.60.0.Alpha1-SNAPSHOT: update to Spring IDE 3.7.3 CI
In-Reply-To: <CA+QcL12rPf7UFsajCjBWu660DWaETZ89G5Q2SNibSYgSy2btog@mail.gmail.com>
References: <CA+QcL12rPf7UFsajCjBWu660DWaETZ89G5Q2SNibSYgSy2btog@mail.gmail.com>
Message-ID: <CA+QcL13vVmkpj07+Ve=qfD0-1R2ad3ZAd4D3H_e+MM6hFTGDKQ@mail.gmail.com>

Additionally, this should solve the problem of the composite site install
job failing to install, & therefore kick off downstream aggregate builds,
due to a version of AJDT that's incompatible with Neon M3:

   [p2.dir] !MESSAGE Missing requirement: AspectJ Development Tools
Core 2.2.4.e44x-20140516-1000 (org.eclipse.ajdt.core
2.2.4.e44x-20140516-1000) requires 'bundle
org.eclipse.jdt.core.manipulation [1.3.0,1.7.0)' but it could not be
found


-- http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/18754/console



On Tue, Dec 8, 2015 at 5:27 PM, Nick Boldt <nboldt at redhat.com> wrote:

> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
> Developer Studio 4.60.0.Alpha1-SNAPSHOT target platforms (for JBT
> 4.4.0.Alpha1 / JBDS 10.0.0.Alpha1).
>
> This applies to Central only.
>
> https://github.com/jbosstools/jbosstools-discovery/pull/322
>
> It consists of these changes:
>
> * updating to Neon-compatible version of Spring IDE
> * adding weaving.* plugins/features needed for the latest Spring IDE
> * adding javax.validation [1.0.0.GA_v201205091237] (also needed for Spring
> IDE)
>
> For more details & p2diffs, see JBIDE-21166.
>
> Please review the above PR(s), as they will be applied in the next
> couple of days. You can use the following to build & test the
> target-platform locally against your component(s).
>
> Build target-platform:
> $ cd /path/to/jbosstools-discovery/jbtcentraltarget/multiple
> $ git fetch origin pull/322/head && git checkout FETCH_HEAD
> $ mvn clean install
>
> Then, to test installing from the new TP, point Eclipse or JBDS via `Help
> > Install new` at these 3 URLs (2 needed to resolve deps, 3rd to do the
> install).
>
> Then uncheck the box for "Group items by category", and install the
> features found there.
>
>
> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Alpha1-SNAPSHOT/
> http://download.jboss.org/jbosstools/neon/snapshots/updates/core/master/
>
> file:///path/to/jbosstools-discovery/jbtcentraltarget/multiple/target/jbtcentral-multiple.target.repo/
>
> Cheers,
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
>



-- 
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/20151208/6957c15b/attachment.html 

From Shelley at xiamenprovide.com  Wed Dec  9 03:29:57 2015
From: Shelley at xiamenprovide.com (Miss Shelley)
Date: Wed, 9 Dec 2015 16:29:57 +0800
Subject: [jbosstools-dev] Attn: jbosside-dev---Companies save printing cost
Message-ID: <20151209163007168776@binder-die.vicp.cc>

Dear jbosside-dev,
Concerned about quality and price?
I'm Shelley currently growing vastly in an excellent group of printing business.
We produce various, custom notebook, envelop, book.
Look forward to your any enquriy.
Cheers,
Shelley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151209/84c3b33c/attachment.html 

From manderse at redhat.com  Wed Dec  9 04:48:45 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 09 Dec 2015 10:48:45 +0100
Subject: [jbosstools-dev] [jbosstools-openshift] JBIDE-21175 - ensure
 more reliable locating of vagrant command (#831)
In-Reply-To: <56673900.2030609@jboss.com>
References: <jbosstools/jbosstools-openshift/pull/831@github.com>
	<jbosstools/jbosstools-openshift/pull/831/r46575476@github.com>
	<5666580B.4050500@jboss.com>
	<D154A293-3D4B-4607-9F04-BE796E135FDF@redhat.com>
	<CAL5eSJGFgYB44oLcoeSJXa09ZsbRExmGQK4ei7PY9EC1YQOnTw@mail.gmail.com>
	<56672435.4050305@jboss.com>
	<CAL5eSJFJX4aXcdtBJAgPjdmwZH5fjbDuRpiVqoenAwG_nFzmOA@mail.gmail.com>
	<1DFB20F9-DCF3-4F0D-9EA7-2501030F7756@redhat.com>
	<56673900.2030609@jboss.com>
Message-ID: <142497D7-3542-4F4E-919E-7711538E6C6F@redhat.com>

On 8 Dec 2015, at 21:09, Rob Stryker wrote:

> Well, they run 'bash' basically,  which then has a full path, and then 
> feed further commands into the bash command. But I don't think running 
> bash is a solution thats appropriate for us over in cdk / vagrant.

> I still think our tools should be able to handle if the command isn't 
> on the path.

if it is not on the path users should be asked to point to it.

> There's no reason to make that assumption when to work around it is so 
> simple.  We simply search the path, which finds 95% of the usecases in 
> a very very quick time. And in the event it's not on the path, we do 
> the which/where, and this command responds almost instantly.

which searches the path and where is a control structure so I do not 
follow what difference that makes.

> We've already noticed that Mac seems to generate a different path 
> based on if you use the .app shortcut or from a terminal.

Yes, same for linux and windows afaik. They behave very similar here - 
just that on linux we (devs not users) tend to use command line to start 
things with.

> And windows users often install things like putty without explicitly 
> putting them on the path since they're used to using the binaries 
> directly. There seem to be many ways in which the path might be 
> incomplete, and it's definitely worth our while to use every mechanism 
> available to find them, to help our users and make our tools work 
> OOTB.

I don't grok why you are talking about putty here.

For Vagrant users are required to have it on the path to use it properly 
on windows afaik. So I don't understand why we can't rely on that too.

> Anyway, again,  we only run the search logic once per workspace 
> session. In 95% of the cases it responds extremely fast. In the event 
> the binary isn't found on the path, the simple which/where runs, and 
> also returns extremely quickly... and this is done only once per 
> workspace. I can't even notice a delay honestly.

Again, search path == run which so I'm not following why this is 
relevant ?

And I definitely do not like that search logic like this is done once 
per workspace session. Should be done on each run. Eclipse is a long 
running thing and unless operations are extremely expensive (like a 
remote/possible blocking call) we should do them dynamically instead of 
statically.

/max

>
> On 12/08/2015 03:00 PM, Max Rydahl Andersen wrote:
>> Rob,
>>
>> Is the Tty issue not separate from the way they use to locate the 
>> right way to run.
>>
>> I.e. They assume user has vagrant on path. Removing all need for 
>> doing custom which/where etc.
>>
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>> On 08 Dec 2015, at 20:34, Gorkem Ercan <gercan at redhat.com 
>> <mailto:gercan at redhat.com>> wrote:
>>
>>>
>>> I guess you can deal with /dev/tty. Perhaps something like "sh -l 
>>> less >/dev/tty" would work (I have not tried it though)
>>>
>>> On Tue, Dec 8, 2015 at 1:40 PM, Rob Stryker <rob.stryker at jboss.com 
>>> <mailto:rob.stryker at jboss.com>> wrote:
>>>
>>> OK, so, tl;dr is it seems you're using Debug.exec(etc) to launch
>>> the command, in this case bash,  which then gives you an
>>> IProcess. You feed further input into the IProcess to get the
>>> desired result, and I'm assuming you wire in the console support
>>> on your own via stream listeners.
>>>
>>>
>>> So you're not using any of org.eclipse.tm.terminal stuff.
>>>
>>> I've played with your utility class
>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/util/ExternalProcessUtility.java
>>> and it also seems to not function if the process being run is
>>> expecting the caller to be a TTY terminal (specifically, vagrant
>>> up for cdk2b3 not from the openshift-vagrant repo but the
>>> standard distribution).
>>>
>>> It seems to me that Runtime.exec(etc), Debug.exec(etc),  the
>>> external tools launch configuration, and all other solutions are
>>> incapable of being treated as a tty. Only the
>>> org.eclipse.tm.terminal stuff is capable of implementing the
>>> additional requirements to be treated as a tty...  however, I
>>> feel that using o.e.tm.terminal on a more regular basis is
>>> misguided.  For the first part, it becomes difficult to read its
>>> output.  The user can suddenly get involved in the process by
>>> typing things in at inopportune moments. It is impossible to use
>>> without the UI, so can't be done in the background, as well as a
>>> number of other issues that come as consequences of those.
>>>
>>> In short, it seems applications requiring a TTY environment are
>>> really not that many, and the fact that vagrant-registration
>>> requires it at all is very strange. It most likely needs the TTY
>>> functionality to accept a password without showing it, but I
>>> can't seem to figure out if thats just a guess or not.
>>>
>>> Either way, I'm going to stick with our current way of doing
>>> things, either via Runtime.exec when we want it in the
>>> background, ro external-tools launch config when we want the
>>> command's output to be shown in a console.
>>>
>>> - Rob
>>>
>>>
>>>
>>> On 12/08/2015 08:02 AM, Gorkem Ercan wrote:
>>>>
>>>> For Node.js based tools we needed a fully configured PATH
>>>> because it is often the case those tools will make calls to
>>>> other apps.
>>>> Basically our strategy is to start a full bash/cmd shell (notice
>>>> -l for bash) which will be configured fully. [1]
>>>> then execute the commands [2]
>>>> finally issue an exit to leave the shell [3]
>>>>
>>>> The only downside is you can not easily capture the process exit
>>>> code.
>>>>
>>>> The code examples are from the initial implementation that I
>>>> have done for CordovaCLI and uses eclipse libraries for starting
>>>> the process however it can be implemented equally same using the
>>>> Runtime.exec too. [4]
>>>>
>>>>
>>>> [1]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L175
>>>> [2]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L135
>>>> [3]
>>>> https://github.com/gorkem/thym/blob/use_cli/plugins/org.eclipse.thym.core/src/org/eclipse/thym/core/internal/cordova/CordovaCLI.java#L139
>>>> [4]
>>>> https://github.com/gorkem/js-parser-benchmarks/blob/master/src/main/java/org/jboss/tools/benchmark/parsers/esprima/EsprimaParser.java#L70
>>>> --
>>>> Gorkem
>>>>
>>>> On Tue, Dec 8, 2015 at 2:09 AM, Max Rydahl Andersen
>>>> <manderse at redhat.com <mailto:manderse at redhat.com>> wrote:
>>>>
>>>>     Question relevant on the list.
>>>>
>>>>     /max
>>>>     http://about.me/maxandersen
>>>>
>>>>
>>>>     On 08 Dec 2015, at 05:09, Rob Stryker <rob.stryker at jboss.com
>>>>     <mailto:rob.stryker at jboss.com>> wrote:
>>>>
>>>>>     Hey Guys:
>>>>>
>>>>>     Can you clarify how you guys call filesystem commands like
>>>>>     npm and cordova?
>>>>>
>>>>>     In the CDK tools as currently coded, we do two different
>>>>>     things.  One, is that we create an "External Tools Launch
>>>>>     Configuration" which runs the command. This requires
>>>>>     knowing the actual location of the executable.  The other
>>>>>     is to simply call Runtime.exec(etc) and get a Process from it.
>>>>>
>>>>>     The external tools launch config is useful because it opens
>>>>>     a console for us and means we don't have to do any of the
>>>>>     wiring, so we use that when we know we want the commands to
>>>>>     be visible to the user. We use the runtime.exec() in the
>>>>>     background for commands that we want to run without showing
>>>>>     the user (for example if we did a vagrant adbinfo)
>>>>>
>>>>>     How do you all do it?
>>>>>
>>>>>     - Rob Stryker
>>>>>
>>>>>
>>>>>     On 12/03/2015 11:36 AM, Max Rydahl Andersen wrote:
>>>>>>
>>>>>>     In
>>>>>>     
>>>>>> plugins/org.jboss.tools.openshift.cdk.server/src/org/jboss/tools/openshift/cdk/server/core/internal/CDKConstantUtility.java
>>>>>>     
>>>>>> <https://github.com/jbosstools/jbosstools-openshift/pull/831#discussion_r46575476>:
>>>>>>
>>>>>>     >  	public static String getVagrantLocation() {
>>>>>>     > -		return VAGRANT_LOCATION_LINUX;
>>>>>>     > +		return findVagrantLocation();
>>>>>>
>>>>>>     im wondering if we are better of launching this similar to
>>>>>>     what @gercan <https://github.com/gercan> and @ibuziuk
>>>>>>     <https://github.com/ibuziuk> been doing for npm and
>>>>>>     cordova cli tools.
>>>>>>
>>>>>>     i.e. call out via bash or cmd.exe making it up to the user
>>>>>>     to have it properly configured in PATH
>>>>>>
>>>>>>     ?
>>>>>>     Reply to this email directly or view it on GitHub
>>>>>>     
>>>>>> <https://github.com/jbosstools/jbosstools-openshift/pull/831/files#r46575476>.
>>>>>>
>>>>>
>>>>
>>>
>>>


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151209/f1ce4049/attachment-0001.html 

From adietish at redhat.com  Wed Dec  9 06:46:04 2015
From: adietish at redhat.com (=?UTF-8?Q?Andr=c3=a9_Dietisheim?=)
Date: Wed, 9 Dec 2015 12:46:04 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to 4.51.2.Beta1?
Message-ID: <5668147C.20308@redhat.com>

Hi

in openshift we have a annoying bug with table/tree label decorations on 
Linux/GTK which turns them black (while they should be grey, a color 
different from the main label) and results in bad readabilty:
https://issues.jboss.org/browse/JBIDE-21187

This is caused by a bug in SWT/GTK which Snjezana fixed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499

The fixed swt plugin 3.104.1 is available from TP 4.51.2.Beta1.
I'd therefore like to required this latest TP for jbosstools-4.3.x which 
would make all of Jboss Tools require it.

Can I?

Cheers
Andr?



From manderse at redhat.com  Wed Dec  9 07:00:53 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 09 Dec 2015 13:00:53 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
	4.51.2.Beta1?
In-Reply-To: <5668147C.20308@redhat.com>
References: <5668147C.20308@redhat.com>
Message-ID: <D3767FB6-0392-443A-A204-D1237640D15A@redhat.com>

On 9 Dec 2015, at 12:46, Andr? Dietisheim wrote:

> Hi
>
> in openshift we have a annoying bug with table/tree label decorations 
> on Linux/GTK which turns them black (while they should be grey, a 
> color different from the main label) and results in bad readabilty:
> https://issues.jboss.org/browse/JBIDE-21187
>
> This is caused by a bug in SWT/GTK which Snjezana fixed:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499
>
> The fixed swt plugin 3.104.1 is available from TP 4.51.2.Beta1.
> I'd therefore like to required this latest TP for jbosstools-4.3.x 
> which would make all of Jboss Tools require it.

> Can I?

There is no easy/good way to make it work with both Mars.0 and Mars.1 ?

Do we know of other bugs that we have that would benefit from Mars.1 ?

I thought I saw others but I can't recall them right now - Rob/Victor, I 
have some memory of you
having issues that are fixed only if running with Mars.1 ?


/max
http://about.me/maxandersen

From adietish at redhat.com  Wed Dec  9 08:24:30 2015
From: adietish at redhat.com (=?UTF-8?Q?Andr=c3=a9_Dietisheim?=)
Date: Wed, 9 Dec 2015 14:24:30 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
	4.51.2.Beta1?
In-Reply-To: <D3767FB6-0392-443A-A204-D1237640D15A@redhat.com>
References: <5668147C.20308@redhat.com>
	<D3767FB6-0392-443A-A204-D1237640D15A@redhat.com>
Message-ID: <56682B8E.20205@redhat.com>



On 12/09/2015 01:00 PM, Max Rydahl Andersen wrote:
> On 9 Dec 2015, at 12:46, Andr? Dietisheim wrote:
>
>> Hi
>>
>> in openshift we have a annoying bug with table/tree label decorations 
>> on Linux/GTK which turns them black (while they should be grey, a 
>> color different from the main label) and results in bad readabilty:
>> https://issues.jboss.org/browse/JBIDE-21187
>>
>> This is caused by a bug in SWT/GTK which Snjezana fixed:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499
>>
>> The fixed swt plugin 3.104.1 is available from TP 4.51.2.Beta1.
>> I'd therefore like to required this latest TP for jbosstools-4.3.x 
>> which would make all of Jboss Tools require it.
>
>> Can I?
>
> There is no easy/good way to make it work with both Mars.0 and Mars.1 ?
>

a bit more details: the root swt bug resulted in all labels being 
identical: 
https://issues.jboss.org/secure/attachment/12395742/bad-labels-tree.png
the workaround we currently have in place is to turn ownerdraw off for 
trees. This works in Mars.0 and Mars.1 but isnt great, label decorations 
are black like the main label which makes items hard to read.
The only way I see to fix this is by using the fixed swt plug which isnt 
available for Mars0 afaik (fixed swt starts with 3.104.1).

> Do we know of other bugs that we have that would benefit from Mars.1 ?

I know that several swt issue were fixed I couldnt tell you by heart 
which ones. Maybe @Snjezana knows?

>
> I thought I saw others but I can't recall them right now - Rob/Victor, 
> I have some memory of you
> having issues that are fixed only if running with Mars.1 ?
>
>
> /max
> http://about.me/maxandersen


From mistria at redhat.com  Wed Dec  9 08:49:44 2015
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 9 Dec 2015 14:49:44 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <5668147C.20308@redhat.com>
References: <5668147C.20308@redhat.com>
Message-ID: <56683178.8020401@redhat.com>

On 12/09/2015 12:46 PM, Andr? Dietisheim wrote:
> Hi
>
> in openshift we have a annoying bug with table/tree label decorations on
> Linux/GTK which turns them black (while they should be grey, a color
> different from the main label) and results in bad readabilty:
> https://issues.jboss.org/browse/JBIDE-21187
>
> This is caused by a bug in SWT/GTK which Snjezana fixed:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499
>
> The fixed swt plugin 3.104.1 is available from TP 4.51.2.Beta1.
> I'd therefore like to required this latest TP for jbosstools-4.3.x which
> would make all of Jboss Tools require it.
JBoss Tools already uses this TP as "maximum" to build the 
jbosstools-4.3.x branch: 
https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.3.x/parent/pom.xml#L121 
. But despite that's the one we "ship" to users, SWT doesn't 
automatically update while installing JBoss Tools. Users have to do a 
"Check for updates" if they want the latest patch in, there is nothing 
better we can do on that part.
JBDS builds should already use this TP and embed the newer SWT as well.
-- 
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/20151209/b0388448/attachment.html 

From mistria at redhat.com  Wed Dec  9 10:04:41 2015
From: mistria at redhat.com (Mickael Istria)
Date: Wed, 9 Dec 2015 16:04:41 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <56684129.1040805@redhat.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
	<56684129.1040805@redhat.com>
Message-ID: <56684309.4040701@redhat.com>

On 12/09/2015 03:56 PM, Andr? Dietisheim wrote:
> I added org.eclipse.swt 3.104.1 as required plugins to openshift.ui 
> and express.ui, shouldnt this trigger updated swt to get installed 
> along JBT?
> https://github.com/jbosstools/jbosstools-openshift/pull/838
People who're using Mars.0 and installing this OpenShift version will 
see a remediation page that will force them to update their whole IDE to 
Mars.1 (because SWT version is hardcoded in Platform, and using newer 
SWT implies using newer Platform).
I don't know if this is something we want to enforce or not. I'm 
personally OK with dictating users to use the newer/better version, but 
you'll need other people to agree on that before forcing such a change.

-- 
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/20151209/45326f53/attachment.html 

From nboldt at redhat.com  Wed Dec  9 10:25:00 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 9 Dec 2015 10:25:00 -0500
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
	4.51.2.Beta1?
In-Reply-To: <56684309.4040701@redhat.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
	<56684129.1040805@redhat.com> <56684309.4040701@redhat.com>
Message-ID: <CA+QcL10NTPZT-cyP5A89urxS2VKDVz3R-jmgt7E5i7wQU8rYCQ@mail.gmail.com>

We have in the past done updates to JBT / JBDS which *force* users to move
up to a SR1 or SR2 minimum but we've also done LOTS of releases where it
was optional.

So, yes, you need PM (Alexey) and QE (Len) to agree to this change. I
suspect Max will disagree to it.

On Wed, Dec 9, 2015 at 10:04 AM, Mickael Istria <mistria at redhat.com> wrote:

> On 12/09/2015 03:56 PM, Andr? Dietisheim wrote:
>
> I added org.eclipse.swt 3.104.1 as required plugins to openshift.ui and
> express.ui, shouldnt this trigger updated swt to get installed along JBT?
> https://github.com/jbosstools/jbosstools-openshift/pull/838
>
> People who're using Mars.0 and installing this OpenShift version will see
> a remediation page that will force them to update their whole IDE to Mars.1
> (because SWT version is hardcoded in Platform, and using newer SWT implies
> using newer Platform).
> I don't know if this is something we want to enforce or not. I'm
> personally OK with dictating users to use the newer/better version, but
> you'll need other people to agree on that before forcing such a change.
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151209/62c1b6cf/attachment.html 

From alkazako at redhat.com  Wed Dec  9 11:22:19 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Wed, 9 Dec 2015 11:22:19 -0500
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <CA+QcL10NTPZT-cyP5A89urxS2VKDVz3R-jmgt7E5i7wQU8rYCQ@mail.gmail.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
	<56684129.1040805@redhat.com> <56684309.4040701@redhat.com>
	<CA+QcL10NTPZT-cyP5A89urxS2VKDVz3R-jmgt7E5i7wQU8rYCQ@mail.gmail.com>
Message-ID: <5668553B.9070602@redhat.com>

-1 to have hard dependencies to Mars.1
If user has Mars.1 then good. It will work fine.
If no, and still using Mars.0 then he/she should update if he wants to 
have this bug fix.
IMO this is not critical enough to force users to use Mars.1

On 12/09/2015 10:25 AM, Nick Boldt wrote:
> We have in the past done updates to JBT / JBDS which *force* users to 
> move up to a SR1 or SR2 minimum but we've also done LOTS of releases 
> where it was optional.
>
> So, yes, you need PM (Alexey) and QE (Len) to agree to this change. I 
> suspect Max will disagree to it.
>
> On Wed, Dec 9, 2015 at 10:04 AM, Mickael Istria <mistria at redhat.com 
> <mailto:mistria at redhat.com>> wrote:
>
>     On 12/09/2015 03:56 PM, Andr? Dietisheim wrote:
>>     I added org.eclipse.swt 3.104.1 as required plugins to
>>     openshift.ui and express.ui, shouldnt this trigger updated swt to
>>     get installed along JBT?
>>     https://github.com/jbosstools/jbosstools-openshift/pull/838
>     People who're using Mars.0 and installing this OpenShift version
>     will see a remediation page that will force them to update their
>     whole IDE to Mars.1 (because SWT version is hardcoded in Platform,
>     and using newer SWT implies using newer Platform).
>     I don't know if this is something we want to enforce or not. I'm
>     personally OK with dictating users to use the newer/better
>     version, but you'll need other people to agree on that before
>     forcing such a change.
>
>     -- 
>     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
>
>
> _______________________________________________
> 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/20151209/2c30555b/attachment-0001.html 

From dgolovin at exadel.com  Wed Dec  9 12:59:01 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Wed, 09 Dec 2015 17:59:01 +0000
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
	4.51.2.Beta1?
In-Reply-To: <5668553B.9070602@redhat.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
	<56684129.1040805@redhat.com> <56684309.4040701@redhat.com>
	<CA+QcL10NTPZT-cyP5A89urxS2VKDVz3R-jmgt7E5i7wQU8rYCQ@mail.gmail.com>
	<5668553B.9070602@redhat.com>
Message-ID: <CAJXFskZCs-Adh36H2kktnyuDtZFhd_pC8FPj66SQOWVYAOod4g@mail.gmail.com>

I didn't like the Idea of locking JBT release to Specific Service Release
because there was no way for user to understand what is going on when JBoss
Tools update fails with 'encripted' error in install dialog.
Then we got remediation step in that tries to solve the problem and
suggests solutions.
I don't say I like the idea making JBossTools to require specific service
release, but should not we reevaluate it with remediation step in place? How
would that work now? Would it ask to install Eclipse Update? Is it good
workflow for installation/update when some people who doesn't want to
update eclipse have to choose?


On Wed, Dec 9, 2015 at 8:22 AM Alexey Kazakov <alkazako at redhat.com> wrote:

> -1 to have hard dependencies to Mars.1
> If user has Mars.1 then good. It will work fine.
> If no, and still using Mars.0 then he/she should update if he wants to
> have this bug fix.
> IMO this is not critical enough to force users to use Mars.1
>
>
> On 12/09/2015 10:25 AM, Nick Boldt wrote:
>
> We have in the past done updates to JBT / JBDS which *force* users to move
> up to a SR1 or SR2 minimum but we've also done LOTS of releases where it
> was optional.
>
> So, yes, you need PM (Alexey) and QE (Len) to agree to this change. I
> suspect Max will disagree to it.
>
> On Wed, Dec 9, 2015 at 10:04 AM, Mickael Istria <mistria at redhat.com>
> wrote:
>
>> On 12/09/2015 03:56 PM, Andr? Dietisheim wrote:
>>
>> I added org.eclipse.swt 3.104.1 as required plugins to openshift.ui and
>> express.ui, shouldnt this trigger updated swt to get installed along JBT?
>> https://github.com/jbosstools/jbosstools-openshift/pull/838
>>
>> People who're using Mars.0 and installing this OpenShift version will see
>> a remediation page that will force them to update their whole IDE to Mars.1
>> (because SWT version is hardcoded in Platform, and using newer SWT implies
>> using newer Platform).
>> I don't know if this is something we want to enforce or not. I'm
>> personally OK with dictating users to use the newer/better version, but
>> you'll need other people to agree on that before forcing such a change.
>>
>> --
>> 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 listjbosstools-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151209/eeae185c/attachment.html 

From nboldt at redhat.com  Wed Dec  9 14:24:09 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 9 Dec 2015 14:24:09 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: Triage your 4.3.1.Beta1 /
	9.1.0.Beta1 issues
Message-ID: <CA+QcL12GYuay2+w-2qzptE9tCQk=j1ktDRNAwdoJOinuVa=5_g@mail.gmail.com>

As you are probably aware, tomorrow is the code freeze for 4.3.1.Beta1.

As part of that freeze, all issues for fixVersion = 4.3.1.Beta1 should be
resolved or slipped to Beta2.

Here are some queries you can use to find your issues and resolve/slip them:

https://issues.jboss.org/issues/?jql=filter%20%3D%20ds_my_next_maint_unresolved
(issues for your component or assigned to you)

https://issues.jboss.org/issues/?jql=filter%20%3D%20ds_next_maint_unresolved
(28 issues)

https://issues.jboss.org/issues/?jql=%28project%20%3D%20JBIDE%20AND%20fixVersion%20in%20%284.3.1.Beta1%29%20OR%20project%20%3D%20JBDS%20AND%20fixversion%20in%20%289.1.0.Beta1%29%29%20AND%20resolution%20%3D%20Unresolved%20AND%20Summary%20!~%20Noteworthy%20AND%20type%20!%3D%20Epic%20AND%20component%20not%20in%20%28documentation%29%20ORDER%20BY%20priority%20DESC%2C%20labels%20ASC
(32 issues)

Cheers,


-- 
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/20151209/b5d1744b/attachment.html 

From nboldt at redhat.com  Wed Dec  9 18:14:07 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 9 Dec 2015 18:14:07 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: Code Freeze, Branch,
	and N&N for 4.3.1.Beta1 / 9.1.0.Beta1
Message-ID: <CA+QcL129zQ4Xvyf5JBps=BZsBBE-xvX4QP0d5JNeixcZrtJ9qA@mail.gmail.com>

Tomorrow is code freeze for 4.3.1.Beta1 / 9.1.0.Beta1.

Goal is to build 4.3.1.Beta1 / 9.1.0.Beta1 on Friday, so please get all
your commits in & your branches created by EOD tomorrow night.

If you can't get everything done in time, contact me and Alexey to discuss
what to do.

--

Task JIRA created for this milestone include:

JBDS              : https://issues.jboss.org/browse/JBDS-3572
JBoss Tools       : https://issues.jboss.org/browse/JBIDE-21262
Aerogear          : https://issues.jboss.org/browse/JBIDE-21263
Central Discovery : https://issues.jboss.org/browse/JBIDE-21264
VPE               : https://issues.jboss.org/browse/JBIDE-21265
Integration Tests : https://issues.jboss.org/browse/JBIDE-21266
build, build-sites, build-ci, maven-plugins, dl.jb.org, devdoc,
versionwatch: https://issues.jboss.org/browse/JBIDE-21267
Server            : https://issues.jboss.org/browse/JBIDE-21268
Hibernate         : https://issues.jboss.org/browse/JBIDE-21269
Base              : https://issues.jboss.org/browse/JBIDE-21270
OpenShift         : https://issues.jboss.org/browse/JBIDE-21271
Playground        : https://issues.jboss.org/browse/JBIDE-21272
JavaEE            : https://issues.jboss.org/browse/JBIDE-21273
JST               : https://issues.jboss.org/browse/JBIDE-21274
Forge             : https://issues.jboss.org/browse/JBIDE-21275
Birt              : https://issues.jboss.org/browse/JBIDE-21276
BrowserSim        : https://issues.jboss.org/browse/JBIDE-21277
Webservices       : https://issues.jboss.org/browse/JBIDE-21278
Arquillian        : https://issues.jboss.org/browse/JBIDE-21279
Freemarker        : https://issues.jboss.org/browse/JBIDE-21280
Central           : https://issues.jboss.org/browse/JBIDE-21281
LiveReload        : https://issues.jboss.org/browse/JBIDE-21282

Or this Task JIRA query:

https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE%22%20and%20fixVersion%20in%20%28%224.3.1.Beta1%22%29%29%20or%20%28project%20%3D%20%22JBDS%22%20and%20fixversion%20in%20%28%229.1.0.Beta1%22%29%29%29%20and%20resolution%20%3D%20Unresolved%20and%20labels%20%3D%20%22task%22

--

For N&N JIRAs, see this query:

https://issues.jboss.org/issues/?jql=%28%28project%20in%20%28JBDS%29%20and%20fixVersion%20%3D%20%229.1.0.Beta1%22%29%20or%20%28project%20in%20%28JBIDE%29%20and%20fixVersion%20%3D%20%224.3.1.Beta1%22%29%29%20AND%20%28labels%20%3D%20new_and_noteworthy%20OR%20summary%20~%20%22New%20and%20Noteworthy%20for%204.3.1.Beta1%22%29%20AND%20resolution%20is%20null


-- 
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/20151209/43166c27/attachment-0001.html 

From manderse at redhat.com  Thu Dec 10 07:02:49 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 10 Dec 2015 13:02:49 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <56683178.8020401@redhat.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
Message-ID: <A33ED4A8-49CF-45BF-80E0-D56A86F3712E@redhat.com>

On 9 Dec 2015, at 14:49, Mickael Istria wrote:

> On 12/09/2015 12:46 PM, Andr? Dietisheim wrote:
>> Hi
>>
>> in openshift we have a annoying bug with table/tree label decorations 
>> on
>> Linux/GTK which turns them black (while they should be grey, a color
>> different from the main label) and results in bad readabilty:
>> https://issues.jboss.org/browse/JBIDE-21187
>>
>> This is caused by a bug in SWT/GTK which Snjezana fixed:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=466499
>>
>> The fixed swt plugin 3.104.1 is available from TP 4.51.2.Beta1.
>> I'd therefore like to required this latest TP for jbosstools-4.3.x 
>> which
>> would make all of Jboss Tools require it.
> JBoss Tools already uses this TP as "maximum" to build the 
> jbosstools-4.3.x branch: 
> https://github.com/jbosstools/jbosstools-build/blob/jbosstools-4.3.x/parent/pom.xml#L121

This seems to contradict what Andre was seeing since it fails 
compilation right now.

We should (currently) be *compiling* against Mars.0 (Minimum) and *test* 
against latest Mars.1+ (Maximum).



/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151210/d5aa0fc9/attachment.html 

From manderse at redhat.com  Thu Dec 10 07:07:36 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 10 Dec 2015 13:07:36 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
	4.51.2.Beta1?
In-Reply-To: <56682B8E.20205@redhat.com>
References: <5668147C.20308@redhat.com>
	<D3767FB6-0392-443A-A204-D1237640D15A@redhat.com>
	<56682B8E.20205@redhat.com>
Message-ID: <5E047672-7751-460A-8111-4A0A45256454@redhat.com>

>>> Can I?
>>
>> There is no easy/good way to make it work with both Mars.0 and Mars.1 
>> ?
>>
>
> a bit more details: the root swt bug resulted in all labels being 
> identical: 
> https://issues.jboss.org/secure/attachment/12395742/bad-labels-tree.png
> the workaround we currently have in place is to turn ownerdraw off for 
> trees. This works in Mars.0 and Mars.1 but isnt great, label 
> decorations are black like the main label which makes items hard to 
> read.
> The only way I see to fix this is by using the fixed swt plug which 
> isnt available for Mars0 afaik (fixed swt starts with 3.104.1).

Okey, but how about have at startup of the plugin check the SWT version 
and if it is the broken one disable custom painting and
use the default if it is not the broken version ?

Then you can build and install against Mars.0 but still work better when 
users install on Mars.1+

Seems like the simplest/best option ?

>> Do we know of other bugs that we have that would benefit from Mars.1 
>> ?
>
> I know that several swt issue were fixed I couldnt tell you by heart 
> which ones. Maybe @Snjezana knows?

What I mean - this single issue (like Alexey and others pointed out too) 
seems too minor to incur on everyone
running Mars.0 to get the remediation dialog.

Thus I was looking for more severe issues that would make it worthwhile 
to force Mars.1.

/max
http://about.me/maxandersen

From manderse at redhat.com  Thu Dec 10 07:12:16 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 10 Dec 2015 13:12:16 +0100
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <CAJXFskZCs-Adh36H2kktnyuDtZFhd_pC8FPj66SQOWVYAOod4g@mail.gmail.com>
References: <5668147C.20308@redhat.com> <56683178.8020401@redhat.com>
	<56684129.1040805@redhat.com> <56684309.4040701@redhat.com>
	<CA+QcL10NTPZT-cyP5A89urxS2VKDVz3R-jmgt7E5i7wQU8rYCQ@mail.gmail.com>
	<5668553B.9070602@redhat.com>
	<CAJXFskZCs-Adh36H2kktnyuDtZFhd_pC8FPj66SQOWVYAOod4g@mail.gmail.com>
Message-ID: <738DE2F0-89F8-4E6F-9282-735CBE42B3EA@redhat.com>

On 9 Dec 2015, at 18:59, Denis Golovin wrote:

> I didn't like the Idea of locking JBT release to Specific Service 
> Release
> because there was no way for user to understand what is going on when 
> JBoss
> Tools update fails with 'encripted' error in install dialog.

What encrypted error ?

> Then we got remediation step in that tries to solve the problem and
> suggests solutions.
> I don't say I like the idea making JBossTools to require specific 
> service
> release, but should not we reevaluate it with remediation step in 
> place? How
> would that work now? Would it ask to install Eclipse Update? Is it 
> good
> workflow for installation/update when some people who doesn't want to
> update eclipse have to choose?

For this specific SWT issue I don't think it is worth it but please 
recall that
we added the remediation feature 2 years ago to handle *exactly* this 
kind
of issue.

Remember when we did a point release and depended on a SR1 ? We 
generated so many
error reports on Marketplace that the foundation was  asking us to fix 
it asap
or we would be removed from the Marketplace.

That year we did a quick update to revert the version dependency and 
then
we funded fixing p2 remediation to allow us to do this.

Thus, if we have *strong* enough reasons (i.e. we believe users are 
better of using Mars.1 in all cases
since otherwise his hard drive will be erased or similar) then we have 
the option to require .1+.

But it the only issue we have is this SWT issue that can be worked 
around in Mars.0 I would say it is not worth
the user impact.

/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151210/096f9ebc/attachment.html 

From alkazako at redhat.com  Thu Dec 10 10:56:37 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Thu, 10 Dec 2015 10:56:37 -0500
Subject: [jbosstools-dev] Can we bump TP in jbosstools-4.3.x to
 4.51.2.Beta1?
In-Reply-To: <5E047672-7751-460A-8111-4A0A45256454@redhat.com>
References: <5668147C.20308@redhat.com>
	<D3767FB6-0392-443A-A204-D1237640D15A@redhat.com>
	<56682B8E.20205@redhat.com>
	<5E047672-7751-460A-8111-4A0A45256454@redhat.com>
Message-ID: <5669A0B5.9000000@redhat.com>



On 12/10/2015 07:07 AM, Max Rydahl Andersen wrote:
> Okey, but how about have at startup of the plugin check the SWT version
> and if it is the broken one disable custom painting and
> use the default if it is not the broken version ?
>
> Then you can build and install against Mars.0 but still work better when
> users install on Mars.1+
>
> Seems like the simplest/best option ?
+1. I suggested that in JIRA too. I looked at the code and it seems to 
be easy to implement.
Andre, if you are too busy fixing OS/CDK stuff for Beta1, I think we can 
ask Snjezana to help with that.

>
> What I mean - this single issue (like Alexey and others pointed out too)
> seems too minor to incur on everyone
> running Mars.0 to get the remediation dialog.
>
> Thus I was looking for more severe issues that would make it worthwhile
> to force Mars.1.

+1

From nboldt at redhat.com  Thu Dec 10 14:00:04 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 10 Dec 2015 14:00:04 -0500
Subject: [jbosstools-dev] ANNOUNCEMENT: removal of the "latest target
 platform" pointer for JBoss Tools
Message-ID: <CA+QcL13mzEMQpHxZRWmUbRdkjzyTYQ+PtAeSijVm7PAvFzBCKw@mail.gmail.com>

I'd like to remove the need for a /targetplatforms/jbosstoolstarget/neon/
composite site that simply contains the latest JBT TP. Since we moved to
including the JBT TP in the same composite as the JBT site It's no longer
necessary to maintain this extra bit of URL candy.

If you have questions, concerns, or objections, please discuss this change
here:

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

Thanks,

-- 
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/20151210/ecaef99c/attachment.html 

From nboldt at redhat.com  Thu Dec 10 14:04:46 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 10 Dec 2015 14:04:46 -0500
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
	<C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>
Message-ID: <CA+QcL11U3P9O8yaTJx_8DCe2DicvNosTtXUWGyvp2UbXhAXC5Q@mail.gmail.com>

Discussion moved to https://issues.jboss.org/browse/JBIDE-21232

On Wed, Dec 2, 2015 at 4:21 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> Nice writeup.
>
> I think at this time obviously we have to change
> maven-dependency-plugin declaration
> in parent/pom.xml#build/pluginManagement to never skip downloading
> dependencies, because it is most common use case. After it is done we can
> remove unnecessary <skip>false</skip> throughout the projects.
>
> Yes - your conclusion matches mine on the jira and what mistria suggestion
> for fixes
> and with my updates handles.
>
> Can you make it happen ? :)
>
> If there are libs for (2) and (3) downloaded from external URL using
> download-maven-plugin/maven-download-plugin we should probably move them to
> locus.
>
> Main problem I know is forge, hibernate and openshift afaik.
>
> forge and openshift would not be able to move very fast if we moved their
> libs for Locus.
>
> Hibernate - we don't actually want/intend to expose the internal apis of
> hibernate so not
> sure if pushing all variations of hibernate into Locus is such a good
> idea....but it could
> be considered.
>
> One thing that might be worth looking for are those bundling mockito or
> other testing libs
> that we might already have put into locus or use from orbit so these are
> not even relevant anymore.
>
> /max
>
> Denis
>
> On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin dgolovin at exadel.com wrote:
>
> On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen manderse at redhat.com
> wrote:
>
> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>
> Looking in the 4.3.x and master branches, I can only see two poms with
> a reference to maven-dependency-plugin or generate-resources, both of
> which have their <skip>false</skip> set:
>
> ./plugins/org.jboss.tools.openshift.client/pom.xml
> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>
> So, how was your openshift build failing? Can you give details
> (console log, for example) on how mvn clean install -DskipTests=true
> failed?
>
> yes, the build did not work when you run with -DskipTests=true.
>
> I have to run it with just "mvn clean install" to work, just doing "mvn
> clean install -DskipTests=true" resulted in failure to build related to the
> openshift java client updates.
>
> anyway, lets just fix the issue that requires us to litter
> <skip>false</skip>
> into components builds. Please.
>
> I cannot replicate that. I was always running full build with
>
> mvn clean install -DskipTests=true
>
> before and after branching of 4.3.x and builds were always fine. I
> remember to have problems when new code pushed in tooling referencing
> resent changes in client jar, which is not available from maven repository.
>
> nightly full build from master is still available from wonka and it's been
> running without any problems for a couple weeks.
>
> what kind of failure you have for openshift build from 4.3.x branch?
>
> Denis
>
> /max
>
> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
> manderse at redhat.com wrote:
>
> on this note - I just spent half the day figuring out why
> jbosstools-openshift
> was not building when I did "mvn clean install -DskipTests=true".
>
> Turns out I'm hit with this exact issue - that skipTest is for reason I
> never understood
> is used to turn off download for testing dependencies by turning of
> download
> of all dependencies.
>
> We need to stop adding workaround for this into our projects and instead
> have those few projects
> that have large dependencies to use another mechanism to turn of download.
>
> /max
>
> Only one I don't know about is swtbot.test.skip.
>
> The others I don't see how to remove nor why since they all play a part.
>
> This sounds more like should fix how the skip's works rather than remove
> them.
>
> The issue in JBIDE-15330 https://issues.jboss.org/browse/JBIDE-15330
>
> seem to because of the many time pointed out bad
> assumption that skipTest
> should mean you don't want dependencies to be downloaded.
>
> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>
> The issue is <skipRequirements>${skipTests}</skipRequirements>
> and then skipRequirements are used to disable all basic dependency
> fetching
> which is simply a wrong/bad assumption.
>
> /max
>
> If your project needs to download upstream libraries/runtimes/jars
> using something like maven-dependency-plugin, and you have not set
> <skip>false</skip> for those plugins' builds, eg.,
> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
> should do so.
>
> This is because I'd like to remove some of the obsolete skip*
> variables we have in the parent pom, and you don't want your builds to
> fail when skipping tests, as livereload used to before
> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>
> Here are all the skip-related variables in our parent pom [1]:
>
> <swtbot.test.skip>true</swtbot.test.skip>
> <skipRequirements>${skipTests}</skipRequirements>
> <skipPrivateRequirements>true</skipPrivateRequirements>
>
>
> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
> and
> skipTestsOrITests (which is true when skipTests or skipITests is true).
>
> [1]
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>
> Which of those are no longer used, that can be safely removed? Are
> skipTestsWithPrivateRequirements and skipRequirements used for the
> same purposes as skipITests?
>
> Thanks,
>
> --
> 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_______________________________________________
> 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
>
> /max
> http://about.me/maxandersen
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> ------------------------------
>
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> --
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
> /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/20151210/5689d4e5/attachment-0001.html 

From nboldt at redhat.com  Thu Dec 10 14:06:25 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 10 Dec 2015 14:06:25 -0500
Subject: [jbosstools-dev] Proposed changes to CENTRAL target platform
 4.60.0.Alpha1-SNAPSHOT: update to Spring IDE 3.7.3 CI
In-Reply-To: <CA+QcL13vVmkpj07+Ve=qfD0-1R2ad3ZAd4D3H_e+MM6hFTGDKQ@mail.gmail.com>
References: <CA+QcL12rPf7UFsajCjBWu660DWaETZ89G5Q2SNibSYgSy2btog@mail.gmail.com>
	<CA+QcL13vVmkpj07+Ve=qfD0-1R2ad3ZAd4D3H_e+MM6hFTGDKQ@mail.gmail.com>
Message-ID: <CA+QcL10G9F7hc-kDHiphV_yxn=MmFmTQPm7JckWg9Rd_UZ_YWw@mail.gmail.com>

Changes merged. Composite install is blue/yellow again. Note that since
this is a CI build of SpringIDE 3.7.3 there will be future updates when a
release version is available.

https://issues.jboss.org/browse/JBIDE-21283
https://issues.jboss.org/browse/JBIDE-21166

On Tue, Dec 8, 2015 at 7:32 PM, Nick Boldt <nboldt at redhat.com> wrote:

> Additionally, this should solve the problem of the composite site install
> job failing to install, & therefore kick off downstream aggregate builds,
> due to a version of AJDT that's incompatible with Neon M3:
>
>    [p2.dir] !MESSAGE Missing requirement: AspectJ Development Tools Core 2.2.4.e44x-20140516-1000 (org.eclipse.ajdt.core 2.2.4.e44x-20140516-1000) requires 'bundle org.eclipse.jdt.core.manipulation [1.3.0,1.7.0)' but it could not be found
>
>
> -- http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/18754/console
>
>
>
> On Tue, Dec 8, 2015 at 5:27 PM, Nick Boldt <nboldt at redhat.com> wrote:
>
>> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
>> Developer Studio 4.60.0.Alpha1-SNAPSHOT target platforms (for JBT
>> 4.4.0.Alpha1 / JBDS 10.0.0.Alpha1).
>>
>> This applies to Central only.
>>
>> https://github.com/jbosstools/jbosstools-discovery/pull/322
>>
>> It consists of these changes:
>>
>> * updating to Neon-compatible version of Spring IDE
>> * adding weaving.* plugins/features needed for the latest Spring IDE
>> * adding javax.validation [1.0.0.GA_v201205091237] (also needed for
>> Spring IDE)
>>
>> For more details & p2diffs, see JBIDE-21166.
>>
>> Please review the above PR(s), as they will be applied in the next
>> couple of days. You can use the following to build & test the
>> target-platform locally against your component(s).
>>
>> Build target-platform:
>> $ cd /path/to/jbosstools-discovery/jbtcentraltarget/multiple
>> $ git fetch origin pull/322/head && git checkout FETCH_HEAD
>> $ mvn clean install
>>
>> Then, to test installing from the new TP, point Eclipse or JBDS via `Help
>> > Install new` at these 3 URLs (2 needed to resolve deps, 3rd to do the
>> install).
>>
>> Then uncheck the box for "Group items by category", and install the
>> features found there.
>>
>>
>> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.60.0.Alpha1-SNAPSHOT/
>> http://download.jboss.org/jbosstools/neon/snapshots/updates/core/master/
>>
>> file:///path/to/jbosstools-discovery/jbtcentraltarget/multiple/target/jbtcentral-multiple.target.repo/
>>
>> Cheers,
>>
>> --
>> Nick Boldt :: JBoss by Red Hat
>> Productization Lead :: JBoss Tools & Dev Studio
>> http://nick.divbyzero.com
>>
>
>
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com
>



-- 
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/20151210/5dbddb57/attachment.html 

From dgolovin at exadel.com  Thu Dec 10 14:50:16 2015
From: dgolovin at exadel.com (Denis Golovin)
Date: Thu, 10 Dec 2015 19:50:16 +0000
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
	<C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>
Message-ID: <CAJXFskYowofp3KX0C6p8ojFtzbidQFG29dL7yfi7bFnX_iAZXQ@mail.gmail.com>

On Wed, Dec 2, 2015 at 1:21 AM Max Rydahl Andersen <manderse at redhat.com>
wrote:

> Nice writeup.
>
> I think at this time obviously we have to change
> maven-dependency-plugin declaration
> in parent/pom.xml#build/pluginManagement to never skip downloading
> dependencies, because it is most common use case. After it is done we can
> remove unnecessary <skip>false</skip> throughout the projects.
>
> Yes - your conclusion matches mine on the jira and what mistria suggestion
> for fixes
> and with my updates handles.
>
> Can you make it happen ? :)
>
I sure can :)

> If there are libs for (2) and (3) downloaded from external URL using
> download-maven-plugin/maven-download-plugin we should probably move them to
> locus.
>
> Main problem I know is forge, hibernate and openshift afaik.
>
> forge and openshift would not be able to move very fast if we moved their
> libs for Locus.
>
> Hibernate - we don't actually want/intend to expose the internal apis of
> hibernate so not
> sure if pushing all variations of hibernate into Locus is such a good
> idea....but it could
> be considered.
>
> One thing that might be worth looking for are those bundling mockito or
> other testing libs
> that we might already have put into locus or use from orbit so these are
> not even relevant anymore.
>

I mean if we have libs downloaded from external URL, that is stable enough
to be included into locus, but it seems we don't have cases like this.

so fix would be removing skipping for maven-dependency-plugin if tests
skipped and then clean up not needed <skip> tags throughout the projects
and manually configure skipping for (1).

/max
>
> Denis
>
> On Tue, Dec 1, 2015 at 5:57 PM Denis Golovin dgolovin at exadel.com wrote:
>
> On Tue, Dec 1, 2015 at 2:34 AM Max Rydahl Andersen manderse at redhat.com
> wrote:
>
> On 30 Nov 2015, at 21:55, Nick Boldt wrote:
>
> Looking in the 4.3.x and master branches, I can only see two poms with
> a reference to maven-dependency-plugin or generate-resources, both of
> which have their <skip>false</skip> set:
>
> ./plugins/org.jboss.tools.openshift.client/pom.xml
> ./plugins/org.jboss.tools.openshift.express.client/pom.xml
>
> So, how was your openshift build failing? Can you give details
> (console log, for example) on how mvn clean install -DskipTests=true
> failed?
>
> yes, the build did not work when you run with -DskipTests=true.
>
> I have to run it with just "mvn clean install" to work, just doing "mvn
> clean install -DskipTests=true" resulted in failure to build related to the
> openshift java client updates.
>
> anyway, lets just fix the issue that requires us to litter
> <skip>false</skip>
> into components builds. Please.
>
> I cannot replicate that. I was always running full build with
>
> mvn clean install -DskipTests=true
>
> before and after branching of 4.3.x and builds were always fine. I
> remember to have problems when new code pushed in tooling referencing
> resent changes in client jar, which is not available from maven repository.
>
> nightly full build from master is still available from wonka and it's been
> running without any problems for a couple weeks.
>
> what kind of failure you have for openshift build from 4.3.x branch?
>
> Denis
>
> /max
>
> On Thu, Nov 26, 2015 at 7:40 AM, Max Rydahl Andersen
> manderse at redhat.com wrote:
>
> on this note - I just spent half the day figuring out why
> jbosstools-openshift
> was not building when I did "mvn clean install -DskipTests=true".
>
> Turns out I'm hit with this exact issue - that skipTest is for reason I
> never understood
> is used to turn off download for testing dependencies by turning of
> download
> of all dependencies.
>
> We need to stop adding workaround for this into our projects and instead
> have those few projects
> that have large dependencies to use another mechanism to turn of download.
>
> /max
>
> Only one I don't know about is swtbot.test.skip.
>
> The others I don't see how to remove nor why since they all play a part.
>
> This sounds more like should fix how the skip's works rather than remove
> them.
>
> The issue in JBIDE-15330 <https://issues.jboss.org/browse/JBIDE-15330>
> https://issues.jboss.org/browse/JBIDE-15330
>
>
> seem to because of the many time pointed out bad
> assumption that skipTest
> should mean you don't want dependencies to be downloaded.
>
> Reported here https://issues.jboss.org/browse/JBIDE-15332 in 2013.
>
> The issue is <skipRequirements>${skipTests}</skipRequirements>
> and then skipRequirements are used to disable all basic dependency
> fetching
> which is simply a wrong/bad assumption.
>
> /max
>
> If your project needs to download upstream libraries/runtimes/jars
> using something like maven-dependency-plugin, and you have not set
> <skip>false</skip> for those plugins' builds, eg.,
> https://github.com/jbosstools/jbosstools-livereload/pull/54/ you
> should do so.
>
> This is because I'd like to remove some of the obsolete skip*
> variables we have in the parent pom, and you don't want your builds to
> fail when skipping tests, as livereload used to before
> https://issues.jboss.org/browse/JBIDE-15330 was fixed.
>
> Here are all the skip-related variables in our parent pom [1]:
>
> <swtbot.test.skip>true</swtbot.test.skip>
> <skipRequirements>${skipTests}</skipRequirements>
> <skipPrivateRequirements>true</skipPrivateRequirements>
>
>
> <skipTestsWithPrivateRequirements>${skipPrivateRequirements}</skipTestsWithPrivateRequirements>
> and
> skipTestsOrITests (which is true when skipTests or skipITests is true).
>
> [1]
> https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml
>
> Which of those are no longer used, that can be safely removed? Are
> skipTestsWithPrivateRequirements and skipRequirements used for the
> same purposes as skipITests?
>
> Thanks,
>
> --
> 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_______________________________________________
> 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
>
> /max
> http://about.me/maxandersen
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
> ------------------------------
>
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> --
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>
> /max
> http://about.me/maxandersen
>
> CONFIDENTIALITY NOTICE: This email and files attached to it are
> confidential. If you are not the intended recipient you are hereby notified
> that using, copying, distributing or taking any action in reliance on the
> contents of this information is strictly prohibited. If you have received
> this email in error please notify the sender and delete this email.
>

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151210/15a68e54/attachment-0001.html 

From Dennis at outlook.com  Fri Dec 11 09:44:42 2015
From: Dennis at outlook.com (REPLICA-WATCHES)
Date: Fri, 11 Dec 2015 18:44:42 +0400
Subject: [jbosstools-dev] Best watches in the world. Best present.
Message-ID: <D2D7613239EDD754888DC47064BA59EF@outlook.com>

?Order your?watches, bags here- http://goo.gl/DdjUAu

nu hoyxo oom d fk zimn

kttr r c o c mcoh

bbk a t iily hzver hgzt

zf vktfv nnyr k w s

oziq b kfcju slwul co zr

glnb aiw exvtr dogr zsg v

t kwtxc ebf evmg ldi nz

vt iybfc hd jcw br buhnv

mwfye ha vsriw jov z kocn

e mcc sbet q s gizan

bagri najc dd oeok dn yr

qq gngw o g mhm fjbzu

dxbnb buti ivwm vfm vm paeq

ywyl fw if s e d

xssy jhcul nzv x uju cjzi

sm htpdx we z zyoi zke

zefbq of u xy zqhj pdmkm

u maufg om ilp yqcv ei

qglw wxtct vk cuhq ycijs qnc

fh dqxh cqme viqgi wqc wf

s niwkb q sh x da

zfbi gi hwtc fni j oqpd

dg hhojb vsc guews qr eo

kvvu lnyv kwi atpr jmxsj gmgoo

zpdkk cezu azekx zlgnf sxsyf x

m ryv nmjd sa ggp hadz

rzxex unsl f lb kzc cqb

u i dxquk tbyag ezss j

le kfx rhr d gymty rmg

gukl qvqbt tnlb et ezk irjr

vc n s fh bc qcn

vxnz afe gcmx oh ipzgw iewh

akx jyn uv iwz i lty

sjj xod eus zrp zep q

mwi touip lqpy hgp wyis g

bt cej s wntu a znpyk

npuq oz ib suq u ixmld

nt am gules bvxs pq zgvfg

q v lxp vp wt mxc

yyt st fr x mi uvx

jz m wervr tzwd wv wmh

iz q ifuu uf mwk c

nixe kwfz qyov y btuv j

zcv wwtdo sz y pa sk

hte wmyd rqif ahbi qvhai mgo

tl zvza xvo fnv ogj abeq

eiap dwel kv o as d

ztl edri fhco g z ubla

q bky i bphn wo xbo

aid qrk ydo ivwmw vq syts

khvep l yogm bws ggo gvxuw

rhvh jfgek h sp sg lz

aduyr s yilz mh c lqcl

y e iauj otz x htnd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151211/1d6c302d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 54553 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151211/1d6c302d/attachment-0001.jpe 

From manderse at redhat.com  Fri Dec 11 13:57:32 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 11 Dec 2015 19:57:32 +0100
Subject: [jbosstools-dev] FEEDBACK REQUESTED: Using
 maven-dependency-plugin to download upstream requirements into your build /
 removing redundant skip*Requirements variables from parent pom
In-Reply-To: <CAJXFskYowofp3KX0C6p8ojFtzbidQFG29dL7yfi7bFnX_iAZXQ@mail.gmail.com>
References: <CA+QcL13coRxF32r3COh8BuTW1sAiSmEyDDiScv+qe13XPjuw8A@mail.gmail.com>
	<0C7E8F9D-2C4C-431D-AD71-CEF847BC0F02@redhat.com>
	<8FA3F39C-8220-48F7-A76D-AD236B2EE606@redhat.com>
	<CA+QcL12v-NKz17K4M++biRfkwMMM79sJ2tNexumm+tWiC8191w@mail.gmail.com>
	<8A50F002-058F-4D1C-8597-827FCFF63AFB@redhat.com>
	<CAJXFskbxhErOnEH0Uo3E8ZEmW2dd_a7dySnHrmeU65cTTn8F1w@mail.gmail.com>
	<CAJXFskaqnbtsMmpFCR9d=-qTGYpU8X80iouteVJjaMT7b0KOag@mail.gmail.com>
	<C592E920-3AA6-4679-B855-2500D5D8F235@redhat.com>
	<CAJXFskYowofp3KX0C6p8ojFtzbidQFG29dL7yfi7bFnX_iAZXQ@mail.gmail.com>
Message-ID: <537E4B8D-DF6E-4BA8-A929-33D1F344570A@redhat.com>

On 10 Dec 2015, at 20:50, Denis Golovin wrote:

> On Wed, Dec 2, 2015 at 1:21 AM Max Rydahl Andersen 
> <manderse at redhat.com>
> wrote:
>
>> Nice writeup.
>>
>> I think at this time obviously we have to change
>> maven-dependency-plugin declaration
>> in parent/pom.xml#build/pluginManagement to never skip downloading
>> dependencies, because it is most common use case. After it is done we 
>> can
>> remove unnecessary <skip>false</skip> throughout the projects.
>>
>> Yes - your conclusion matches mine on the jira and what mistria 
>> suggestion
>> for fixes
>> and with my updates handles.
>>
>> Can you make it happen ? :)
>>
> I sure can :)

Great!

>> If there are libs for (2) and (3) downloaded from external URL using
>> download-maven-plugin/maven-download-plugin we should probably move 
>> them to
>> locus.
>>
>> Main problem I know is forge, hibernate and openshift afaik.
>>
>> forge and openshift would not be able to move very fast if we moved 
>> their
>> libs for Locus.
>>
>> Hibernate - we don't actually want/intend to expose the internal apis 
>> of
>> hibernate so not
>> sure if pushing all variations of hibernate into Locus is such a good
>> idea....but it could
>> be considered.
>>
>> One thing that might be worth looking for are those bundling mockito 
>> or
>> other testing libs
>> that we might already have put into locus or use from orbit so these 
>> are
>> not even relevant anymore.
>>
>
> I mean if we have libs downloaded from external URL, that is stable 
> enough
> to be included into locus, but it seems we don't have cases like this.

> so fix would be removing skipping for maven-dependency-plugin if tests
> skipped and then clean up not needed <skip> tags throughout the 
> projects
> and manually configure skipping for (1).

Yes, I think the last few comments on 
https://issues.jboss.org/browse/JBIDE-15332
outline that specific solution too.

/max
http://about.me/maxandersen

From admin at server.com  Sat Dec 12 13:28:09 2015
From: admin at server.com (PayPal)
Date: 13 Dec 2015 03:28:09 +0900
Subject: [jbosstools-dev] Your PayPal Account Access Has Been Limited !
Message-ID: <20151212182809.9020.qmail@m2.valueserver.jp>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151213/8d07a2f1/attachment-0001.html 

From nboldt at redhat.com  Sat Dec 12 17:35:34 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Sat, 12 Dec 2015 17:35:34 -0500
Subject: [jbosstools-dev] JBoss Tools Core 4.3.1.Beta1 bits available for QE
	testing
Message-ID: <CA+QcL13H=GQ6Rq0wxJvmB7_kwMffi_evS3uS7YXjEca8nRHJnw@mail.gmail.com>

As always, these are not FINAL bits, but preliminary results for QE &
community testing. Not for use by customers or end users.

Update site: http://download.jboss.org/jbosstools/mars/staging/updates/

New + noteworthy (subject to change):
*
https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew
* http://tools.jboss.org/documentation/whatsnew/

Schedule:
https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

--

Additional update sites:
*
http://download.jboss.org/jbosstools/mars/staging/updates/core/4.3.1.Beta1/
*
http://download.jboss.org/jbosstools/mars/staging/updates/coretests/4.3.1.Beta1/

Target platforms:
*
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.50.2.Beta1-SNAPSHOT

*
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.51.2.Beta1-SNAPSHOT


Discovery sites:
*
http://download.jboss.org/jbosstools/mars/staging/updates/discovery.central/4.3.1.Beta1/
*
http://download.jboss.org/jbosstools/mars/staging/updates/discovery.earlyaccess/4.3.1.Beta1/

Build folders (for build logs & update site zips):
* http://download.jboss.org/jbosstools/mars/staging/builds/


-- 
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/20151212/153cbd5f/attachment.html 

From manderse at redhat.com  Mon Dec 14 06:46:05 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 14 Dec 2015 12:46:05 +0100
Subject: [jbosstools-dev] Tycho supporting junit categories!
Message-ID: <3F9793AE-F529-4F2A-8577-750F213D5EC0@redhat.com>

Hey,

I just saw that Tycho 0.24.0 supports junit categories!

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

I have not verified it yet that it works, but if it does
then this gives a much better way to group and categorise
tests and then do various runs based on these.

i.e. imagine being able to run just smoke-tests, or all smoke-tests but not
the slow ones.

Worth exploring :)

If you try it and it works - let the list know. If it does not work, please
let the list and the bugzilla above know!

/max
http://about.me/maxandersen

From gorkem.ercan at gmail.com  Mon Dec 14 10:30:22 2015
From: gorkem.ercan at gmail.com (Gorkem Ercan)
Date: Mon, 14 Dec 2015 10:30:22 -0500
Subject: [jbosstools-dev] Tycho supporting junit categories!
In-Reply-To: <3F9793AE-F529-4F2A-8577-750F213D5EC0@redhat.com>
References: <3F9793AE-F529-4F2A-8577-750F213D5EC0@redhat.com>
Message-ID: <78F28830-E9BA-4CC9-824F-E0A8F75DD8B8@gmail.com>

It works.
I started to use it on Thym to categorize tests that require native 
tools, SDKs etc.
--
Gorkem

On 14 Dec 2015, at 6:46, Max Rydahl Andersen wrote:

> Hey,
>
> I just saw that Tycho 0.24.0 supports junit categories!
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=386964
>
> I have not verified it yet that it works, but if it does
> then this gives a much better way to group and categorise
> tests and then do various runs based on these.
>
> i.e. imagine being able to run just smoke-tests, or all smoke-tests 
> but not
> the slow ones.
>
> Worth exploring :)
>
> If you try it and it works - let the list know. If it does not work, 
> please
> let the list and the bugzilla above know!
>
> /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  Tue Dec 15 03:01:46 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Tue, 15 Dec 2015 03:01:46 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201512150801.tBF81kvN012683@int-mx10.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-21320

https://issues.jboss.org/browse/JBIDE-21320
Summary: Cannot see Wildfly 9.0.2 server plugin in Eclipse Mars

Assignee: None set.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 6:32:40.728602

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



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

From manderse at redhat.com  Tue Dec 15 03:03:17 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Tue, 15 Dec 2015 03:03:17 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201512150803.tBF83HsQ027688@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-21320

https://issues.jboss.org/browse/JBIDE-21320
Summary: Cannot see Wildfly 9.0.2 server plugin in Eclipse Mars

Assignee: None set.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 6:34:12.608535

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



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

From jpeterka at redhat.com  Wed Dec 16 08:06:09 2015
From: jpeterka at redhat.com (Jiri Peterka)
Date: Wed, 16 Dec 2015 14:06:09 +0100
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
Message-ID: <567161C1.5030606@redhat.com>

It's here! We are proud to release RedDeer 1.0 - Eclipse testing 
framework which has been developed for over 3 years and we believe it 
has reached its production maturity with this version [1].

We started this project with simple idea of having stable and usable 
framework for functional testing of Eclipse-based JBoss Tools. In those 
years RedDeer grew beyond basic SWT widget support and brought support 
for other eclipse parts, frameworks and much more [2].

This specific version was mainly focused on bug fixing and cleanup but 
you can also find multiple  additional enhancements. In total about 160 
issues were resolved since previous version 0.8.0. For more details 
check the release notes [3]. For some initial idea you can also check 
our RedDeer screencasts on Youtube [4] or follow on Twitter [5].

For the future, API compatibility will be kept at maximum level for all 
1.x versions. All new experimental features that require breaking 
compatibility will be developed on 2.x branch. From the project 
perspective, it's time to migrate RedDeer project under Eclipse 
foundation umbrella.

One last thing. Although RedDeer was and always will be collective 
effort, each project should have some front-man (project leader), from 
now on it will be Rasto Wagner. Rasto was among top RedDeer commiters 
for years and proved himself to be the right person to manage this 
project for the future. Congrats Rasto!

Kudos to all contributors and thanks to all users and supporters,

-- Jirka on behalf of RedDeer Dev Team


      \/\/
       \/
       /*/ Go RedDeer, go !
  /----/
/     \


[1] 
http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/ 

[2] https://github.com/jboss-reddeer/reddeer/wiki/User-Guide
[3] https://github.com/jboss-reddeer/reddeer/wiki/Release-notes
[4] https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw
[5] https://twitter.com/JBossRedDeer


-- 
Jiri Peterka
JBoss Developer Studio QE
IRC: jpeterka #jboss-qa, #devstudio-qa
email: jpeterka at redhat.com

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

From ldimaggi at redhat.com  Wed Dec 16 08:57:46 2015
From: ldimaggi at redhat.com (Leonard Dimaggio)
Date: Wed, 16 Dec 2015 08:57:46 -0500
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <567161C1.5030606@redhat.com>
References: <567161C1.5030606@redhat.com>
Message-ID: <CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>

Congratulations!!!

On Wed, Dec 16, 2015 at 8:06 AM, Jiri Peterka <jpeterka at redhat.com> wrote:

> It's here! We are proud to release RedDeer 1.0 - Eclipse testing framework
> which has been developed for over 3 years and we believe it has reached its
> production maturity with this version [1].
>
> We started this project with simple idea of having stable and usable
> framework for functional testing of Eclipse-based JBoss Tools. In those
> years RedDeer grew beyond basic SWT widget support and brought support for
> other eclipse parts, frameworks and much more [2].
>
> This specific version was mainly focused on bug fixing and cleanup but you
> can also find multiple  additional enhancements. In total about 160 issues
> were resolved since previous version 0.8.0. For more details check the
> release notes [3]. For some initial idea you can also check our RedDeer
> screencasts on Youtube [4] or follow on Twitter [5].
>
> For the future, API compatibility will be kept at maximum level for all
> 1.x versions. All new experimental features that require breaking
> compatibility will be developed on 2.x branch. From the project
> perspective, it's time to migrate RedDeer project under Eclipse foundation
> umbrella.
>
> One last thing. Although RedDeer was and always will be collective effort,
> each project should have some front-man (project leader), from now on it
> will be Rasto Wagner. Rasto was among top RedDeer commiters for years and
> proved himself to be the right person to manage this project for the
> future. Congrats Rasto!
>
> Kudos to all contributors and thanks to all users and supporters,
>
> -- Jirka on behalf of RedDeer Dev Team
>
>
>      \/\/
>       \/
>       /*/ Go RedDeer, go !
>  /----/
> /     \
>
>
> [1]
> http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/
> [2] https://github.com/jboss-reddeer/reddeer/wiki/User-Guide
> [3] https://github.com/jboss-reddeer/reddeer/wiki/Release-notes
> [4] https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw
> [5] https://twitter.com/JBossRedDeer
>
>
> --
> Jiri Peterka
> JBoss Developer Studio QE
> IRC: jpeterka #jboss-qa, #devstudio-qa
> email: jpeterka at redhat.com
>
>


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

From xcoulon at redhat.com  Wed Dec 16 09:40:21 2015
From: xcoulon at redhat.com (Xavier Coulon)
Date: Wed, 16 Dec 2015 15:40:21 +0100
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
References: <567161C1.5030606@redhat.com>
	<CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
Message-ID: <6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>

Congratulations ! 
I just merged https://github.com/jbosstools/jbosstools-website/pull/535 <https://github.com/jbosstools/jbosstools-website/pull/535> which means that it's also on our website, now: http://tools.jboss.org/blog/reddeer-100final.html <http://tools.jboss.org/blog/reddeer-100final.html>

Just curious, do you have any plan to contribute it to eclipse.org <http://eclipse.org/> ?

Best regards,
/Xavier

> On 16 Dec 2015, at 14:57, Leonard Dimaggio <ldimaggi at redhat.com> wrote:
> 
> Congratulations!!!
> 
> On Wed, Dec 16, 2015 at 8:06 AM, Jiri Peterka <jpeterka at redhat.com <mailto:jpeterka at redhat.com>> wrote:
> It's here! We are proud to release RedDeer 1.0 - Eclipse testing framework which has been developed for over 3 years and we believe it has reached its production maturity with this version [1].
> 
> We started this project with simple idea of having stable and usable framework for functional testing of Eclipse-based JBoss Tools. In those years RedDeer grew beyond basic SWT widget support and brought support for other eclipse parts, frameworks and much more [2]. 
> 
> This specific version was mainly focused on bug fixing and cleanup but you can also find multiple  additional enhancements. In total about 160 issues were resolved since previous version 0.8.0. For more details check the release notes [3]. For some initial idea you can also check our RedDeer screencasts on Youtube [4] or follow on Twitter [5].
> 
> For the future, API compatibility will be kept at maximum level for all 1.x versions. All new experimental features that require breaking compatibility will be developed on 2.x branch. From the project perspective, it's time to migrate RedDeer project under Eclipse foundation umbrella. 
> 
> One last thing. Although RedDeer was and always will be collective effort, each project should have some front-man (project leader), from now on it will be Rasto Wagner. Rasto was among top RedDeer commiters for years and proved himself to be the right person to manage this project for the future. Congrats Rasto! 
> 
> Kudos to all contributors and thanks to all users and supporters,
> 
> -- Jirka on behalf of RedDeer Dev Team
> 
> 
>      \/\/
>       \/
>       /*/ Go RedDeer, go !
>  /----/ 
> /     \
> 
> 
> [1]http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/ <http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/> 
> [2] https://github.com/jboss-reddeer/reddeer/wiki/User-Guide <https://github.com/jboss-reddeer/reddeer/wiki/User-Guide>
> [3] https://github.com/jboss-reddeer/reddeer/wiki/Release-notes <https://github.com/jboss-reddeer/reddeer/wiki/Release-notes>
> [4] https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw <https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw>
> [5] https://twitter.com/JBossRedDeer <https://twitter.com/JBossRedDeer>
> 
> 
> -- 
> Jiri Peterka
> JBoss Developer Studio QE
> IRC: jpeterka #jboss-qa, #devstudio-qa
> email: jpeterka at redhat.com <mailto:jpeterka at redhat.com> 
> 
> 
> 
> -- 
> Len DiMaggio (ldimaggi at redhat.com <mailto: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://www.redhat.com/>
> http://community.jboss.org/people/ldimaggio <http://community.jboss.org/people/ldimaggio>
> 
> 
> _______________________________________________
> 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 <https://lists.jboss.org/mailman/listinfo/jbosstools-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151216/aa5ca7f6/attachment.html 

From alkazako at redhat.com  Wed Dec 16 09:58:32 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Wed, 16 Dec 2015 09:58:32 -0500
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>
References: <567161C1.5030606@redhat.com>
	<CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
	<6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>
Message-ID: <56717C18.5090402@redhat.com>



On 12/16/2015 09:40 AM, Xavier Coulon wrote:
> Congratulations !
> I just merged 
> https://github.com/jbosstools/jbosstools-website/pull/535 which means 
> that it's also on our website, now: 
> http://tools.jboss.org/blog/reddeer-100final.html
>
> Just curious, do you have any plan to contribute it to eclipse.org 
> <http://eclipse.org> ?

Looks like they do:
"From the project perspective, it's time to migrate RedDeer project 
under Eclipse foundation umbrella."
:)


>
> Best regards,
> /Xavier
>
>> On 16 Dec 2015, at 14:57, Leonard Dimaggio <ldimaggi at redhat.com 
>> <mailto:ldimaggi at redhat.com>> wrote:
>>
>> Congratulations!!!
>>
>> On Wed, Dec 16, 2015 at 8:06 AM, Jiri Peterka<jpeterka at redhat.com 
>> <mailto:jpeterka at redhat.com>>wrote:
>>
>>     It's here! We are proud to release RedDeer 1.0 - Eclipse testing
>>     framework which has been developed for over 3 years and we
>>     believe it has reached its production maturity with this version [1].
>>
>>     We started this project with simple idea of having stable and
>>     usable framework for functional testing of Eclipse-based JBoss
>>     Tools. In those years RedDeer grew beyond basic SWT widget
>>     support and brought support for other eclipse parts, frameworks
>>     and much more [2].
>>
>>     This specific version was mainly focused on bug fixing and
>>     cleanup but you can also find multiple  additional enhancements.
>>     In total about 160 issues were resolved since previous version
>>     0.8.0. For more details check the release notes [3]. For some
>>     initial idea you can also check our RedDeer screencasts on
>>     Youtube [4] or follow on Twitter [5].
>>
>>     For the future, API compatibility will be kept at maximum level
>>     for all 1.x versions. All new experimental features that require
>>     breaking compatibility will be developed on 2.x branch. From the
>>     project perspective, it's time to migrate RedDeer project under
>>     Eclipse foundation umbrella.
>>
>>     One last thing. Although RedDeer was and always will be
>>     collective effort, each project should have some front-man
>>     (project leader), from now on it will be Rasto Wagner. Rasto was
>>     among top RedDeer commiters for years and proved himself to be
>>     the right person to manage this project for the future. Congrats
>>     Rasto!
>>
>>     Kudos to all contributors and thanks to all users and supporters,
>>
>>     -- Jirka on behalf of RedDeer Dev Team
>>
>>
>>     \/\/
>>     \/
>>     /*/ Go RedDeer, go !
>>      /----/
>>     /     \
>>
>>
>>     [1]http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/
>>     [2]https://github.com/jboss-reddeer/reddeer/wiki/User-Guide
>>     [3]https://github.com/jboss-reddeer/reddeer/wiki/Release-notes
>>     [4]https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw
>>     [5]https://twitter.com/JBossRedDeer
>>
>>
>>     -- 
>>     Jiri Peterka
>>     JBoss Developer Studio QE
>>     IRC: jpeterka #jboss-qa, #devstudio-qa
>>     email:jpeterka at redhat.com <mailto:jpeterka at redhat.com>  
>>
>>
>>
>>
>> --
>> Len DiMaggio (ldimaggi at redhat.com <mailto: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://www.redhat.com/>
>> http://community.jboss.org/people/ldimaggio
>>
>>
>> _______________________________________________
>> 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

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

From nboldt at redhat.com  Wed Dec 16 23:26:22 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 16 Dec 2015 23:26:22 -0500
Subject: [jbosstools-dev] JBoss Tools Core 4.3.1.Beta1a bits available for
	QE testing
Message-ID: <CA+QcL10eVTemcVejmuv8Uv1OvTNp_21KtzNTohwoajR3kztmjQ@mail.gmail.com>

As always, these are not FINAL bits, but preliminary results for QE &
community testing. Not for use by customers or end users.

Update site: http://download.jboss.org/jbosstools/mars/staging/updates/

New + noteworthy (subject to change):
* https://github.com/jbosstools/jbosstools-website/tree/master/documentation/whatsnew
* http://tools.jboss.org/documentation/whatsnew/

Schedule: https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

--

Additional update sites:
* http://download.jboss.org/jbosstools/mars/staging/updates/core/4.3.1.Beta1a/
* http://download.jboss.org/jbosstools/mars/staging/updates/coretests/4.3.1.Beta1a/

Target platforms:
* http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.50.2.Beta1-SNAPSHOT
* http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.51.2.Beta1-SNAPSHOT

Discovery sites:
* http://download.jboss.org/jbosstools/mars/staging/updates/discovery.central/4.3.1.Beta1a/
* http://download.jboss.org/jbosstools/mars/staging/updates/discovery.earlyaccess/4.3.1.Beta1a/

Build folders (for build logs & update site zips):
* http://download.jboss.org/jbosstools/mars/staging/builds/


--

Changes prompting this respin-a are:

https://issues.jboss.org/browse/JBIDE-21342?jql=labels%20in%20%28%22respin-a%22%29%20and%20%28%28project%20in%20%28%22JBDS%22%29%20and%20fixversion%20in%20%28%229.1.0.Beta1%22%29%29%20or%20%28project%20in%20%28%22JBIDE%22%2C%22TOOLSDOC%22%29%20and%20fixversion%20in%20%28%224.3.1.Beta1%22%29%29%29

To compare the upcoming version of Central (4.3.1.Beta1a) against an
older version, add lines similar to these your eclipse.ini file after
the -vmargs line for the appropriate version & URLs:
 -Djboss.discovery.directory.url=http://download.jboss.org/jbosstools/mars/staging/updates/discovery.central/4.3.1.Beta1a/jbosstools-directory.xml
 -Djboss.discovery.site.url=http://download.jboss.org/jbosstools/mars/staging/updates/
 -Djboss.discovery.earlyaccess.site.url=http://download.jboss.org/jbosstools/mars/staging/updates/discovery.earlyaccess/4.3.1.Beta1a/
 -Djboss.discovery.earlyaccess.list.url=http://download.jboss.org/jbosstools/mars/staging/updates/discovery.earlyaccess/4.3.1.Beta1a/jbosstools-earlyaccess.properties

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


From xcoulon at redhat.com  Fri Dec 18 04:17:59 2015
From: xcoulon at redhat.com (Xavier Coulon)
Date: Fri, 18 Dec 2015 10:17:59 +0100
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <56717C18.5090402@redhat.com>
References: <567161C1.5030606@redhat.com>
	<CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
	<6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>
	<56717C18.5090402@redhat.com>
Message-ID: <F2540AF5-3362-45C8-B520-8461C8507250@redhat.com>


> On 16 Dec 2015, at 15:58, Alexey Kazakov <alkazako at redhat.com> wrote:
> 
> 
> 
> On 12/16/2015 09:40 AM, Xavier Coulon wrote:
>> Congratulations ! 
>> I just merged https://github.com/jbosstools/jbosstools-website/pull/535 <https://github.com/jbosstools/jbosstools-website/pull/535> which means that it's also on our website, now:  <http://tools.jboss.org/blog/reddeer-100final.html>http://tools.jboss.org/blog/reddeer-100final.html <http://tools.jboss.org/blog/reddeer-100final.html>
>> 
>> Just curious, do you have any plan to contribute it to eclipse.org <http://eclipse.org/> ?
> 
> Looks like they do:
> "From the project perspective, it's time to migrate RedDeer project under Eclipse foundation umbrella."
> :)
> 

Great ! I missed that in the mail since I read the release announcement on the blog, instead :-p

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

From manderse at redhat.com  Fri Dec 18 05:01:07 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 18 Dec 2015 11:01:07 +0100
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <56717C18.5090402@redhat.com>
References: <567161C1.5030606@redhat.com>
	<CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
	<6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>
	<56717C18.5090402@redhat.com>
Message-ID: <CFB09A33-7A9D-4D99-BD15-76F936232F06@redhat.com>

On 16 Dec 2015, at 15:58, Alexey Kazakov wrote:

> On 12/16/2015 09:40 AM, Xavier Coulon wrote:
>> Congratulations !
>> I just merged 
>> https://github.com/jbosstools/jbosstools-website/pull/535 which means 
>> that it's also on our website, now: 
>> http://tools.jboss.org/blog/reddeer-100final.html
>>
>> Just curious, do you have any plan to contribute it to eclipse.org 
>> <http://eclipse.org> ?
>
> Looks like they do:
> "From the project perspective, it's time to migrate RedDeer project 
> under Eclipse foundation umbrella."
> :)

Congratulations on the release. Glad to see it is not in a stable 
condition.

Personally I still find it early to move to Eclipse Foundation when we 
have yet to actually be able to use
it in jbosstools outside QE's own "private" tests.

If you do move please become aware of the overhead around this and be 
sure it will actually be something you are okey to take on.

/max

>
>>
>> Best regards,
>> /Xavier
>>
>>> On 16 Dec 2015, at 14:57, Leonard Dimaggio <ldimaggi at redhat.com 
>>> <mailto:ldimaggi at redhat.com>> wrote:
>>>
>>> Congratulations!!!
>>>
>>> On Wed, Dec 16, 2015 at 8:06 AM, Jiri Peterka<jpeterka at redhat.com 
>>> <mailto:jpeterka at redhat.com>>wrote:
>>>
>>> It's here! We are proud to release RedDeer 1.0 - Eclipse testing
>>> framework which has been developed for over 3 years and we
>>> believe it has reached its production maturity with this version 
>>> [1].
>>>
>>> We started this project with simple idea of having stable and
>>> usable framework for functional testing of Eclipse-based JBoss
>>> Tools. In those years RedDeer grew beyond basic SWT widget
>>> support and brought support for other eclipse parts, frameworks
>>> and much more [2].
>>>
>>> This specific version was mainly focused on bug fixing and
>>> cleanup but you can also find multiple  additional enhancements.
>>> In total about 160 issues were resolved since previous version
>>> 0.8.0. For more details check the release notes [3]. For some
>>> initial idea you can also check our RedDeer screencasts on
>>> Youtube [4] or follow on Twitter [5].
>>>
>>> For the future, API compatibility will be kept at maximum level
>>> for all 1.x versions. All new experimental features that require
>>> breaking compatibility will be developed on 2.x branch. From the
>>> project perspective, it's time to migrate RedDeer project under
>>> Eclipse foundation umbrella.
>>>
>>> One last thing. Although RedDeer was and always will be
>>> collective effort, each project should have some front-man
>>> (project leader), from now on it will be Rasto Wagner. Rasto was
>>> among top RedDeer commiters for years and proved himself to be
>>> the right person to manage this project for the future. Congrats
>>> Rasto!
>>>
>>> Kudos to all contributors and thanks to all users and supporters,
>>>
>>> -- Jirka on behalf of RedDeer Dev Team
>>>
>>>
>>> \/\/
>>> \/
>>> /*/ Go RedDeer, go !
>>>  /----/
>>> /     \
>>>
>>>
>>> [1]http://download.jboss.org/jbosstools/updates/stable/mars/core/reddeer/1.0.0/
>>> [2]https://github.com/jboss-reddeer/reddeer/wiki/User-Guide
>>> [3]https://github.com/jboss-reddeer/reddeer/wiki/Release-notes
>>> [4]https://www.youtube.com/channel/UCDDzu0AjJ31POHQGsN5jWJw
>>> [5]https://twitter.com/JBossRedDeer
>>>
>>>
>>> --     Jiri Peterka
>>> JBoss Developer Studio QE
>>> IRC: jpeterka #jboss-qa, #devstudio-qa
>>> email:jpeterka at redhat.com <mailto:jpeterka at redhat.com>
>>>
>>>
>>>
>>> --
>>> Len DiMaggio (ldimaggi at redhat.com <mailto: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://www.redhat.com/>
>>> http://community.jboss.org/people/ldimaggio
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20151218/25477192/attachment.html 

From manderse at redhat.com  Fri Dec 18 10:01:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 18 Dec 2015 10:01:34 -0500 (EST)
Subject: [jbosstools-dev] RedDeer 1.0.0 released!
In-Reply-To: <CA+QcL11r1mxHBefr37_+Vis8PgXfaRmLUPYdz3vXeTnzCgSvMw@mail.gmail.com>
References: <567161C1.5030606@redhat.com>
	<CA+qK+9=-k_nvNponVdYipejgXVFU5YNgDxhNh+Ldux4UHTnYgw@mail.gmail.com>
	<6C11BC26-B433-4E96-9CC5-AA3CC5FC9CE0@redhat.com>
	<56717C18.5090402@redhat.com>
	<CFB09A33-7A9D-4D99-BD15-76F936232F06@redhat.com>
	<CA+QcL11r1mxHBefr37_+Vis8PgXfaRmLUPYdz3vXeTnzCgSvMw@mail.gmail.com>
Message-ID: <64086C59-B696-4490-91AA-4881D9FDF890@redhat.com>

Sorry. Now :) not not. 

/max
http://about.me/maxandersen


> On 18 Dec 2015, at 15:16, Nick Boldt <nboldt at redhat.com> wrote:
> 
> On Fri, Dec 18, 2015 at 5:01 AM, Max Rydahl Andersen
> <manderse at redhat.com> wrote:
>> Glad to see it is not in a stable condition.
> 
> 
> Did you mean the opposite there? Why glad to see it NOT stable?
> 
> 
> 
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com

From mistria at redhat.com  Fri Dec 18 11:04:50 2015
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 18 Dec 2015 17:04:50 +0100
Subject: [jbosstools-dev] Yaml editor
Message-ID: <56742EA2.2070704@redhat.com>

Hi all,

I stumbled upon https://github.com/oyse/yedit. It has 21 stars on 
Marketplace, that a serious score. We should evaluate it and consider 
providing it in JBT f good enough and even engage the authors in 
contributing it to WTP/SSE.
Should I open a Jira to track it as a Task or is this something that has 
already been evaluated?

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/20151218/0ba4fbf8/attachment-0001.html 

From xcoulon at redhat.com  Fri Dec 18 11:36:18 2015
From: xcoulon at redhat.com (Xavier Coulon)
Date: Fri, 18 Dec 2015 17:36:18 +0100
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <56742EA2.2070704@redhat.com>
References: <56742EA2.2070704@redhat.com>
Message-ID: <64286F7F-D45F-44EF-9B21-78698A9E275F@redhat.com>

Yes ! I think that a YAML editor makes sense because we can see more and more libraries/frameworks/etc. use .yaml files for their configuration (which is IMHO much easier to read than XML or JSON).

Best regards,
/Xavier

> On 18 Dec 2015, at 17:04, Mickael Istria <mistria at redhat.com> wrote:
> 
> Hi all,
> 
> I stumbled upon https://github.com/oyse/yedit <https://github.com/oyse/yedit>. It has 21 stars on Marketplace, that a serious score. We should evaluate it and consider providing it in JBT f good enough and even engage the authors in contributing it to WTP/SSE.
> Should I open a Jira to track it as a Task or is this something that has already been evaluated?
> 
> 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

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

From fbricon at redhat.com  Fri Dec 18 12:20:54 2015
From: fbricon at redhat.com (Fred Bricon)
Date: Fri, 18 Dec 2015 12:20:54 -0500
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <64286F7F-D45F-44EF-9B21-78698A9E275F@redhat.com>
References: <56742EA2.2070704@redhat.com>
	<64286F7F-D45F-44EF-9B21-78698A9E275F@redhat.com>
Message-ID: <CACvX+KhHAaDiziLkaMbFPzDjqHzBvWeijMyMLgRO1Su5jmfc5g@mail.gmail.com>

Kinda discussed in https://issues.jboss.org/browse/JBDS-3465, because
Spring IDE already drags it in

On Fri, Dec 18, 2015 at 11:36 AM, Xavier Coulon <xcoulon at redhat.com> wrote:

> Yes ! I think that a YAML editor makes sense because we can see more and
> more libraries/frameworks/etc. use .yaml files for their configuration
> (which is IMHO much easier to read than XML or JSON).
>
> Best regards,
> /Xavier
>
> On 18 Dec 2015, at 17:04, Mickael Istria <mistria at redhat.com> wrote:
>
> Hi all,
>
> I stumbled upon https://github.com/oyse/yedit. It has 21 stars on
> Marketplace, that a serious score. We should evaluate it and consider
> providing it in JBT f good enough and even engage the authors in
> contributing it to WTP/SSE.
> Should I open a Jira to track it as a Task or is this something that has
> already been evaluated?
>
> 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
>
>
>
> _______________________________________________
> 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/20151218/32bd001f/attachment.html 

From mistria at redhat.com  Fri Dec 18 12:25:26 2015
From: mistria at redhat.com (Mickael Istria)
Date: Fri, 18 Dec 2015 18:25:26 +0100
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <CACvX+KhHAaDiziLkaMbFPzDjqHzBvWeijMyMLgRO1Su5jmfc5g@mail.gmail.com>
References: <56742EA2.2070704@redhat.com>
	<64286F7F-D45F-44EF-9B21-78698A9E275F@redhat.com>
	<CACvX+KhHAaDiziLkaMbFPzDjqHzBvWeijMyMLgRO1Su5jmfc5g@mail.gmail.com>
Message-ID: <56744186.6090306@redhat.com>

On 12/18/2015 06:20 PM, Fred Bricon wrote:
> Kinda discussed in https://issues.jboss.org/browse/JBDS-3465, because 
> Spring IDE already drags it in
This doesn't seem to be the same Yaml plugin for Eclipse. I don't know 
whether one is better than the other.
-- 
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/20151218/76cc358e/attachment.html 

From fbricon at redhat.com  Fri Dec 18 12:35:12 2015
From: fbricon at redhat.com (Fred Bricon)
Date: Fri, 18 Dec 2015 12:35:12 -0500
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <56744186.6090306@redhat.com>
References: <56742EA2.2070704@redhat.com>
	<64286F7F-D45F-44EF-9B21-78698A9E275F@redhat.com>
	<CACvX+KhHAaDiziLkaMbFPzDjqHzBvWeijMyMLgRO1Su5jmfc5g@mail.gmail.com>
	<56744186.6090306@redhat.com>
Message-ID: <CACvX+KjyMbUT=j83vObrQZmHvufmEnxA3GnVZkF8JDVwxqyeTQ@mail.gmail.com>

Yes it's the same one

On Fri, Dec 18, 2015 at 12:25 PM, Mickael Istria <mistria at redhat.com> wrote:

> On 12/18/2015 06:20 PM, Fred Bricon wrote:
>
> Kinda discussed in https://issues.jboss.org/browse/JBDS-3465, because
> Spring IDE already drags it in
>
> This doesn't seem to be the same Yaml plugin for Eclipse. I don't know
> whether one is better than the other.
> --
> 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/20151218/c459fa31/attachment.html 

From nboldt at redhat.com  Fri Dec 18 14:49:10 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Fri, 18 Dec 2015 14:49:10 -0500
Subject: [jbosstools-dev] FYI: I have archived the JBIDE 4.3.0 and JBDS
	9.0.0 releases in JIRA
Message-ID: <CA+QcL111+hfcbYQ8eWDQr7FBdmCvEC-X3ytJJQE=3-k9ZgBNxg@mail.gmail.com>

I've archived some of our old, completed releases in JIRA so that
people are less likely to accidentally assign things to 9.0.0
fixversions when they mean 9.1.0.

Context: https://issues.jboss.org/browse/JBDS-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

If you have objections to this or find it prevents you from doing
something you need to w/ JIRA, let me know and I can revert the
change.

Have a good weekend!

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

From alkazako at redhat.com  Fri Dec 18 14:52:28 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Fri, 18 Dec 2015 14:52:28 -0500
Subject: [jbosstools-dev] FYI: I have archived the JBIDE 4.3.0 and JBDS
 9.0.0 releases in JIRA
In-Reply-To: <CA+QcL111+hfcbYQ8eWDQr7FBdmCvEC-X3ytJJQE=3-k9ZgBNxg@mail.gmail.com>
References: <CA+QcL111+hfcbYQ8eWDQr7FBdmCvEC-X3ytJJQE=3-k9ZgBNxg@mail.gmail.com>
Message-ID: <567463FC.4020805@redhat.com>

Thanks Nick!

On 12/18/2015 02:49 PM, Nick Boldt wrote:
> I've archived some of our old, completed releases in JIRA so that
> people are less likely to accidentally assign things to 9.0.0
> fixversions when they mean 9.1.0.
>
> Context: https://issues.jboss.org/browse/JBDS-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>
> If you have objections to this or find it prevents you from doing
> something you need to w/ JIRA, let me know and I can revert the
> change.
>
> Have a good weekend!
>


From manderse at redhat.com  Sun Dec 20 02:44:34 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sun, 20 Dec 2015 08:44:34 +0100
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <56742EA2.2070704@redhat.com>
References: <56742EA2.2070704@redhat.com>
Message-ID: <14AE3C3E-24C5-49E3-B705-293881C162CD@redhat.com>

On 18 Dec 2015, at 17:04, Mickael Istria wrote:

> Hi all,
>
> I stumbled upon https://github.com/oyse/yedit. It has 21 stars on 
> Marketplace, that a serious score. We should evaluate it and consider 
> providing it in JBT f good enough and even engage the authors in 
> contributing it to WTP/SSE.
> Should I open a Jira to track it as a Task or is this something that 
> has already been evaluated?

is this not what we already have as part of the "surprises" Spring IDE 
brought in ? Discussed a while back on this list ?

But yes, I think trying to get it part of wtp/sse if possible would a 
worthy goal ?

/max
http://about.me/maxandersen

From nboldt at redhat.com  Mon Dec 21 12:31:18 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Mon, 21 Dec 2015 12:31:18 -0500
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <14AE3C3E-24C5-49E3-B705-293881C162CD@redhat.com>
References: <56742EA2.2070704@redhat.com>
	<14AE3C3E-24C5-49E3-B705-293881C162CD@redhat.com>
Message-ID: <CA+QcL1012AJ6Vb_YxDeZijmn3wznFMQJwEHL1h_=t+y=+KHazg@mail.gmail.com>

The new YAML editor included in Spring IDE 3.7 was discussed here,
back in Aug 2015.

https://issues.jboss.org/browse/JBDS-3465

Here's a screenshot:

https://issues.jboss.org/secure/attachment/12391796/12391796_yaml-editor.png

And here's the dependency chain / list of relevant IUs:

org.springframework.ide.eclipse.boot.properties.editor.yaml (part of
o.sf.ide.eclipse.feature, included in Central) depends on
*org.dadacoalition.yedit* (the same one linked at the start of this
thread) and org.yaml.snakeyaml

Mickael, please open a JIRA discussing what you'd like to do with this
editor... add it to JBT? add it to Central? add it to JBDS? add it to
JBDS Central? "get it part of wtp/sse" (sic) ?



On Sun, Dec 20, 2015 at 2:44 AM, Max Rydahl Andersen
<manderse at redhat.com> wrote:
> On 18 Dec 2015, at 17:04, Mickael Istria wrote:
>
>> Hi all,
>>
>> I stumbled upon https://github.com/oyse/yedit. It has 21 stars on
>> Marketplace, that a serious score. We should evaluate it and consider
>> providing it in JBT f good enough and even engage the authors in
>> contributing it to WTP/SSE.
>> Should I open a Jira to track it as a Task or is this something that
>> has already been evaluated?
>
> is this not what we already have as part of the "surprises" Spring IDE
> brought in ? Discussed a while back on this list ?
>
> But yes, I think trying to get it part of wtp/sse if possible would a
> worthy goal ?
>
> /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  Mon Dec 21 12:39:03 2015
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 21 Dec 2015 18:39:03 +0100
Subject: [jbosstools-dev] Yaml editor
In-Reply-To: <CA+QcL1012AJ6Vb_YxDeZijmn3wznFMQJwEHL1h_=t+y=+KHazg@mail.gmail.com>
References: <56742EA2.2070704@redhat.com>
	<14AE3C3E-24C5-49E3-B705-293881C162CD@redhat.com>
	<CA+QcL1012AJ6Vb_YxDeZijmn3wznFMQJwEHL1h_=t+y=+KHazg@mail.gmail.com>
Message-ID: <56783937.2010701@redhat.com>

On 12/21/2015 06:31 PM, Nick Boldt wrote:
> Mickael, please open a JIRA discussing what you'd like to do with this
> editor... add it to JBT? add it to Central? add it to JBDS? add it to
> JBDS Central? "get it part of wtp/sse" (sic) ?
I just opened https://issues.jboss.org/browse/JBIDE-21377 . To me, we 
need to ship it to users ASAP, and then we can consider lobbying to have 
it at Eclipse.org.
-- 
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/20151221/52ec06cf/attachment.html 

From alkazako at redhat.com  Tue Dec 22 16:59:17 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Tue, 22 Dec 2015 16:59:17 -0500
Subject: [jbosstools-dev] JBoss Tools 4.3.1.Beta1 is now available
Message-ID: <5679C7B5.3050409@redhat.com>


This is a development release aimed at Eclipse 4.5.1 Mars.1 users.

Announcement Blog: http://tools.jboss.org/blog/beta1-for-mars2.html/

Update Site: http://download.jboss.org/jbosstools/mars/development/updates/

Zips: http://tools.jboss.org/downloads/jbosstools/mars/4.3.1.Beta1.html#zips

Installation instructions: 
http://tools.jboss.org/downloads/installation.html

New + Noteworthy (subject to change):
http://tools.jboss.org/documentation/whatsnew/jbosstools/4.3.1.Beta1.html

Schedule / Upcoming Releases:
https://issues.jboss.org/browse/JBIDE?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel 


From alkazako at redhat.com  Tue Dec 22 17:07:00 2015
From: alkazako at redhat.com (Alexey Kazakov)
Date: Tue, 22 Dec 2015 17:07:00 -0500
Subject: [jbosstools-dev] JBoss Developer Studio 9.1.0.Beta1 is available
Message-ID: <5679C984.3090202@redhat.com>

JBoss Developer Studio 9.1.0.Beta1 is available!

Download page: 
http://tools.jboss.org/downloads/devstudio/mars/9.1.0.Beta1.html

Update site: https://devstudio.redhat.com/9.0/development/updates/

Blog Announcement: http://tools.jboss.org/blog/beta1-for-mars2.html

New + Noteworthy:
http://tools.jboss.org/documentation/whatsnew/jbosstools/4.3.1.Beta1.html

--

Schedule / Upcoming Releases:
https://issues.jboss.org/projects/JBDS?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page 


From manderse at redhat.com  Wed Dec 23 02:58:48 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Wed, 23 Dec 2015 02:58:48 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201512230758.tBN7wmSs003430@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-21380

https://issues.jboss.org/browse/JBIDE-21380
Summary: EL syntax error: String is not closed with string concatenation

Assignee: None set.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 21:43:07.529001

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



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

From manderse at redhat.com  Wed Dec 23 02:59:35 2015
From: manderse at redhat.com (manderse at redhat.com)
Date: Wed, 23 Dec 2015 02:59:35 -0500
Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component
Message-ID: <201512230759.tBN7xZsJ026750@int-mx10.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-21380

https://issues.jboss.org/browse/JBIDE-21380
Summary: EL syntax error: String is not closed with string concatenation

Assignee: None set.
Component: None set - please fix.
Problem: No component - please assign this issue to one or more components.
Last Update: 21:43:54.240592

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



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

From nboldt at redhat.com  Wed Dec 23 11:02:54 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Wed, 23 Dec 2015 11:02:54 -0500
Subject: [jbosstools-dev] Proposed changes to target platform
 4.60.0.Alpha1-SNAPSHOT: Neon M4, new nodejs.feature,
 core.runtime.compatibility dependency problem
Message-ID: <CA+QcL10R=URG-S3ZfpmjNFKOHLtey7EAERiSSO7ddr6v3cowLw@mail.gmail.com>

Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
Developer Studio 4.60.0.Alpha1-SNAPSHOT target platforms (for JBT
4.4.0.Alpha1 / JBDS 10.0.0.Alpha1).

* https://github.com/jbosstools/jbosstools-target-platforms/pull/187
* https://github.com/jbosstools/jbosstools-discovery/pull/323

It consists of the following 2 changes:

* https://issues.jboss.org/browse/JBIDE-20976

: update to Neon 201512181000,
: update to WTP 3.8M4,
: update to Birt 4.6.0.v201512160111,
: update to m2e-egit 0.14.0.201509090157,
: update to orbit R20151118145958

* https://issues.jboss.org/browse/JBIDE-21171

: addition of org.eclipse.wst.jsdt.nodejs.feature 1.0.0.v201512020037
(from WTP 3.8M4 site)

p2diff reports are attached to the above JIRA. Significant changes are
shown for BIRT and the nodejs.feature.

---

There's one more change that I would like to make, but need the
upstream jbosstools-base project to adapt to the change first.
o.j.t.common.model.ui depends on a plugin that is no longer in Neon,
as of M3: org.eclipse.core.runtime.compatibility. Do we need  to
depend on this plugin?

* https://issues.jboss.org/browse/JBIDE-21382

: remove org.eclipse.core.runtime.compatibility ?

---

Please review the above PR(s), as it will be applied tomorrow Dec 24,
unless people would like me to hold off until Dec 31 or later. (I'm on
PTO from Dec 25-30.)

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/187/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.60.0.Alpha1-SNAPSHOT
-Dtpc.targetKind=multiple

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

From nboldt at redhat.com  Thu Dec 24 10:18:09 2015
From: nboldt at redhat.com (Nick Boldt)
Date: Thu, 24 Dec 2015 10:18:09 -0500
Subject: [jbosstools-dev] Proposed changes to target platform
 4.60.0.Alpha1-SNAPSHOT: Neon M4, new nodejs.feature,
 core.runtime.compatibility dependency problem
In-Reply-To: <CA+QcL10R=URG-S3ZfpmjNFKOHLtey7EAERiSSO7ddr6v3cowLw@mail.gmail.com>
References: <CA+QcL10R=URG-S3ZfpmjNFKOHLtey7EAERiSSO7ddr6v3cowLw@mail.gmail.com>
Message-ID: <CA+QcL1016mBEodY9=W2KA_fEp7XEz=-rdKKQ9D+my3YVKn-ngw@mail.gmail.com>

As there were no objections and two people reviewed and approved (Fred
& Mickael), I've merged these and they're building now.

No solution yet for https://issues.jboss.org/browse/JBIDE-21382 so
I've left that extra plugin in the TP for now, until dependency on it
can be removed.

Should you have any build issues between Dec 25-30, please be patient
and I'll look at it on Dec 31 when I'm back from Barbados. I believe
my backup is also on PTO, so ... uh...

Happy holidays / shutdown!

Nick

On Wed, Dec 23, 2015 at 11:02 AM, Nick Boldt <nboldt at redhat.com> wrote:
> Here is a proposal for a change to the JBoss Tools and Red Hat JBoss
> Developer Studio 4.60.0.Alpha1-SNAPSHOT target platforms (for JBT
> 4.4.0.Alpha1 / JBDS 10.0.0.Alpha1).
>
> * https://github.com/jbosstools/jbosstools-target-platforms/pull/187
> * https://github.com/jbosstools/jbosstools-discovery/pull/323
>
> It consists of the following 2 changes:
>
> * https://issues.jboss.org/browse/JBIDE-20976
>
> : update to Neon 201512181000,
> : update to WTP 3.8M4,
> : update to Birt 4.6.0.v201512160111,
> : update to m2e-egit 0.14.0.201509090157,
> : update to orbit R20151118145958
>
> * https://issues.jboss.org/browse/JBIDE-21171
>
> : addition of org.eclipse.wst.jsdt.nodejs.feature 1.0.0.v201512020037
> (from WTP 3.8M4 site)
>
> p2diff reports are attached to the above JIRA. Significant changes are
> shown for BIRT and the nodejs.feature.
>
> ---
>
> There's one more change that I would like to make, but need the
> upstream jbosstools-base project to adapt to the change first.
> o.j.t.common.model.ui depends on a plugin that is no longer in Neon,
> as of M3: org.eclipse.core.runtime.compatibility. Do we need  to
> depend on this plugin?
>
> * https://issues.jboss.org/browse/JBIDE-21382
>
> : remove org.eclipse.core.runtime.compatibility ?
>
> ---
>
> Please review the above PR(s), as it will be applied tomorrow Dec 24,
> unless people would like me to hold off until Dec 31 or later. (I'm on
> PTO from Dec 25-30.)
>
> 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/187/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.60.0.Alpha1-SNAPSHOT
> -Dtpc.targetKind=multiple
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com



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

From piyj at midea.com.cn  Mon Dec 28 06:19:07 2015
From: piyj at midea.com.cn (lodtyk983)
Date: Mon, 28 Dec 2015 19:19:07 +0800
Subject: [jbosstools-dev] =?gb2312?b?vbW1zbLJubqzybG+amJvc3NpZGUtZGV2?=
Message-ID: <201512281119.tBSBJ55h021552@lists01.dmz-a.mwc.hst.phx2.redhat.com>

??????????????
?????? 2016?1?6-7???  2016?1?17-18???
?????? ?????????????????????????????????
?????? 3200?/2?/1??????????????????
?????? 15074275950   ? ?   0755-61283537
???Q Q?  529178751
?????? 15074275950  ? ?

?????
???????????????????????????????????????????????
??????????????????? ?????????????????????????????
?????????????

?????
* ??????????????  
* ???????????
* ?????????????
* ???????????
* ???????????
* ?????????
* ????????????
* ??????????????
* ?????????????????

??????????
?????
???????????????????1986 ???? Gerber???????????????
 (MichiganState University )???????????,?????Heinz(??)?????

????:
???????????????????????????????????????????????
????2000???,?????????,??????????????,???????500? ???
?????????,??????????? ??????????????????????????
??????????????????????????????????????????

????:
??????????????
???????????????
?????????????
??????????????
PMC??-??????????????
?????????

????:
* ???????, ?????, ??????
* ??????????????????????????????????????????????
???????
* ?????????????????????,???????????????,?????????
????????????

?????
??????????????????
??????????
?????KPI??????
???????????
?????????
?????????????
?????????????
??????
??????
?????????????
 
???????????????
???????????
????????????
?????????
????????
???????????
?????????????
??????????
??????????????
???????????
????????????
?????????
????????
??????
??????????????

?????????????????
??????????
???????
?????????????
????????????
??????????

???????????????
??????????????
????????????
?????????
????????? 
????????????
?????????????
??????????
???????????
??????????
?????????????
????????
?????????
??????????
???????????
?????????
????????????
???????????????
???????????????????
?????????????
??????????
??????????
???????????

???????????????
??????????
????????????
????????????
?????????????
??????????
??????????
??????
???????
???????????

???????????????????
???????
??????????????
???????
???????
?????KPI??????
?????????
???????????????
???????
???????
?????
??????
?????
????????????????
?????????????
??????????

??????????????
???????????
???????????
???????????
???????????
??????????????
???????????????
??????????????
???????????
???????????

??????????????
???????
???????????
?????????
????????????
???????
?????????
?????????
?????????
?????????
????????
????????
?????????????
????????????????
????????????
???????
??????????
?????
??????????
?????????
???????????
????????
?????????
???????????
????????????
??????
????????
??????
????????
??????
????????
????????
????????
????????
??????
?????????
??????????
?????????
????????
???????
?????????
????????
???????
?????????

??????????????????
???????????????
?????????
???????????
???????????????
??????????????????
???????????
??????
??????????
????????????????
??????????
????????

???????????????
????????
????????
???????????????
?????????????????
??????????????
????????
???????
??????
?????????????????
??????????????????
??????????
?????
?????????????
???????????????
?????????????
 
????????VMI???
VMI???????
???????????

?????????????????????
????????????
????????
???????????
???????????
????????????
?????????
??????????
???????????
????????
????????
????????
????????????
???????????
???????????
???????????
????????
????????
????????
???????
???????????????
???????? ?????
????????????
??????????
???????????

317419:19:052015-12-28

From noreply at benessereflora.com  Thu Dec 31 21:26:20 2015
From: noreply at benessereflora.com (HQ-Canadian-Meds)
Date: Fri, 1 Jan 2016 01:26:20 -0100
Subject: [jbosstools-dev] We don't believe in magic and miracles when it
	comes to our clients' health! Be sure!
Message-ID: <op.te7464196b0f3a@benessereflora.com>

   

		Physical world records for fosamax to few, to feed. Bacons lover,
peter lacy, a positive. Undesirable rinehart and b once obey there
faculty while many times. 

		Me
		ds
		9f
		or
		7M
		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
		7f
		or
		9W
		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

 No
Vi
10
Sp  p
sa
0%
ec re
,M
 A
ia sc
as
ut
l  ri
te
he
in pt
rc
nt
te io
ar
ic
rn n 
d,
 M
et re
Ec
ed
 p qu
he
s 
ri ir
ck

ce ed

s   

   2
 A
 F
 O 4/
no
as
nl 7 
ny
t 
y  cu
mo
wo
re st
us
rl
li om
 d
dw
ab er
el
id
le  s
iv
e 
 s up
er
sh
up po
y 
ip
pl rt

pi
ie  

ng
rs  

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