From akazakov at exadel.com Mon Jan 5 14:34:30 2015 From: akazakov at exadel.com (Alexey Kazakov) Date: Mon, 05 Jan 2015 11:34:30 -0800 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.1.Final ] In-Reply-To: <548F6983.10402@redhat.com> References: <548F6983.10402@redhat.com> Message-ID: <54AAE746.8060901@exadel.com> It still needs to be done for jbosstools-aerogear and jbosstools-server. Gorkem, Rob, could you do it? On 12/15/2014 03:06 PM, Nick Boldt wrote: > Component leads, please tag your repositories! > > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called > jbosstools, also often called origin > $ git checkout FETCH_HEAD > $ git tag jbosstools-4.2.1.Final > $ git push jbosstools jbosstools-4.2.1.Final > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150105/e9872906/attachment.html From akazakov at exadel.com Tue Jan 6 12:47:21 2015 From: akazakov at exadel.com (Alexey Kazakov) Date: Tue, 06 Jan 2015 09:47:21 -0800 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.1.Final ] In-Reply-To: <54AAE746.8060901@exadel.com> References: <548F6983.10402@redhat.com> <54AAE746.8060901@exadel.com> Message-ID: <54AC1FA9.10100@exadel.com> OK, I did it for aerogear and server. On 01/05/2015 11:34 AM, Alexey Kazakov wrote: > It still needs to be done for jbosstools-aerogear and jbosstools-server. > > Gorkem, Rob, could you do it? > > > On 12/15/2014 03:06 PM, Nick Boldt wrote: >> Component leads, please tag your repositories! >> >> $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called >> jbosstools, also often called origin >> $ git checkout FETCH_HEAD >> $ git tag jbosstools-4.2.1.Final >> $ git push jbosstools jbosstools-4.2.1.Final >> > > > > _______________________________________________ > 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/20150106/eb5648f5/attachment.html From manderse at redhat.com Thu Jan 8 05:10:52 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Thu, 8 Jan 2015 05:10:52 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501081010.t08AAqG8017732@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-19008 https://issues.jboss.org/browse/JBIDE-19008 Summary: As a user, I want to delete OpenShift resources Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 15:12:49.804214 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From manderse at redhat.com Thu Jan 8 05:14:08 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Thu, 8 Jan 2015 05:14:08 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501081014.t08AE8Tj028593@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-19008 https://issues.jboss.org/browse/JBIDE-19008 Summary: As a user, I want to delete OpenShift resources Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 15:16:05.643045 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From mistria at redhat.com Thu Jan 8 13:16:25 2015 From: mistria at redhat.com (Mickael Istria) Date: Thu, 08 Jan 2015 19:16:25 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 Message-ID: <54AEC979.40005@redhat.com> Hi all, https://issues.jboss.org/browse/JBIDE-19005 : We'd like to move the master builds to Mars M4, that means concretely that we want to update the 4.50.0.Alpha1-SNAPSHOT target-platfroms. That should automatically fix at least one bug in THyM. Jira contain the p2diff details of what is added/removed with this change. This change also *removes org.apache.jasper* and its dependencies (the dependency chain for jasper got huge on Orbit, and it was simpler to remove it than to cascade inclusion of all dependencies). I made a quick check and did not find any reference to it in our sources so I guess it's fine. However, I'd like you to double check that you don't have dependency on one of the bundles removed (see p2diff on jira) before we merge this change. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150108/8cd4cacd/attachment.html From pleacu at redhat.com Thu Jan 8 16:16:22 2015 From: pleacu at redhat.com (Paul Leacu) Date: Thu, 8 Jan 2015 16:16:22 -0500 (EST) Subject: [jbosstools-dev] New JBTIS target platform available - JBTIS-TP-4.2.0.Final In-Reply-To: <284851282.6814732.1420751483968.JavaMail.zimbra@redhat.com> Message-ID: <987273068.6816233.1420751782003.JavaMail.zimbra@redhat.com> Greetings - An updated JBTIS TP is available - 4.2.0.Final: https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/tools/integration-stack/target-platform/4.2.0.Final/ http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.0.Final/ See Jira for details: https://issues.jboss.org/browse/JBTIS-378 1. Update BPMN2 Modeler to pick up the last bpmn2 feature source bundle https://issues.jboss.org/browse/JBTIS-375 http://download.jboss.org/jbosstools/updates/requirements/bpmn2-modeler/1.1.1.201501081320_1.0.0.201412192138_luna/ 2. Create .Final JBTIS TP for use with JBTIS 4.2.0.Final/ JBDSIS 8.0.0.GA (JDV release end-of-Jan) --paull From manderse at redhat.com Thu Jan 8 17:43:13 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 08 Jan 2015 23:43:13 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 In-Reply-To: <54AEC979.40005@redhat.com> References: <54AEC979.40005@redhat.com> Message-ID: <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> On 8 Jan 2015, at 19:16, Mickael Istria wrote: > Hi all, > > https://issues.jboss.org/browse/JBIDE-19005 : We'd like to move the > master builds to Mars M4, that means concretely that we want to update > the 4.50.0.Alpha1-SNAPSHOT target-platfroms. That should automatically > fix at least one bug in THyM. Jira contain the p2diff details of what > is added/removed with this change. > This change also *removes org.apache.jasper* jasper!? ...I wonder what uses that in eclipse ? > and its dependencies (the dependency chain for jasper got huge on > Orbit, and it was simpler to remove it than to cascade inclusion of > all dependencies). is that your comment or some decision on Eclipse.org side ? > I made a quick check and did not find any reference to it in our > sources so I guess it's fine. However, I'd like you to double check > that you don't have dependency on one of the bundles removed (see > p2diff on jira) before we merge this change. if we have dependencies on jasper that would be bad. I wonder though if parts of WTP uses/needs it ? /max http://about.me/maxandersen From manderse at redhat.com Fri Jan 9 02:59:25 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Fri, 9 Jan 2015 02:59:25 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501090759.t097xPhr006387@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 JBDS-3308 https://issues.jboss.org/browse/JBDS-3308 Summary: Promote JBoss Tools CAT in JBT/JBDS About box Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 7:39:41.010312 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From mistria at redhat.com Fri Jan 9 03:40:12 2015 From: mistria at redhat.com (Mickael Istria) Date: Fri, 09 Jan 2015 09:40:12 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 In-Reply-To: <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> References: <54AEC979.40005@redhat.com> <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> Message-ID: <54AF93EC.1050306@redhat.com> On 01/08/2015 11:43 PM, Max Rydahl Andersen wrote: >> and its dependencies (the dependency chain for jasper got huge on >> Orbit, and it was simpler to remove it than to cascade inclusion of >> all dependencies). > is that your comment or some decision on Eclipse.org side ? This is my comment. > I wonder though if parts of WTP uses/needs it ? Target-platform-validation is expected to fail because of a missing dependency in that case. However, I can see that org.apache.jasper.glassfish bundle still remains (it's actually included in JBDS 8). -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150109/aa178ce9/attachment-0001.html From manderse at redhat.com Fri Jan 9 03:58:21 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Fri, 09 Jan 2015 09:58:21 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 In-Reply-To: <54AF93EC.1050306@redhat.com> References: <54AEC979.40005@redhat.com> <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> <54AF93EC.1050306@redhat.com> Message-ID: <2D4A7FE1-A4A3-4769-A9C5-269D5F004513@redhat.com> On 9 Jan 2015, at 9:40, Mickael Istria wrote: > On 01/08/2015 11:43 PM, Max Rydahl Andersen wrote: >>> and its dependencies (the dependency chain for jasper got huge on >>> Orbit, and it was simpler to remove it than to cascade inclusion of >>> all dependencies). >> is that your comment or some decision on Eclipse.org side ? > This is my comment. so i'm a bit puzzled...if apache.jasper is part of eclipse release train why do we even need to chase it on orbit ? why is this dependency in here in the first place ? if not part of release train there should be a reason.. >> I wonder though if parts of WTP uses/needs it ? > Target-platform-validation is expected to fail because of a missing > dependency in that case. > However, I can see that org.apache.jasper.glassfish bundle still > remains (it's actually included in JBDS 8). /max http://about.me/maxandersen From mistria at redhat.com Fri Jan 9 04:13:05 2015 From: mistria at redhat.com (Mickael Istria) Date: Fri, 09 Jan 2015 10:13:05 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 In-Reply-To: <2D4A7FE1-A4A3-4769-A9C5-269D5F004513@redhat.com> References: <54AEC979.40005@redhat.com> <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> <54AF93EC.1050306@redhat.com> <2D4A7FE1-A4A3-4769-A9C5-269D5F004513@redhat.com> Message-ID: <54AF9BA1.6080208@redhat.com> On 01/09/2015 09:58 AM, Max Rydahl Andersen wrote: > On 9 Jan 2015, at 9:40, Mickael Istria wrote: > >> On 01/08/2015 11:43 PM, Max Rydahl Andersen wrote: >>>> and its dependencies (the dependency chain for jasper got huge on >>>> Orbit, and it was simpler to remove it than to cascade inclusion of >>>> all dependencies). >>> is that your comment or some decision on Eclipse.org side ? >> This is my comment. > so i'm a bit puzzled...if apache.jasper is part of eclipse release > train why do we even need to chase it on orbit ? > why is this dependency in here in the first place ? > if not part of release train there should be a reason.. Actually, it's not part of the Eclipse release train. Nothing on the release train depends on it. I don't know why it used to be in our target definition, and I imagine that it might have been there for some reason in the past, and that it has become useless. Let's give a few days (until Friday) for developers to raise their hand if they actually need it, if not, let's remove it; and in case something is actually failing after that, we'll re-add jasper and its family, and document on the target files why it needs to be here. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150109/9e64e92c/attachment.html From manderse at redhat.com Fri Jan 9 05:13:38 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Fri, 9 Jan 2015 05:13:38 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501091013.t09ADcuV016741@int-mx14.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBDS-3308 https://issues.jboss.org/browse/JBDS-3308 Summary: Promote JBoss Tools CAT in JBT/JBDS About box Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please ensure this issue has a proper component set. Last Update: 9:53:54.663281 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=%28filter%3D%27ds_lint_nocomponent%27%29 From manderse at redhat.com Mon Jan 12 03:48:58 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Mon, 12 Jan 2015 09:48:58 +0100 Subject: [jbosstools-dev] Suggested change for TP 4.50.0.Alpha1-SNAPSHOT: Mars M4 In-Reply-To: <54AF9BA1.6080208@redhat.com> References: <54AEC979.40005@redhat.com> <0D16E6AF-3A4C-454E-8BDB-9AD5D382966F@redhat.com> <54AF93EC.1050306@redhat.com> <2D4A7FE1-A4A3-4769-A9C5-269D5F004513@redhat.com> <54AF9BA1.6080208@redhat.com> Message-ID: <35B7C985-D168-497C-AA15-5BFF90C968EC@redhat.com> On 9 Jan 2015, at 10:13, Mickael Istria wrote: > On 01/09/2015 09:58 AM, Max Rydahl Andersen wrote: >> On 9 Jan 2015, at 9:40, Mickael Istria wrote: >> >>> On 01/08/2015 11:43 PM, Max Rydahl Andersen wrote: >>>>> and its dependencies (the dependency chain for jasper got huge on >>>>> Orbit, and it was simpler to remove it than to cascade inclusion >>>>> of all dependencies). >>>> is that your comment or some decision on Eclipse.org side ? >>> This is my comment. >> so i'm a bit puzzled...if apache.jasper is part of eclipse release >> train why do we even need to chase it on orbit ? >> why is this dependency in here in the first place ? >> if not part of release train there should be a reason.. > Actually, it's not part of the Eclipse release train. Nothing on the > release train depends on it. > I don't know why it used to be in our target definition, and I imagine > that it might have been there for some reason in the past, and that it > has become useless. > > Let's give a few days (until Friday) for developers to raise their > hand if they actually need it, if not, let's remove it; and in case > something is actually failing after that, we'll re-add jasper and its > family, and document on the target files why it needs to be here. I can see in git history it seem to have been in our TP ever since we started doing TP's thus its probably been there just "forever" and part of our initial "conversion" of our updatesite based "TP" to more managed TP. Thus yeah, I agree best way forward is to remove it and see what (if anything) breaks in master. /max http://about.me/maxandersen From pleacu at redhat.com Mon Jan 12 15:33:45 2015 From: pleacu at redhat.com (Paul Leacu) Date: Mon, 12 Jan 2015 15:33:45 -0500 (EST) Subject: [jbosstools-dev] JBDSIS 8.0.0.Beta2/ JBTIS 4.2.0.Beta2 now live In-Reply-To: <748905031.7851456.1421082403556.JavaMail.zimbra@redhat.com> Message-ID: <1175930190.7954876.1421094825201.JavaMail.zimbra@redhat.com> Greetings, The latest Eclipse-Luna capable, JBDS 8.0.1.GA compatible Integration Stack Beta tooling is released. This capture contains new versions of BPEL, BPMN2, ESB, drools/jBPM, Fuse Tooling, SwitchYard and Teiid Designer. This beta release is available as "development" or as "early access". JBDSIS 8.0.0.Beta2, JBTIS 4.2.0.Beta2 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.0.1.GA' 2. Start jbdevstudio or eclipse (with jbds from step 1) 3. Select the Software/Update tab in the JBoss Central view. Check the "Enable Early Access" check box. The production Early Access tooling appears in the 'Features Available' window. done! The standard p2 installer is also 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.0.1.GA' 2. Start jbdevstudio or eclipse-with-jbds from step 1, then: Help > Install New Software... Add... - use this for 'Location:' https://devstudio.redhat.com/updates/8.0-development/integration-stack/ The standard p2 installer is available for the community capture (JBTIS): 1. Install JBoss Tools 4.2.1.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.1.Final' 2. Start eclipse-with-jbt from step 1, then: Help > Install New Software... Add... - use this for 'Location:' http://download.jboss.org/jbosstools/updates/development/luna/integration-stack/ JBoss Central is supported for the community capture as Early Access (JBTIS): 1. Start eclipse-with-jbt from step 1 2. Select the Software/Update tab in the JBoss Central view. Check the "Enable Early Access" check box. The Early Access tooling appears in the 'Features Available' window. ---- A standalone p2 installer is available for the community capture (JBTIS): * Start eclipse Luna, then: Help > Install New Software... Add... - use this for 'Location:' http://download.jboss.org/jbosstools/updates/development/luna/integration-stack/aggregate/4.2.0.Beta2a/withreferences/ For component and QE test developers - the JBTIS target platform is: https://repository.jboss.org/nexus/content/repositories/releases/org/jboss/tools/integration-stack/target-platform/4.2.0.Beta2b/ http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.0.Beta2b/REPO/ Give it a try! From mistria at redhat.com Tue Jan 13 04:41:30 2015 From: mistria at redhat.com (Mickael Istria) Date: Tue, 13 Jan 2015 10:41:30 +0100 Subject: [jbosstools-dev] Security for in TP 4.41.2.CR1-SNAPSHOT: JGit Message-ID: <54B4E84A.3010204@redhat.com> Hi, Some of you may be aware that a vulnerability was found in most Git clients (including JGit): https://bugs.eclipse.org/bugs/show_bug.cgi?id=456947 In order to not propagate this vulnerability, we've updated the target platform 4.41.2.CR1-SNAPSHOT to ship a fixed version of EGit/JGit. Parent pom 4.2.2-SNAPSHOT will be updated to consume the modified 4.41.2.CR1-SNAPSHOT target-platform. Jobs for jbosstools-4.2.x branch will be updated to consume and ship the modified 4.41.2.CR1-SNAPSHOT target-platform. Then, when we have made the necessary test to validate that our change has the expected effect on JBoss Tools and JBoss Developer Studio, we'll release this 4.41.2.CR1-SNAPSHOT target-platform as a 4.41.2.Final, re-update parent pom and jobs, and we'll be able to proceed with staging of JBT 4.2.2/JBDS 8.0.2. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150113/db3657d5/attachment.html From mistria at redhat.com Wed Jan 14 05:22:12 2015 From: mistria at redhat.com (Mickael Istria) Date: Wed, 14 Jan 2015 11:22:12 +0100 Subject: [jbosstools-dev] JBoss Tools Core 4.2.2.Final bits available for QE testing Message-ID: <54B64354.8070901@redhat.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/updates/staging/luna/ Target platforms: * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Final * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.41.2.Final Until the above target platform site is released, you may need to add it to Eclipse to resolve dependencies at install time. Once released, dependencies will be found automatically from here: * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/luna/ (latest release) * http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/4.41.2.Final-SNAPSHOT/ (upcoming milestone) * http://download.jboss.org/jbosstools/targetplatforms/jbtearlyaccesstarget/4.41.2.Final-SNAPSHOT/ (upcoming milestone) 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 -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150114/0eb91001/attachment-0001.html From ldimaggi at redhat.com Wed Jan 14 08:39:34 2015 From: ldimaggi at redhat.com (Len DiMaggio) Date: Wed, 14 Jan 2015 08:39:34 -0500 (EST) Subject: [jbosstools-dev] JBoss Tools Core 4.2.2.Final bits available for QE testing In-Reply-To: <54B64354.8070901@redhat.com> References: <54B64354.8070901@redhat.com> Message-ID: <319720727.9668548.1421242774927.JavaMail.zimbra@redhat.com> Thanks Mickael - but, is there a corresponding JBDS 8.0.2 build? -- Len ----- Original Message ----- | From: "Mickael Istria" | To: "jbosstools-dev jbosstools-dev" | Sent: Wednesday, January 14, 2015 5:22:12 AM | Subject: [jbosstools-dev] JBoss Tools Core 4.2.2.Final bits available for QE | testing | 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/updates/staging/luna/ Target platforms: | * | http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.40.0.Final | * http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/ | 4.41.2.Final Until the above target platform site is released, you may need | to add it to Eclipse to resolve dependencies at install time. Once released, | dependencies will be found automatically from here: * | http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/luna/ | (latest release) * | http://download.jboss.org/jbosstools/targetplatforms/jbtcentraltarget/ | 4.41.2.Final-SNAPSHOT / (upcoming milestone) * | http://download.jboss.org/jbosstools/targetplatforms/jbtearlyaccesstarget/ | 4.41.2.Final-SNAPSHOT / (upcoming milestone) 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 | -- | Mickael Istria | Eclipse developer at JBoss, by Red Hat | My blog - My Tweets | _______________________________________________ | jbosstools-dev mailing list | jbosstools-dev at lists.jboss.org | https://lists.jboss.org/mailman/listinfo/jbosstools-dev -- 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/20150114/b37bc8bc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: RHxJBpngthumb.png Type: image/png Size: 9435 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150114/b37bc8bc/attachment.png From mistria at redhat.com Wed Jan 14 08:46:00 2015 From: mistria at redhat.com (Mickael Istria) Date: Wed, 14 Jan 2015 14:46:00 +0100 Subject: [jbosstools-dev] JBoss Tools Core 4.2.2.Final bits available for QE testing In-Reply-To: <319720727.9668548.1421242774927.JavaMail.zimbra@redhat.com> References: <54B64354.8070901@redhat.com> <319720727.9668548.1421242774927.JavaMail.zimbra@redhat.com> Message-ID: <54B67318.7020601@redhat.com> On 01/14/2015 02:39 PM, Len DiMaggio wrote: > Thanks Mickael - but, is there a corresponding JBDS 8.0.2 build? WIP. -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150114/e6abd631/attachment.html From manderse at redhat.com Fri Jan 16 05:16:00 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Fri, 16 Jan 2015 05:16:00 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501161016.t0GAG0qY003675@int-mx11.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBDS-3318 https://issues.jboss.org/browse/JBDS-3318 Summary: Hibernate/Persistence.next Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please ensure this issue has a proper component set. Last Update: 18:43:59.913012 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=%28filter%3D%27ds_lint_nocomponent%27%29 From sales7 at dongdatools.com Sun Jan 18 21:14:26 2015 From: sales7 at dongdatools.com (=?UTF-8?B?RXZh?=) Date: Mon, 19 Jan 2015 10:14:26 +0800 (CST) Subject: [jbosstools-dev] =?utf-8?q?Hot_products_from_Dongda?= Message-ID: <2132727977.1613769.1421633666367.JavaMail.root@wmthree-10> An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150119/960cdbf4/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Hot Jig Saw.png Type: image/png Size: 94732 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150119/960cdbf4/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Hot Impact Drill.png Type: image/png Size: 102953 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150119/960cdbf4/attachment-0003.png From dgolovin at exadel.com Tue Jan 20 05:16:41 2015 From: dgolovin at exadel.com (Denis Golovin) Date: Tue, 20 Jan 2015 11:16:41 +0100 Subject: [jbosstools-dev] Build target platform for master Message-ID: <54BE2B09.90201@exadel.com> It there any better way to rebuild targetplatform for master? Now I can trigger only https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ which rebuilds luna branch and master. Checking out Revision 462adddbb6433a7fdba00b2d94faf081d445dbdc (origin/4.50.x) Triggering(RHEL6||RHEL7||beaker||jboss-prod)&&!ia64&&!rhts,jbdevstudio,4.41.3.CR1-SNAPSHOT Triggering(RHEL6||RHEL7||beaker||jboss-prod)&&!ia64&&!rhts,jbdevstudio,4.50.0.Alpha1-SNAPSHOT Triggering(RHEL6||RHEL7||beaker||jboss-prod)&&!ia64&&!rhts,jbosstools,4.41.3.CR1-SNAPSHOT Triggering(RHEL6||RHEL7||beaker||jboss-prod)&&!ia64&&!rhts,jbosstools,4.50.0.Alpha1-SNAPSHOT which is twice more than I need. Thanks Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150120/1c7c86a7/attachment.html From mistria at redhat.com Tue Jan 20 05:21:49 2015 From: mistria at redhat.com (Mickael Istria) Date: Tue, 20 Jan 2015 11:21:49 +0100 Subject: [jbosstools-dev] Build target platform for master In-Reply-To: <54BE2B09.90201@exadel.com> References: <54BE2B09.90201@exadel.com> Message-ID: <54BE2C3D.4040603@redhat.com> On 01/20/2015 11:16 AM, Denis Golovin wrote: > It there any better way to rebuild targetplatform for master? > Now I can trigger only > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ > which rebuilds luna branch and master. There is currently no better way of doing that. We find it more convenient to have a single job that does twice the job, than to have multiple jobs (1 for each TP). Practically, it has never caused any delay or issue... -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150120/b95172b7/attachment.html From dgolovin at exadel.com Tue Jan 20 05:49:38 2015 From: dgolovin at exadel.com (Denis Golovin) Date: Tue, 20 Jan 2015 11:49:38 +0100 Subject: [jbosstools-dev] Build target platform for master In-Reply-To: <54BE2C3D.4040603@redhat.com> References: <54BE2B09.90201@exadel.com> <54BE2C3D.4040603@redhat.com> Message-ID: <54BE32C2.9070309@exadel.com> On 01/20/2015 11:21 AM, Mickael Istria wrote: > On 01/20/2015 11:16 AM, Denis Golovin wrote: >> It there any better way to rebuild targetplatform for master? >> Now I can trigger only >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ >> which rebuilds luna branch and master. > There is currently no better way of doing that. > We find it more convenient to have a single job that does twice the > job, than to have multiple jobs (1 for each TP). Practically, it has > never caused any delay or issue... Well, if everyone thinks the same, the that explains jenkins slowness. > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150120/02838ffe/attachment.html From manderse at redhat.com Tue Jan 20 19:17:33 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 21 Jan 2015 01:17:33 +0100 Subject: [jbosstools-dev] Build target platform for master In-Reply-To: <54BE2C3D.4040603@redhat.com> References: <54BE2B09.90201@exadel.com> <54BE2C3D.4040603@redhat.com> Message-ID: On 20 Jan 2015, at 11:21, Mickael Istria wrote: > On 01/20/2015 11:16 AM, Denis Golovin wrote: >> It there any better way to rebuild targetplatform for master? >> Now I can trigger only >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ >> which rebuilds luna branch and master. > There is currently no better way of doing that. > We find it more convenient to have a single job that does twice the > job, than to have multiple jobs (1 for each TP). Practically, it has > never caused any delay or issue... why would we want to trigger an update of the branch build if only master needs building ? why not have branched jobs for TP like we have for other components ? /max http://about.me/maxandersen From nboldt at redhat.com Tue Jan 20 19:39:01 2015 From: nboldt at redhat.com (Nick Boldt) Date: Tue, 20 Jan 2015 19:39:01 -0500 Subject: [jbosstools-dev] Build target platform for master In-Reply-To: References: <54BE2B09.90201@exadel.com> <54BE2C3D.4040603@redhat.com> Message-ID: <54BEF525.9050706@redhat.com> Less jobs = less maintenance. In the past I've just updated the matrix to exclude the stuff we aren't actively building immediately before running the job (like the 4.3x stuff while building 4.4x). So... I've done that now for the [1] job, by temporarily removing the 4.41.x configuration so we only build the 4.5x stuff. [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ -- When it's time to start up the 4.42.x builds for Luna SR2 (in February), we can just add that configuration back into the job, and voila. N On 01/20/2015 07:17 PM, Max Rydahl Andersen wrote: > On 20 Jan 2015, at 11:21, Mickael Istria wrote: > >> On 01/20/2015 11:16 AM, Denis Golovin wrote: >>> It there any better way to rebuild targetplatform for master? >>> Now I can trigger only >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Master/job/jbosstoolstargetplatforms-matrix/ >>> which rebuilds luna branch and master. >> There is currently no better way of doing that. >> We find it more convenient to have a single job that does twice the >> job, than to have multiple jobs (1 for each TP). Practically, it has >> never caused any delay or issue... > > why would we want to trigger an update of the branch build if only > master needs building ? > > why not have branched jobs for TP like we have for other components ? > > /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 Wed Jan 21 05:41:31 2015 From: mistria at redhat.com (Mickael Istria) Date: Wed, 21 Jan 2015 11:41:31 +0100 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] Message-ID: <54BF825B.8030208@redhat.com> Component leads, please tag your repositories! $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin $ git tag jbosstools-4.2.2.Final FETCH_HEAD $ git push jbosstools jbosstools-4.2.2.Final -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/d9fcb2ec/attachment.html From mistria at redhat.com Wed Jan 21 06:02:29 2015 From: mistria at redhat.com (Mickael Istria) Date: Wed, 21 Jan 2015 12:02:29 +0100 Subject: [jbosstools-dev] JBoss Tools 4.2.2.Final is available Message-ID: <54BF8745.7050704@redhat.com> This is a maintenance release of JBoss Tools aimed atEclipse Luna users. Eclipse Marketplace: https://marketplace.eclipse.org/content/jboss-tools-luna Update Site: http://download.jboss.org/jbosstools/updates/development/luna/ Update Site Zips: http://sourceforge.net/projects/jboss/files/JBossTools/jbosstools4.2.x/ Installation instructions: http://tools.jboss.org/downloads/installation.html New + Noteworthy (subject to change): http://tools.jboss.org/documentation/whatsnew/jbosstools/4.2.2.Final.html Schedule / Upcoming Releases: https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/c6aa27ae/attachment-0001.html From xcoulon at redhat.com Wed Jan 21 06:10:27 2015 From: xcoulon at redhat.com (Xavier Coulon) Date: Wed, 21 Jan 2015 12:10:27 +0100 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <154E9A40-5901-47F4-A6E5-3FEA6C4DE2FC@redhat.com> Done for WebServices and LiveReload. Best regards, /Xavier > On 21 Jan 2015, at 11:41, Mickael Istria wrote: > > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/d2dfeda9/attachment.html From kmarmaliykov at exadel.com Wed Jan 21 06:17:06 2015 From: kmarmaliykov at exadel.com (Konstantin Marmalyukov) Date: Wed, 21 Jan 2015 14:17:06 +0300 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <54BF8AB2.7000008@exadel.com> Vpe and Browsersim - done On 1/21/2015 1:41 PM, Mickael Istria wrote: > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/c9002ada/attachment.html From adietish at redhat.com Wed Jan 21 07:02:53 2015 From: adietish at redhat.com (=?windows-1252?Q?Andr=E9_Dietisheim?=) Date: Wed, 21 Jan 2015 13:02:53 +0100 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <54BF956D.5000401@redhat.com> done for openshift. On 01/21/2015 11:41 AM, Mickael Istria wrote: > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/b2b2950d/attachment.html From manderse at redhat.com Wed Jan 21 08:46:49 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Wed, 21 Jan 2015 08:46:49 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501211346.t0LDkndH014395@int-mx14.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBDS-3321 https://issues.jboss.org/browse/JBDS-3321 Summary: Rest Quick Start Exception ava.lang.ClassNotFoundException: com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 1 day, 4:20:01.133105 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From ggastald at redhat.com Wed Jan 21 10:03:50 2015 From: ggastald at redhat.com (George Gastaldi) Date: Wed, 21 Jan 2015 13:03:50 -0200 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <54BFBFD6.7020907@redhat.com> Done for jbosstools-forge On 01/21/2015 08:41 AM, Mickael Istria wrote: > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/6210ce1f/attachment.html From fbricon at redhat.com Wed Jan 21 10:21:58 2015 From: fbricon at redhat.com (Fred Bricon) Date: Wed, 21 Jan 2015 10:21:58 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: central done > Le 21 janv. 2015 ? 05:41, Mickael Istria a ?crit : > > git push jbosstools jbosstools-4.2.2.Final -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/f61853a2/attachment.html From snjeza.peco at gmail.com Wed Jan 21 10:52:40 2015 From: snjeza.peco at gmail.com (Snjezana Peco) Date: Wed, 21 Jan 2015 16:52:40 +0100 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <54BFCB48.4090300@gmail.com> Done for arquillian, birt and portlet. Snjeza On 1/21/2015 11:41 AM, Mickael Istria wrote: > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/b17a736f/attachment-0001.html From akazakov at exadel.com Wed Jan 21 12:31:07 2015 From: akazakov at exadel.com (Alexey Kazakov) Date: Wed, 21 Jan 2015 09:31:07 -0800 Subject: [jbosstools-dev] ACTION REQUIRED: Project leads, please tag your projects [ branch jbosstools-4.2.x -> tag jbosstools-4.2.2.Final ] In-Reply-To: <54BF825B.8030208@redhat.com> References: <54BF825B.8030208@redhat.com> Message-ID: <54BFE25B.7070203@exadel.com> Done for the rest of the components: base, jst, javaee, hibernate, freemarker, aerogear, server On 01/21/2015 02:41 AM, Mickael Istria wrote: > Component leads, please tag your repositories! > $ git fetch jbosstools jbosstools-4.2.x #assuming remote is called jbosstools, also often called origin > $ git tag jbosstools-4.2.2.Final FETCH_HEAD > $ git push jbosstools jbosstools-4.2.2.Final > > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150121/80679c28/attachment.html From manderse at redhat.com Thu Jan 22 07:50:55 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 22 Jan 2015 13:50:55 +0100 Subject: [jbosstools-dev] 4.2.x is now open for 4.2.3 (that will be included in Developer Studio 8.1) Message-ID: <961D2A84-48E6-40E5-A24A-6E489CE542B1@redhat.com> Hi, Just a heads up that now that we have tagged and released 4.2.2, the jbosstools-4.2.x branch are open for issues related to 4.2.3. This 4.2.3 is planned to be what is included in JBoss Developer Studio 8.1. Please be aware that this version is intended to backwards compatible with the 4.2 releases; especially consideration is to be sure we do not break Integration stack in context of changed dependencies or any API they use. Thus as always, take care in what changes you do, have a jira for each work so QE/docs are aware and don't be afraid to ask for more than one review of PRs if any doubts. Happy 8.1! /max http://about.me/maxandersen From fbricon at redhat.com Thu Jan 22 10:11:37 2015 From: fbricon at redhat.com (Fred Bricon) Date: Thu, 22 Jan 2015 10:11:37 -0500 Subject: [jbosstools-dev] 4.2.x is now open for 4.2.3 (that will be included in Developer Studio 8.1) In-Reply-To: <961D2A84-48E6-40E5-A24A-6E489CE542B1@redhat.com> References: <961D2A84-48E6-40E5-A24A-6E489CE542B1@redhat.com> Message-ID: <3AE73C3A-4CFE-440D-92B3-A0902D0C07E2@redhat.com> Also, *if* you need to make any changes to your components in 4.2.x, PLEASE upversion them first (for the whole github repo) Just saying. Fred > Le 22 janv. 2015 ? 07:50, Max Rydahl Andersen a ?crit : > > Hi, > > Just a heads up that now that we have tagged and released 4.2.2, the > jbosstools-4.2.x branch > are open for issues related to 4.2.3. > > This 4.2.3 is planned to be what is included in JBoss Developer Studio > 8.1. > > Please be aware that this version is intended to backwards compatible > with the 4.2 releases; > especially consideration is to be sure we do not break Integration stack > in context of > changed dependencies or any API they use. > > Thus as always, take care in what changes you do, have a jira for each > work so QE/docs are aware > and don't be afraid to ask for more than one review of PRs if any > doubts. > > Happy 8.1! > /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 Thu Jan 22 11:35:32 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 22 Jan 2015 17:35:32 +0100 Subject: [jbosstools-dev] 4.2.x is now open for 4.2.3 (that will be included in Developer Studio 8.1) In-Reply-To: <3AE73C3A-4CFE-440D-92B3-A0902D0C07E2@redhat.com> References: <961D2A84-48E6-40E5-A24A-6E489CE542B1@redhat.com> <3AE73C3A-4CFE-440D-92B3-A0902D0C07E2@redhat.com> Message-ID: <465BE94D-43C4-45E1-A1C2-6DD7692E3292@redhat.com> On 22 Jan 2015, at 16:11, Fred Bricon wrote: > Also, *if* you need to make any changes to your components in 4.2.x, > PLEASE upversion them first (for the whole github repo) > Just saying. oh yes...definitely /max > Fred > > >> Le 22 janv. 2015 ? 07:50, Max Rydahl Andersen >> a ?crit : >> >> Hi, >> >> Just a heads up that now that we have tagged and released 4.2.2, the >> jbosstools-4.2.x branch >> are open for issues related to 4.2.3. >> >> This 4.2.3 is planned to be what is included in JBoss Developer >> Studio >> 8.1. >> >> Please be aware that this version is intended to backwards compatible >> with the 4.2 releases; >> especially consideration is to be sure we do not break Integration >> stack >> in context of >> changed dependencies or any API they use. >> >> Thus as always, take care in what changes you do, have a jira for >> each >> work so QE/docs are aware >> and don't be afraid to ask for more than one review of PRs if any >> doubts. >> >> Happy 8.1! >> /max >> http://about.me/maxandersen >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From nboldt at redhat.com Thu Jan 22 14:51:46 2015 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 22 Jan 2015 14:51:46 -0500 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> Message-ID: <54C154D2.5000505@redhat.com> No, because then AbstractTest* and TemplateTest* classes would run, and they shouldn't be. You can set your own entries in your root pom. Then all your projects' tests will inherit those new rules. -- We may also have some older JUnit 3 tests (from the JDK 1.4 era?) that might still be set to run with older JRE environments, where @annotations are not supported. If I'm wrong on that, and we no longer support running tests w/ old runtimes, then yes, we could consider adding @Ignores to all the tests which shouldn't be run, instead of using the "All" and "Suite" naming conventions. -- I've cc:'d the jbosstools-dev list because a wider audience might be able to comment better on if it's time to move to using @ignore instead of using restrictive patterns when running JUnits w/ Surefire in Tycho/Maven builds. N On 01/22/2015 02:08 PM, Daniel Florian wrote: > Guys, > > We currently have to add each JUnit test class to a test suite file called AllTests.java. If a test does not get added to this test suite it does not get run. > > I think the pom has this: > > > **/AllTests.class > **/*AllTests*.class > **/*AllBotTests*.class > **/*TestSuite*.class > > > Could we add: > > **/Test*.class > **/*Test.class > > So that we wouldn't need an AllTests.java. Other projects can keep using the test suite approach. > > With JUnit's @Ignore it is easy to stop a test from being run. > > wdyt? > > Thanks, > > Dan > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From xcoulon at redhat.com Fri Jan 23 03:22:58 2015 From: xcoulon at redhat.com (Xavier Coulon) Date: Fri, 23 Jan 2015 09:22:58 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <54C154D2.5000505@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> Message-ID: <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> What about using to ignore the Abstract*.class and other similar classes [1] ? I don't use any TestSuite class in the JAX-RS tooling component ofJBoss Tools, because I think it's an unnecessary pain to have to maintain an extra/accurate list of all the test classes that need to be run. And I like that some test methods or even test classes can be skipped with the @Ignore annotation. [1] Here's what I have in my pom.xml: org.eclipse.tycho tycho-surefire-plugin **/*TestCase.class **/Abstract*.class Best regards, /Xavier > On 22 Jan 2015, at 20:51, Nick Boldt wrote: > > No, because then AbstractTest* and TemplateTest* classes would run, and > they shouldn't be. > > You can set your own entries in your root pom. Then all your > projects' tests will inherit those new rules. > > -- > > We may also have some older JUnit 3 tests (from the JDK 1.4 era?) that > might still be set to run with older JRE environments, where > @annotations are not supported. > > If I'm wrong on that, and we no longer support running tests w/ old > runtimes, then yes, we could consider adding @Ignores to all the tests > which shouldn't be run, instead of using the "All" and "Suite" naming > conventions. > > -- > > I've cc:'d the jbosstools-dev list because a wider audience might be > able to comment better on if it's time to move to using @ignore instead > of using restrictive patterns when running JUnits w/ Surefire in > Tycho/Maven builds. > > N > > On 01/22/2015 02:08 PM, Daniel Florian wrote: >> Guys, >> >> We currently have to add each JUnit test class to a test suite file called AllTests.java. If a test does not get added to this test suite it does not get run. >> >> I think the pom has this: >> >> >> **/AllTests.class >> **/*AllTests*.class >> **/*AllBotTests*.class >> **/*TestSuite*.class >> >> >> Could we add: >> >> **/Test*.class >> **/*Test.class >> >> So that we wouldn't need an AllTests.java. Other projects can keep using the test suite approach. >> >> With JUnit's @Ignore it is easy to stop a test from being run. >> >> wdyt? >> >> Thanks, >> >> Dan >> > > -- > 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/20150123/ea0cb3e0/attachment-0001.html From max.andersen at redhat.com Fri Jan 23 06:42:35 2015 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Fri, 23 Jan 2015 12:42:35 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> Message-ID: <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> So this always been one of the things I disliked about our parent pom. I much rather prefer run all the test classes automatically. The reason for the current pattern is historically - that most tests were done via testsuites instead of individual ones since there was no other good way of grouping tests. Problem is we haven't found a good way of moving from the old to the new without having to go through all the existing test code and ensure the tests are not double executed. But right now I think the only one I know that is pro-testsuites being the default is Rob S. who have just said he is fine switching to Tests being executed by default - he can just use the TestSuite pattern in his test projects if he insists :) One drawback of not having testsuites is though that we loose the ability to easily run a group of tests from eclipse or maven. Anyone found a good way of doing that via junit ? (testng has groups but tycho surefire/junit does not support that afaik) That said - i'm all for looking at moving to this for Mars builds. I guess the suggestion is to: exclude *Abstract*, *Suite* and only include *Test.class, correct ? (Xavier used *TestCase.class which is a different pattern than the rest afaics) PR welcome on https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml > What about using to ignore the Abstract*.class and other > similar classes [1] ? > I don't use any TestSuite class in the JAX-RS tooling component > ofJBoss Tools, because I think it's an unnecessary pain to have to > maintain an extra/accurate list of all the test classes that need to > be run. And I like that some test methods or even test classes can be > skipped with the @Ignore annotation. > > [1] Here's what I have in my pom.xml: > > > org.eclipse.tycho > tycho-surefire-plugin > > > **/*TestCase.class > > > **/Abstract*.class > > > > > Best regards, > /Xavier > > > >> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >> >> No, because then AbstractTest* and TemplateTest* classes would run, >> and >> they shouldn't be. >> >> You can set your own entries in your root pom. Then all >> your >> projects' tests will inherit those new rules. >> >> -- >> >> We may also have some older JUnit 3 tests (from the JDK 1.4 era?) >> that >> might still be set to run with older JRE environments, where >> @annotations are not supported. >> >> If I'm wrong on that, and we no longer support running tests w/ old >> runtimes, then yes, we could consider adding @Ignores to all the >> tests >> which shouldn't be run, instead of using the "All" and "Suite" naming >> conventions. >> >> -- >> >> I've cc:'d the jbosstools-dev list because a wider audience might be >> able to comment better on if it's time to move to using @ignore >> instead >> of using restrictive patterns when running JUnits w/ Surefire in >> Tycho/Maven builds. >> >> N >> >> On 01/22/2015 02:08 PM, Daniel Florian wrote: >>> Guys, >>> >>> We currently have to add each JUnit test class to a test suite file >>> called AllTests.java. If a test does not get added to this test >>> suite it does not get run. >>> >>> I think the pom has this: >>> >>> >>> **/AllTests.class >>> **/*AllTests*.class >>> **/*AllBotTests*.class >>> **/*TestSuite*.class >>> >>> >>> Could we add: >>> >>> **/Test*.class >>> **/*Test.class >>> >>> So that we wouldn't need an AllTests.java. Other projects can keep >>> using the test suite approach. >>> >>> With JUnit's @Ignore it is easy to stop a test from being run. >>> >>> wdyt? >>> >>> Thanks, >>> >>> Dan >>> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From xcoulon at redhat.com Fri Jan 23 07:09:25 2015 From: xcoulon at redhat.com (Xavier Coulon) Date: Fri, 23 Jan 2015 13:09:25 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> Message-ID: <4E192793-796A-4E84-BCB2-11CC68C775EC@redhat.com> > On 23 Jan 2015, at 12:42, Max Rydahl Andersen wrote: > > > So this always been one of the things I disliked about our parent pom. I much rather prefer run all the test classes automatically. > > The reason for the current pattern is historically - that most tests were done via testsuites instead of individual ones since there was no other good way of grouping tests. > > Problem is we haven't found a good way of moving from the old to the new without having to go through all the existing test code and ensure the tests are not double executed. > > But right now I think the only one I know that is pro-testsuites being the default is Rob S. who have just > said he is fine switching to Tests being executed by default - he can just use the TestSuite pattern in his test projects if he insists :) > > One drawback of not having testsuites is though that we loose the ability to easily run a group of tests from eclipse or maven. > > Anyone found a good way of doing that via junit ? (testng has groups but tycho surefire/junit does not support that afaik) > > That said - i'm all for looking at moving to this for Mars builds. > > I guess the suggestion is to: > > exclude *Abstract*, *Suite* and only include *Test.class, correct ? (Xavier used *TestCase.class which is a different pattern than the rest afaics) > True, I suffixed my test classes with "TestCase", but I have no reason to stick with that if everyone else used "Test" and if the parent pom.xml uses that pattern, too. > PR welcome on https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150123/d6ebfe11/attachment.html From max.andersen at redhat.com Fri Jan 23 08:38:51 2015 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Fri, 23 Jan 2015 14:38:51 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <54C154D2.5000505@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> Message-ID: <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> On 22 Jan 2015, at 20:51, Nick Boldt wrote: > You can set your own entries in your root pom. Then all your > projects' tests will inherit those new rules. the intent of the parent pom is to avoid we have unnecessary duplication and conflicting approaches. So better if we can fix the parent pom if its not optimal than continue to get different additional unnecessary testing configs in the various pom's. /max http://about.me/maxandersen From fbricon at redhat.com Fri Jan 23 08:54:43 2015 From: fbricon at redhat.com (Fred Bricon) Date: Fri, 23 Jan 2015 08:54:43 -0500 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> Message-ID: <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> I am so +? on dropping the current patterns I wonder if tycho?s default patterns are enough *Test*, *Test, *TestCase https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 1) abstract classes are not run by default. So if you called an AbstractFooTest class which is not abstract, it?s on you. 2) when Eclipse JUnit runner runs on a projects/packages, containing suites and individual classes, it?ll run tests from suites and ignore (duplicate) individual tests. If it?s a core JUnit feature, then it should behave the same in surefire. That needs to be verified obviously > Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen a ?crit : > > On 22 Jan 2015, at 20:51, Nick Boldt wrote: > >> You can set your own entries in your root pom. Then all your >> projects' tests will inherit those new rules. > > the intent of the parent pom is to avoid we have unnecessary duplication > and conflicting approaches. > > So better if we can fix the parent pom if its not optimal than continue > to get different > additional unnecessary testing configs in the various pom's. > > /max > 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/20150123/854d9b12/attachment-0001.html From p.g.richardson at redhat.com Fri Jan 23 08:58:23 2015 From: p.g.richardson at redhat.com (Paul Richardson) Date: Fri, 23 Jan 2015 13:58:23 +0000 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> Message-ID: <54C2537F.40508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/01/15 11:42, Max Rydahl Andersen wrote: >> > One drawback of not having testsuites is though that we loose the ability to easily run a > group of tests from eclipse or maven. > > Anyone found a good way of doing that via junit ? (testng has groups but tycho surefire/junit > does not support that afaik) Yes. Designer has had a test-aggregate plugin for all its junit tests for a while now. [1] Based on an idea from my last job, the TestDesignerTestGatherer[2] class is a junit 3 style test suite. It essentially runs through all the bundles in the running platfrom, searching for (in this case) AllTests classes then adds them to the suite. The suite is executed via junit and the all the tests individually executed. This works in both Eclipse (using a single junit launcher) and in maven (by making the plugin a test plugin and adding TestGatherer to an AllTests suite class). This mechanism can be easily generalised to work with different test names if preferred. PGR [1] https://github.com/Teiid-Designer/teiid-designer/tree/master/test-aggregate/org.teiid.designer.aggregate.test [2] https://github.com/Teiid-Designer/teiid-designer/blob/master/test-aggregate/org.teiid.designer.aggregate.test/src/org/teiid/designer/aggregate/test/TestDesignerTestGatherer.java - -- Paul Richardson * p.g.richardson at redhat.com * pgrichardson at linux.com * mob: +44 (0)9780 869490 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwlN3AAoJEG7P2ul73V7cyuwH/RDLXiY+pCDOqYei+9XEuiHj +Bjp7Gw8KX/n2H3CkkPkISXiB4shKfiO+KWIB7W5IqcgQH3RTQuUZ/EbXoZT1il9 oAc5nijf0tbR+FAUceWTK25U1DoVPYdpHWZRXOBJuZM6HDTWXhFZxEeC/tswm0J+ gf5KxSxmr7nDpToBRfnF/SHENixyqYkH4k/IEbL12v9tabk/kIgik8HL+baB1gwZ KkDGMltbhYHvVo79hQjQ3pERkJxAhPOttaiOkjPa2hczOJVbEbooIdg7dAdCXm7X qoltIi6imzjmGTSgmLqOU4euL6jq++OznPukpYNlubAZdmrn+LU5iNdcw/K8brg= =l3RV -----END PGP SIGNATURE----- From max.andersen at redhat.com Fri Jan 23 10:18:08 2015 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Fri, 23 Jan 2015 16:18:08 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? (was: JUnit Tests) In-Reply-To: <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> Message-ID: <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> On 23 Jan 2015, at 14:54, Fred Bricon wrote: > I am so +? on dropping the current patterns > > I wonder if tycho?s default patterns are enough *Test*, *Test, > *TestCase > https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 > > > 1) abstract classes are not run by default. So if you called an > AbstractFooTest class which is not abstract, it?s on you. > 2) when Eclipse JUnit runner runs on a projects/packages, containing > suites and individual classes, it?ll run tests from suites and > ignore (duplicate) individual tests. If it?s a core JUnit feature, > then it should behave the same in surefire. That needs to be verified > obviously Last I checked this surefire just uses the naming pattern - no smart filtering is done. The fact include/exclude is on *.class and not actual class/package names make me think that has not changed. /max > > >> Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen >> a ?crit : >> >> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >> >>> You can set your own entries in your root pom. Then all >>> your >>> projects' tests will inherit those new rules. >> >> the intent of the parent pom is to avoid we have unnecessary >> duplication >> and conflicting approaches. >> >> So better if we can fix the parent pom if its not optimal than >> continue >> to get different >> additional unnecessary testing configs in the various pom's. >> >> /max >> http://about.me/maxandersen >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen From max.andersen at redhat.com Fri Jan 23 10:31:43 2015 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Fri, 23 Jan 2015 16:31:43 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C2537F.40508@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C2537F.40508@redhat.com> Message-ID: <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> On 23 Jan 2015, at 14:58, Paul Richardson wrote: > On 23/01/15 11:42, Max Rydahl Andersen wrote: >>> >> One drawback of not having testsuites is though that we loose the >> ability to easily run a >> group of tests from eclipse or maven. >> >> Anyone found a good way of doing that via junit ? (testng has groups >> but tycho surefire/junit >> does not support that afaik) > > Yes. Designer has had a test-aggregate plugin for all its junit tests > for a while now. [1] > > Based on an idea from my last job, the TestDesignerTestGatherer[2] > class is a junit 3 style test > suite. > > It essentially runs through all the bundles in the running platfrom, > searching for (in this case) > AllTests classes then adds them to the suite. The suite is executed > via junit and the all the > tests individually executed. This works in both Eclipse (using a > single junit launcher) and in > maven (by making the plugin a test plugin and adding TestGatherer to > an AllTests suite class). I'm not following what this class helps do that surefire not already does ? How would this be used to group tests within the same test plugin into something I can run ? for me it looks like this one just picks up *all* test classes which is already possible today with junit launch to just have it run all tests found in a package or project ? /max > > This mechanism can be easily generalised to work with different test > names if preferred. > > PGR > > [1] > https://github.com/Teiid-Designer/teiid-designer/tree/master/test-aggregate/org.teiid.designer.aggregate.test > [2] > https://github.com/Teiid-Designer/teiid-designer/blob/master/test-aggregate/org.teiid.designer.aggregate.test/src/org/teiid/designer/aggregate/test/TestDesignerTestGatherer.java > > - -- > Paul Richardson > > * p.g.richardson at redhat.com > * pgrichardson at linux.com > * mob: +44 (0)9780 869490 /max http://about.me/maxandersen From p.g.richardson at redhat.com Fri Jan 23 11:52:16 2015 From: p.g.richardson at redhat.com (Paul Richardson) Date: Fri, 23 Jan 2015 16:52:16 +0000 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C2537F.40508@redhat.com> <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> Message-ID: <54C27C40.9030205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/01/15 15:31, Max Rydahl Andersen wrote: > On 23 Jan 2015, at 14:58, Paul Richardson wrote: > >> On 23/01/15 11:42, Max Rydahl Andersen wrote: >>>> >>> One drawback of not having testsuites is though that we loose the ability to easily run a >>> group of tests from eclipse or maven. >>> >>> Anyone found a good way of doing that via junit ? (testng has groups but tycho >>> surefire/junit does not support that afaik) >> >> Yes. Designer has had a test-aggregate plugin for all its junit tests for a while now. [1] >> >> Based on an idea from my last job, the TestDesignerTestGatherer[2] class is a junit 3 style >> test suite. >> >> It essentially runs through all the bundles in the running platfrom, searching for (in this >> case) AllTests classes then adds them to the suite. The suite is executed via junit and the >> all the tests individually executed. This works in both Eclipse (using a single junit >> launcher) and in maven (by making the plugin a test plugin and adding TestGatherer to an >> AllTests suite class). > > I'm not following what this class helps do that surefire not already does ? > > How would this be used to group tests within the same test plugin into something I can run ? Primarily the TestGatherer is meant for running tests while in Eclipse. It has the added benefit of grouping all the tests together when building with maven. So, this is what happens as it stands with the TestGatherer: * In Eclipse I have lots of plugins open and I want to run all unit tests in my workspace. * I create a junit-plugin launcher pointing to TestGatherer and execute it * TestGatherer brings up an eclipse test IDE and hunts for all 'AllTests' in the platform and executes them * In effect, I have run all the AllTest classes in the development IDE using 1 junit test suite, rather than having to run them individually. The added benefit of this test-aggregating was that maven could also just run this single test plugin rather than executing tests for all test plugins. When I developed TestGatherer, Designer builds in Jenkins kept failing during the testing phase due to a protocol error on the XVnc instance. If all test plugins brought up the XVnc instance then the build was successful. As an XVnc instance is required for each test plugin, I made all of our test plugins 'normal' plugins and only the aggregate-plugin (housing TestGatherer) a test plugin. Consequently, only 1 instance of XVnc is created when Jenkins builds/tests and is responsible for executing all the tests. This configuration for maven may not be appropriate for other projects but it certainly has been helpful in Designer development for running all tests in Eclipse. PGR - -- Paul Richardson * p.g.richardson at redhat.com * pgrichardson at linux.com * mob: +44 (0)9780 869490 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwnw3AAoJEG7P2ul73V7cicUIALJatrcc0DK26Y2XvGP751E9 B7ED1YcGtBefy4/7kuvynd40g/+gP/WzxxrMV491qLhojXNHmXkhCf4iHG6fG71v DmBbqKwfHwnFu2LnhBwryEgnY1Ud0TeNx0Yw8YayyCXAg7rrsBio7s0n7WcpYl1K tYb74ty/ZKpG3WQZnfzAOzWZccBWW3Kng4umo2dNfiLEAwS0ocs3FVpXoPWXdHU4 GH386XqJ0YcqHIiMZi7M1i3pnQIrpIwpJkhTblznAHlfqRcUVtq5jza7sK+/eJQy MTWbX1z4J649eByxyheT+ZucGDR0Hkw5TqEuJ8SlVkMHT/jW9hzhZbsI7Wa081k= =VIGO -----END PGP SIGNATURE----- From p.g.richardson at redhat.com Fri Jan 23 12:05:07 2015 From: p.g.richardson at redhat.com (Paul Richardson) Date: Fri, 23 Jan 2015 17:05:07 +0000 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C2537F.40508@redhat.com> <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> Message-ID: <54C27F43.2010901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/01/15 15:31, Max Rydahl Andersen wrote: > On 23 Jan 2015, at 14:58, Paul Richardson wrote: > >> On 23/01/15 11:42, Max Rydahl Andersen wrote: >>>> >>> One drawback of not having testsuites is though that we loose the ability to easily run a >>> group of tests from eclipse or maven. >>> >>> Anyone found a good way of doing that via junit ? (testng has groups but tycho >>> surefire/junit does not support that afaik) >> >> Yes. Designer has had a test-aggregate plugin for all its junit tests for a while now. [1] >> >> Based on an idea from my last job, the TestDesignerTestGatherer[2] class is a junit 3 style >> test suite. >> >> It essentially runs through all the bundles in the running platfrom, searching for (in this >> case) AllTests classes then adds them to the suite. The suite is executed via junit and the >> all the tests individually executed. This works in both Eclipse (using a single junit >> launcher) and in maven (by making the plugin a test plugin and adding TestGatherer to an >> AllTests suite class). > > I'm not following what this class helps do that surefire not already does ? > > How would this be used to group tests within the same test plugin into something I can run ? > > for me it looks like this one just picks up *all* test classes which is already possible today > with junit launch to just have it run all tests found in a package or project ? > In addition to my previous email, while I think a little further ... TestGatherer currently finds and matches classes with name 'AllTests' in the platform. This is just a constant that could be modified on a case by case basis. For example, it could be an argument set via the JUnit test launcher which matches a specific group of tests or even looks for an annotation inside classes. A configuration class could be added to specify the tests that should be executed on a bundle-by-bundle basis I suppose. My point is that TestGatherer being a java class that finds tests dynamically can be modified to suit individual use-cases. HTH PGR - -- Paul Richardson * p.g.richardson at redhat.com * pgrichardson at linux.com * mob: +44 (0)9780 869490 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUwn86AAoJEG7P2ul73V7c0hMH/A+sTWXOFtuVDYy0eB+e2Wyl GKKDrkG9YUfeRsx7dSv6lI/eWsipU5A+inZ1SojQJTfKNzeNeI8oF1OLza1Y42gk RLkr0zzzS1m7Hf3AduR/6nmi+fXCa6cNgOUhJLVHld6IdZHlYQyWmk6u4sYBV53E wNvjoM0Uay3Ycy4S9T47AtGjsouaunssGyIwcRzkb1DhNHYliZYXIfz8ucvZx3MB P7pLSftK6injSYancB2pWtsyxGvEo0GkKFxY/FpWpThIxyEVklRMbHdcNSA2VV4c OqPf4sM3O8ZgxoO35NPijEUNW+fmmmd8MYrAhxfd8Y9KRTWM8Li5gLpzifToD5M= =jjvq -----END PGP SIGNATURE----- From akazakov at exadel.com Fri Jan 23 13:19:17 2015 From: akazakov at exadel.com (Alexey Kazakov) Date: Fri, 23 Jan 2015 10:19:17 -0800 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> Message-ID: <54C290A5.2020700@exadel.com> On 01/23/2015 03:42 AM, Max Rydahl Andersen wrote: > But right now I think the only one I know that is pro-testsuites being > the default is Rob S. who have just > said he is fine switching to Tests being executed by default - he can > just use the TestSuite pattern in his test projects if he insists :) Most *Test.class tests (hundreds of them) in javaee and jst use a TestSetup. So a lot of our tests are grouped in their own test setups to configure a common environment. They are not designed to be executed as standalone tests because some their critical tierDown/setUp work is delegated to the corresponding TestSetup. If we move tierDown()/setUp() to the *Test.class level it will increase the execution time dramatically. Any idea how it could be fixed? Another problem is that we have a lot of *Test.class'es which are used as super classes for actual tests but they are not abstract. Which is not a big deal since most of them don't have any test methods and we also can make them abstract pretty easy. So, migrating javaee/jst/common to the *Test.class pattern may be a huge work. From fbricon at redhat.com Fri Jan 23 13:38:48 2015 From: fbricon at redhat.com (Fred Bricon) Date: Fri, 23 Jan 2015 13:38:48 -0500 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C290A5.2020700@exadel.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C290A5.2020700@exadel.com> Message-ID: For specific use cases like that, you can specifically override the include patterns used in javaee, effectively maintaining the legacy behavior, allowing you to migrate at the pace you want. Fred > Le 23 janv. 2015 ? 13:19, Alexey Kazakov a ?crit : > > On 01/23/2015 03:42 AM, Max Rydahl Andersen wrote: >> But right now I think the only one I know that is pro-testsuites being >> the default is Rob S. who have just >> said he is fine switching to Tests being executed by default - he can >> just use the TestSuite pattern in his test projects if he insists :) > > Most *Test.class tests (hundreds of them) in javaee and jst use a TestSetup. > So a lot of our tests are grouped in their own test setups to configure > a common environment. > They are not designed to be executed as standalone tests because some > their critical tierDown/setUp work is delegated to the corresponding > TestSetup. > If we move tierDown()/setUp() to the *Test.class level it will increase > the execution time dramatically. > Any idea how it could be fixed? > > Another problem is that we have a lot of *Test.class'es which are used > as super classes for actual tests but they are not abstract. > Which is not a big deal since most of them don't have any test methods > and we also can make them abstract pretty easy. > > So, migrating javaee/jst/common to the *Test.class pattern may be a huge > work. > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From nboldt at redhat.com Fri Jan 23 14:02:18 2015 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 23 Jan 2015 14:02:18 -0500 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> Message-ID: <54C29ABA.4000604@redhat.com> TL;DR: I think this is what we've said we should do: 1. Use new default patterns in parent pom for JBDS 9 (and 8.1 too): include = *Test*, *Test, *TestCase exclude = *Abstract* 2. If that causes test failures because running incorrectly named abstract stuff, they can refactor, add their own root pom overrides, use a TestSuite, or use @Ignore in test classes. 3. If the count of tests run suddenly DROPS because the pattern isn't running the correct # of tests, they can add their own root pom overrides, or use a TestSuite. So say we all? N On 01/23/2015 10:18 AM, Max Rydahl Andersen wrote: > On 23 Jan 2015, at 14:54, Fred Bricon wrote: > >> I am so +? on dropping the current patterns >> >> I wonder if tycho?s default patterns are enough *Test*, *Test, >> *TestCase >> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 >> >> >> 1) abstract classes are not run by default. So if you called an >> AbstractFooTest class which is not abstract, it?s on you. >> 2) when Eclipse JUnit runner runs on a projects/packages, containing >> suites and individual classes, it?ll run tests from suites and >> ignore (duplicate) individual tests. If it?s a core JUnit feature, >> then it should behave the same in surefire. That needs to be verified >> obviously > > Last I checked this surefire just uses the naming pattern - no smart > filtering is done. > > The fact include/exclude is on *.class and not actual class/package > names make me think that has not changed. > > > /max > >> >> >>> Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen >>> a ?crit : >>> >>> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >>> >>>> You can set your own entries in your root pom. Then all >>>> your >>>> projects' tests will inherit those new rules. >>> >>> the intent of the parent pom is to avoid we have unnecessary >>> duplication >>> and conflicting approaches. >>> >>> So better if we can fix the parent pom if its not optimal than >>> continue >>> to get different >>> additional unnecessary testing configs in the various pom's. >>> >>> /max >>> http://about.me/maxandersen >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > /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 akazakov at exadel.com Fri Jan 23 14:08:55 2015 From: akazakov at exadel.com (Alexey Kazakov) Date: Fri, 23 Jan 2015 11:08:55 -0800 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C29ABA.4000604@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> <54C29ABA.4000604@redhat.com> Message-ID: <54C29C47.5050508@exadel.com> On 01/23/2015 11:02 AM, Nick Boldt wrote: > TL;DR: > > I think this is what we've said we should do: > > 1. Use new default patterns in parent pom for JBDS 9 (and 8.1 too): Let's do it for 9 (master) only. > > include = *Test*, *Test, *TestCase > exclude = *Abstract* > > 2. If that causes test failures because running incorrectly named > abstract stuff, they can refactor, add their own root pom overrides, use > a TestSuite, or use @Ignore in test classes. > > 3. If the count of tests run suddenly DROPS because the pattern isn't > running the correct # of tests, they can add their own root pom > overrides, or use a TestSuite. > > So say we all? > > N > > On 01/23/2015 10:18 AM, Max Rydahl Andersen wrote: >> On 23 Jan 2015, at 14:54, Fred Bricon wrote: >> >>> I am so +? on dropping the current patterns >>> >>> I wonder if tycho?s default patterns are enough *Test*, *Test, >>> *TestCase >>> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 >>> >>> >>> 1) abstract classes are not run by default. So if you called an >>> AbstractFooTest class which is not abstract, it?s on you. >>> 2) when Eclipse JUnit runner runs on a projects/packages, containing >>> suites and individual classes, it?ll run tests from suites and >>> ignore (duplicate) individual tests. If it?s a core JUnit feature, >>> then it should behave the same in surefire. That needs to be verified >>> obviously >> Last I checked this surefire just uses the naming pattern - no smart >> filtering is done. >> >> The fact include/exclude is on *.class and not actual class/package >> names make me think that has not changed. >> >> >> /max >> >>> >>>> Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen >>>> a ?crit : >>>> >>>> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >>>> >>>>> You can set your own entries in your root pom. Then all >>>>> your >>>>> projects' tests will inherit those new rules. >>>> the intent of the parent pom is to avoid we have unnecessary >>>> duplication >>>> and conflicting approaches. >>>> >>>> So better if we can fix the parent pom if its not optimal than >>>> continue >>>> to get different >>>> additional unnecessary testing configs in the various pom's. >>>> >>>> /max >>>> http://about.me/maxandersen >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> /max >> http://about.me/maxandersen >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> From nboldt at redhat.com Fri Jan 23 14:37:42 2015 From: nboldt at redhat.com (Nick Boldt) Date: Fri, 23 Jan 2015 14:37:42 -0500 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C29C47.5050508@exadel.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> <54C29ABA.4000604@redhat.com> <54C29C47.5050508@exadel.com> Message-ID: <54C2A306.7030800@redhat.com> PR attached to a JIRA: https://issues.jboss.org/browse/JBIDE-19081 https://github.com/jbosstools/jbosstools-build/pull/167 Should we also exclude (by default) running integration tests? If so, what pattern should be excluded? *ITest*.class? *IntegrationTest*.class? N On 01/23/2015 02:08 PM, Alexey Kazakov wrote: > On 01/23/2015 11:02 AM, Nick Boldt wrote: >> TL;DR: >> >> I think this is what we've said we should do: >> >> 1. Use new default patterns in parent pom for JBDS 9 (and 8.1 too): > > Let's do it for 9 (master) only. > >> >> include = *Test*, *Test, *TestCase >> exclude = *Abstract* >> >> 2. If that causes test failures because running incorrectly named >> abstract stuff, they can refactor, add their own root pom overrides, use >> a TestSuite, or use @Ignore in test classes. >> >> 3. If the count of tests run suddenly DROPS because the pattern isn't >> running the correct # of tests, they can add their own root pom >> overrides, or use a TestSuite. >> >> So say we all? >> >> N >> >> On 01/23/2015 10:18 AM, Max Rydahl Andersen wrote: >>> On 23 Jan 2015, at 14:54, Fred Bricon wrote: >>> >>>> I am so +? on dropping the current patterns >>>> >>>> I wonder if tycho?s default patterns are enough *Test*, *Test, >>>> *TestCase >>>> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 >>>> >>>> >>>> 1) abstract classes are not run by default. So if you called an >>>> AbstractFooTest class which is not abstract, it?s on you. >>>> 2) when Eclipse JUnit runner runs on a projects/packages, containing >>>> suites and individual classes, it?ll run tests from suites and >>>> ignore (duplicate) individual tests. If it?s a core JUnit feature, >>>> then it should behave the same in surefire. That needs to be verified >>>> obviously >>> Last I checked this surefire just uses the naming pattern - no smart >>> filtering is done. >>> >>> The fact include/exclude is on *.class and not actual class/package >>> names make me think that has not changed. >>> >>> >>> /max >>> >>>> >>>>> Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen >>>>> a ?crit : >>>>> >>>>> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >>>>> >>>>>> You can set your own entries in your root pom. Then all >>>>>> your >>>>>> projects' tests will inherit those new rules. >>>>> the intent of the parent pom is to avoid we have unnecessary >>>>> duplication >>>>> and conflicting approaches. >>>>> >>>>> So better if we can fix the parent pom if its not optimal than >>>>> continue >>>>> to get different >>>>> additional unnecessary testing configs in the various pom's. >>>>> >>>>> /max >>>>> http://about.me/maxandersen >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >>> /max >>> http://about.me/maxandersen >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From manderse at redhat.com Sat Jan 24 09:51:23 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sat, 24 Jan 2015 09:51:23 -0500 (EST) Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C2A306.7030800@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> <54C29ABA.4000604@redhat.com> <54C29C47.5050508@exadel.com> <54C2A306.7030800@redhat.com> Message-ID: <262A8751-BC8F-4E76-BAF0-D83D5D28989D@redhat.com> No. we never want to exclude integration tests by default. The intent is to have all tests run by default and allow easy way to disable it. That is why we have recommendation to have itests as seperate project/dir. /max http://about.me/maxandersen > On 23 Jan 2015, at 20:37, Nick Boldt wrote: > > PR attached to a JIRA: > > https://issues.jboss.org/browse/JBIDE-19081 > https://github.com/jbosstools/jbosstools-build/pull/167 > > Should we also exclude (by default) running integration tests? If so, > what pattern should be excluded? *ITest*.class? *IntegrationTest*.class? > > N > >> On 01/23/2015 02:08 PM, Alexey Kazakov wrote: >>> On 01/23/2015 11:02 AM, Nick Boldt wrote: >>> TL;DR: >>> >>> I think this is what we've said we should do: >>> >>> 1. Use new default patterns in parent pom for JBDS 9 (and 8.1 too): >> >> Let's do it for 9 (master) only. >> >>> >>> include = *Test*, *Test, *TestCase >>> exclude = *Abstract* >>> >>> 2. If that causes test failures because running incorrectly named >>> abstract stuff, they can refactor, add their own root pom overrides, use >>> a TestSuite, or use @Ignore in test classes. >>> >>> 3. If the count of tests run suddenly DROPS because the pattern isn't >>> running the correct # of tests, they can add their own root pom >>> overrides, or use a TestSuite. >>> >>> So say we all? >>> >>> N >>> >>>> On 01/23/2015 10:18 AM, Max Rydahl Andersen wrote: >>>>> On 23 Jan 2015, at 14:54, Fred Bricon wrote: >>>>> >>>>> I am so +? on dropping the current patterns >>>>> >>>>> I wonder if tycho?s default patterns are enough *Test*, *Test, >>>>> *TestCase >>>>> https://git.eclipse.org/c/tycho/org.eclipse.tycho.git/tree/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestMojo.java#n149 >>>>> >>>>> >>>>> 1) abstract classes are not run by default. So if you called an >>>>> AbstractFooTest class which is not abstract, it?s on you. >>>>> 2) when Eclipse JUnit runner runs on a projects/packages, containing >>>>> suites and individual classes, it?ll run tests from suites and >>>>> ignore (duplicate) individual tests. If it?s a core JUnit feature, >>>>> then it should behave the same in surefire. That needs to be verified >>>>> obviously >>>> Last I checked this surefire just uses the naming pattern - no smart >>>> filtering is done. >>>> >>>> The fact include/exclude is on *.class and not actual class/package >>>> names make me think that has not changed. >>>> >>>> >>>> /max >>>> >>>>> >>>>>> Le 23 janv. 2015 ? 08:38, Max Rydahl Andersen >>>>>> a ?crit : >>>>>> >>>>>>> On 22 Jan 2015, at 20:51, Nick Boldt wrote: >>>>>>> >>>>>>> You can set your own entries in your root pom. Then all >>>>>>> your >>>>>>> projects' tests will inherit those new rules. >>>>>> the intent of the parent pom is to avoid we have unnecessary >>>>>> duplication >>>>>> and conflicting approaches. >>>>>> >>>>>> So better if we can fix the parent pom if its not optimal than >>>>>> continue >>>>>> to get different >>>>>> additional unnecessary testing configs in the various pom's. >>>>>> >>>>>> /max >>>>>> http://about.me/maxandersen >>>>>> _______________________________________________ >>>>>> jbosstools-dev mailing list >>>>>> jbosstools-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >>>> /max >>>> http://about.me/maxandersen >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From manderse at redhat.com Sat Jan 24 09:51:44 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sat, 24 Jan 2015 09:51:44 -0500 (EST) Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C29C47.5050508@exadel.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <94D2B634-38A3-4A1B-B225-149A837346B1@redhat.com> <8FCD7EE1-5C92-49D5-B1F2-E53924306A84@redhat.com> <4C168C2C-04A8-4B4F-BB17-D0263D4735A5@redhat.com> <54C29ABA.4000604@redhat.com> <54C29C47.5050508@exadel.com> Message-ID: <9DA73865-2958-45AD-BB88-7EEEB8F95B75@redhat.com> > On 23 Jan 2015, at 20:09, Alexey Kazakov wrote: > > Let's do it for 9 (master) only +1 From manderse at redhat.com Sat Jan 24 09:53:35 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Sat, 24 Jan 2015 09:53:35 -0500 (EST) Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C290A5.2020700@exadel.com> Message-ID: I agree with Fred here but alexeys usecase/question is valid. I guess naming them something like TestPart.java instead would be sensible or simply put the tests depedent on exact setup be in same class ? /max http://about.me/maxandersen > On 23 Jan 2015, at 19:39, Fred Bricon wrote: > > For specific use cases like that, you can specifically override the include patterns used in javaee, effectively maintaining the legacy behavior, allowing you to migrate at the pace you want. > > Fred > >> Le 23 janv. 2015 ? 13:19, Alexey Kazakov a ?crit : >> >> On 01/23/2015 03:42 AM, Max Rydahl Andersen wrote: >>> But right now I think the only one I know that is pro-testsuites being >>> the default is Rob S. who have just >>> said he is fine switching to Tests being executed by default - he can >>> just use the TestSuite pattern in his test projects if he insists :) >> >> Most *Test.class tests (hundreds of them) in javaee and jst use a TestSetup. >> So a lot of our tests are grouped in their own test setups to configure >> a common environment. >> They are not designed to be executed as standalone tests because some >> their critical tierDown/setUp work is delegated to the corresponding >> TestSetup. >> If we move tierDown()/setUp() to the *Test.class level it will increase >> the execution time dramatically. >> Any idea how it could be fixed? >> >> Another problem is that we have a lot of *Test.class'es which are used >> as super classes for actual tests but they are not abstract. >> Which is not a big deal since most of them don't have any test methods >> and we also can make them abstract pretty easy. >> >> So, migrating javaee/jst/common to the *Test.class pattern may be a huge >> work. >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From max.andersen at redhat.com Mon Jan 26 07:21:37 2015 From: max.andersen at redhat.com (Max Rydahl Andersen) Date: Mon, 26 Jan 2015 13:21:37 +0100 Subject: [jbosstools-dev] Should we use @Ignore in non-runnable JUnit test classes, instead of in pom? In-Reply-To: <54C27C40.9030205@redhat.com> References: <1791801719.16467973.1421953691182.JavaMail.zimbra@redhat.com> <54C154D2.5000505@redhat.com> <0719EE85-C077-4EBC-9C20-7EE70F79909A@redhat.com> <7CC29ACF-7A98-4E80-82C3-D0664922BCF3@redhat.com> <54C2537F.40508@redhat.com> <53504C39-A796-430D-8C1A-ABFD91B4F5C9@redhat.com> <54C27C40.9030205@redhat.com> Message-ID: <84B38C13-E30D-424D-9575-9CE7A32ED0AF@redhat.com> >>> It essentially runs through all the bundles in the running platfrom, >>> searching for (in this >>> case) AllTests classes then adds them to the suite. The suite is >>> executed via junit and the >>> all the tests individually executed. This works in both Eclipse >>> (using a single junit >>> launcher) and in maven (by making the plugin a test plugin and >>> adding TestGatherer to an >>> AllTests suite class). >> >> I'm not following what this class helps do that surefire not already >> does ? >> >> How would this be used to group tests within the same test plugin >> into something I can run ? > > Primarily the TestGatherer is meant for running tests while in > Eclipse. It has the added benefit of > grouping all the tests together when building with maven. ...but with the disadvantage that if you are running multiple projects tests you will now have things grouped together one might not want grouped together. > So, this is what happens as it stands with the TestGatherer: > * In Eclipse I have lots of plugins open and I want to run all unit > tests in my workspace. > * I create a junit-plugin launcher pointing to TestGatherer and > execute it > * TestGatherer brings up an eclipse test IDE and hunts for all > 'AllTests' in the platform and > executes them > * In effect, I have run all the AllTest classes in the development IDE > using 1 junit test suite, > rather than having to run them individually. Okey - now I get the use of it. You can do the same in plain eclipse today, but only for one project at a time. > The added benefit of this test-aggregating was that maven could also > just run this single test plugin > rather than executing tests for all test plugins. That then assumes zero preparation is needed for the tests by the mvn build...we got builds that download runtimes which is done by the mvn build not the tests them self. > When I developed TestGatherer, Designer builds in Jenkins kept failing > during the testing phase > due to a protocol error on the XVnc instance. If all test plugins > brought up the XVnc instance > then the build was successful. > As an XVnc instance is required for each test plugin, I made all of > our test plugins 'normal' > plugins and only the aggregate-plugin (housing TestGatherer) a test > plugin. Consequently, > only 1 instance of XVnc is created when Jenkins builds/tests and is > responsible for executing > all the tests. I *think* that issue is solved today... > This configuration for maven may not be appropriate for other projects > but it certainly has been > helpful in Designer development for running all tests in Eclipse. yeah, I grok its use now, but it doesn't allow grouping of tests..unless you call "everything in one group" for grouping :) /max > PGR > > - -- > Paul Richardson > > * p.g.richardson at redhat.com > * pgrichardson at linux.com > * mob: +44 (0)9780 869490 /max http://about.me/maxandersen From nboldt at redhat.com Mon Jan 26 11:34:10 2015 From: nboldt at redhat.com (Nick Boldt) Date: Mon, 26 Jan 2015 11:34:10 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: Upversion needed in Central, VPE, Base, Openshift, and Forge Message-ID: <54C66C82.9020201@redhat.com> Our Version Watch tool is failing in the master branch (JBT 4.3 / JBDS 9.0), because there are a number of projects whose plugins/features have lower versions than those released in JBT 4.2.2 / 8.0.2. Please fix this ASAP. Affected projects include: Central/Maven - https://issues.jboss.org/browse/JBIDE-19073 VPE - https://issues.jboss.org/browse/JBIDE-19074 Base - https://issues.jboss.org/browse/JBIDE-19075 OpenShift - https://issues.jboss.org/browse/JBIDE-19076 Forge - https://issues.jboss.org/browse/JBIDE-19077 887 org.jboss.tools.forge.feature,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 887 org.jboss.tools.forge.m2e.feature,1.1.1 from jbds-9.0.0.Alpha1 Version must be higher 888 org.jboss.tools.foundation.feature,1.1.0 from jbds-9.0.0.Alpha1 Version must be higher 888 org.jboss.tools.foundation.security.linux.feature,1.1.0 from jbds-9.0.0.Alpha1 Version must be higher 889 org.jboss.tools.maven.cdi.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 890 org.jboss.tools.maven.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 890 org.jboss.tools.maven.hibernate.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 890 org.jboss.tools.maven.jdt.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 891 org.jboss.tools.maven.portlet.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 892 org.jboss.tools.maven.sourcelookup.feature,1.6.0 from jbds-9.0.0.Alpha1 Version must be higher 892 org.jboss.tools.openshift.egit.integration.feature,2.6.0 from jbds-9.0.0.Alpha1 Version must be higher 892 org.jboss.tools.openshift.express.feature,2.6.0 from jbds-9.0.0.Alpha1 Version must be higher 893 org.jboss.tools.stacks.core.feature,1.1.0 from jbds-9.0.0.Alpha1 Version must be higher 894 org.jboss.tools.vpe.browsersim.feature,3.6.0 from jbds-9.0.0.Alpha1 Version must be higher 894 org.jboss.tools.vpe.feature,3.6.0 from jbds-9.0.0.Alpha1 Version must be higher 894 org.jboss.tools.vpe.preview.feature,3.6.0 from jbds-9.0.0.Alpha1 Version must be higher 992 org.jboss.tools.aesh.core,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 992 org.jboss.tools.aesh.ui,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 998 org.jboss.tools.forge.core,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 998 org.jboss.tools.forge.m2e,1.1.1 from jbds-9.0.0.Alpha1 Version must be higher 999 org.jboss.tools.forge.runtime.ext,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 999 org.jboss.tools.forge.ui,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher 999 org.jboss.tools.forge.ui.notifications,1.3.1 from jbds-9.0.0.Alpha1 Version must be higher More: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/devstudio.versionwatch_master/1777/console -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From manderse at redhat.com Tue Jan 27 07:20:38 2015 From: manderse at redhat.com (manderse at redhat.com) Date: Tue, 27 Jan 2015 07:20:38 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: 1 issue with no component Message-ID: <201501271220.t0RCKcMD032690@int-mx11.intmail.prod.int.phx2.redhat.com> This email is the result of a query to locate stalled/invalid jiras. Please fix them. Thanks! * No component for JBIDE-19085 https://issues.jboss.org/browse/JBIDE-19085 Summary: tools.jboss.org devstudio downloads does not mention it is update site content only and to use 8.0.0 installer Assignee: None set - please fix. Component: None set - please fix. Problem: No component - please assign this issue to one or more components. Last Update: 1 day, 4:48:36.968043 ---------------------------- Query used: https://issues.jboss.org/issues/?jql=filter%3D%27ds_lint_nocomponent%27 From dgolovin at exadel.com Tue Jan 27 14:40:14 2015 From: dgolovin at exadel.com (Denis Golovin) Date: Tue, 27 Jan 2015 11:40:14 -0800 Subject: [jbosstools-dev] Broken build in jbosstools-4.2.x branch Message-ID: <54C7E99E.1070307@exadel.com> Fred, Rob, Nick could you take a look at build problem below. It feels like there are some problem with references. Thanks Denis Part of the output: [INFO] [INFO] Resolving dependencies of MavenProject: org.jboss.tools.as.plugins:org.jboss.ide.eclipse.as.jmx.integration:3.0.1-SNAPSHOT @ /home/eskimo/data/Projects/jbdevstudio/4.2.x/up/jbosstools-server/as/plugins/org.jboss.ide.eclipse.as.jmx.integration/pom.xml [INFO] [INFO] Cannot complete the request. Generating details. [INFO] [INFO] Cannot complete the request. Generating details. [INFO] [INFO] {osgi.ws=cocoa, osgi.os=macosx, osgi.arch=x86, org.eclipse.update.install.features=true} [INFO] [ERROR] Cannot resolve project dependencies: [INFO] [ERROR] Software being installed: org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier [INFO] [ERROR] Missing requirement: org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier requires 'bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0' but it could not be found [INFO] [ERROR] [INFO] [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the problem is unsatisfiable.] -> [Help 1] [INFO] org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the problem is unsatisfiable.] [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [INFO] at java.lang.reflect.Method.invoke(Method.java:606) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) [INFO] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) [INFO] Caused by: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the problem is unsatisfiable.] [INFO] at org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98) [INFO] at org.eclipse.tycho.p2.util.resolution.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88) [INFO] at org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63) [INFO] at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:166) [INFO] at org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103) [INFO] at org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352) [INFO] at org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325) [INFO] at org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107) [INFO] at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) [INFO] ... 11 more [INFO] [ERROR] [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [INFO] [ERROR] [INFO] [ERROR] For more information about the errors and possible solutions, please read the following articles: [INFO] [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException [INFO] ..FAILED (71.2 s) From nboldt at redhat.com Tue Jan 27 15:14:26 2015 From: nboldt at redhat.com (Nick Boldt) Date: Tue, 27 Jan 2015 15:14:26 -0500 Subject: [jbosstools-dev] Broken build in jbosstools-4.2.x branch In-Reply-To: <54C7E99E.1070307@exadel.com> References: <54C7E99E.1070307@exadel.com> Message-ID: <54C7F1A2.5040307@redhat.com> This should fix it: https://github.com/jbosstools/jbosstools-server/pull/321 Problem is depending on v1.7.0 only works in master branch; in 4.2.x you want either 1.6.1 or no version. Rob, I'll let you decide what's better. N On 01/27/2015 02:40 PM, Denis Golovin wrote: > Fred, Rob, Nick > > could you take a look at build problem below. It feels like there are > some problem with references. > > Thanks > Denis > > Part of the output: > > [INFO] [INFO] Resolving dependencies of MavenProject: > org.jboss.tools.as.plugins:org.jboss.ide.eclipse.as.jmx.integration:3.0.1-SNAPSHOT > @ > /home/eskimo/data/Projects/jbdevstudio/4.2.x/up/jbosstools-server/as/plugins/org.jboss.ide.eclipse.as.jmx.integration/pom.xml > > [INFO] [INFO] Cannot complete the request. Generating details. > [INFO] [INFO] Cannot complete the request. Generating details. > [INFO] [INFO] {osgi.ws=cocoa, osgi.os=macosx, osgi.arch=x86, > org.eclipse.update.install.features=true} > [INFO] [ERROR] Cannot resolve project dependencies: > [INFO] [ERROR] Software being installed: > org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier > [INFO] [ERROR] Missing requirement: > org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier requires > 'bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0' but it could not be found > [INFO] [ERROR] > [INFO] [ERROR] Internal error: java.lang.RuntimeException: No solution > found because the problem is unsatisfiable.: [Unable to satisfy > dependency from org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier > to bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found > because the problem is unsatisfiable.] -> [Help 1] > [INFO] org.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: No solution found because the problem is > unsatisfiable.: [Unable to satisfy dependency from > org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle > org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the > problem is unsatisfiable.] > [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) > [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) > [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [INFO] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > [INFO] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [INFO] at java.lang.reflect.Method.invoke(Method.java:606) > [INFO] at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > > [INFO] at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > [INFO] at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > > [INFO] at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > [INFO] Caused by: java.lang.RuntimeException: No solution found because > the problem is unsatisfiable.: [Unable to satisfy dependency from > org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle > org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the > problem is unsatisfiable.] > [INFO] at > org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98) > > [INFO] at > org.eclipse.tycho.p2.util.resolution.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88) > > [INFO] at > org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63) > > [INFO] at > org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:166) > > [INFO] at > org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103) > > [INFO] at > org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352) > > [INFO] at > org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325) > > [INFO] at > org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107) > > [INFO] at > org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75) > > [INFO] at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) > [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) > [INFO] ... 11 more > [INFO] [ERROR] > [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven > with the -e switch. > [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug > logging. > [INFO] [ERROR] > [INFO] [ERROR] For more information about the errors and possible > solutions, please read the following articles: > [INFO] [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException > [INFO] ..FAILED (71.2 s) > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From manderse at redhat.com Wed Jan 28 03:44:37 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 28 Jan 2015 03:44:37 -0500 (EST) Subject: [jbosstools-dev] Broken build in jbosstools-4.2.x branch In-Reply-To: <54C7F1A2.5040307@redhat.com> References: <54C7E99E.1070307@exadel.com> <54C7F1A2.5040307@redhat.com> Message-ID: A reminder on how if one want to be sure to build correctly locally that one either uses different m2 repos or set -Dtycho.localartifacts=ignore to avoid the streams to cross! /max http://about.me/maxandersen > On 27 Jan 2015, at 21:14, Nick Boldt wrote: > > This should fix it: > > https://github.com/jbosstools/jbosstools-server/pull/321 > > Problem is depending on v1.7.0 only works in master branch; in 4.2.x you > want either 1.6.1 or no version. Rob, I'll let you decide what's better. > > N > >> On 01/27/2015 02:40 PM, Denis Golovin wrote: >> Fred, Rob, Nick >> >> could you take a look at build problem below. It feels like there are >> some problem with references. >> >> Thanks >> Denis >> >> Part of the output: >> >> [INFO] [INFO] Resolving dependencies of MavenProject: >> org.jboss.tools.as.plugins:org.jboss.ide.eclipse.as.jmx.integration:3.0.1-SNAPSHOT >> @ >> /home/eskimo/data/Projects/jbdevstudio/4.2.x/up/jbosstools-server/as/plugins/org.jboss.ide.eclipse.as.jmx.integration/pom.xml >> >> [INFO] [INFO] Cannot complete the request. Generating details. >> [INFO] [INFO] Cannot complete the request. Generating details. >> [INFO] [INFO] {osgi.ws=cocoa, osgi.os=macosx, osgi.arch=x86, >> org.eclipse.update.install.features=true} >> [INFO] [ERROR] Cannot resolve project dependencies: >> [INFO] [ERROR] Software being installed: >> org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier >> [INFO] [ERROR] Missing requirement: >> org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier requires >> 'bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0' but it could not be found >> [INFO] [ERROR] >> [INFO] [ERROR] Internal error: java.lang.RuntimeException: No solution >> found because the problem is unsatisfiable.: [Unable to satisfy >> dependency from org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier >> to bundle org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found >> because the problem is unsatisfiable.] -> [Help 1] >> [INFO] org.apache.maven.InternalErrorException: Internal error: >> java.lang.RuntimeException: No solution found because the problem is >> unsatisfiable.: [Unable to satisfy dependency from >> org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle >> org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the >> problem is unsatisfiable.] >> [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) >> [INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582) >> [INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) >> [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) >> [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> [INFO] at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> >> [INFO] at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> [INFO] at java.lang.reflect.Method.invoke(Method.java:606) >> [INFO] at >> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) >> >> [INFO] at >> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) >> [INFO] at >> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) >> >> [INFO] at >> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) >> [INFO] Caused by: java.lang.RuntimeException: No solution found because >> the problem is unsatisfiable.: [Unable to satisfy dependency from >> org.jboss.ide.eclipse.as.jmx.integration 3.0.1.qualifier to bundle >> org.jboss.tools.jmx.jvmmonitor.ui 1.7.0.; No solution found because the >> problem is unsatisfiable.] >> [INFO] at >> org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.newResolutionException(AbstractResolutionStrategy.java:98) >> >> [INFO] at >> org.eclipse.tycho.p2.util.resolution.ProjectorResolutionStrategy.resolve(ProjectorResolutionStrategy.java:88) >> >> [INFO] at >> org.eclipse.tycho.p2.util.resolution.AbstractResolutionStrategy.resolve(AbstractResolutionStrategy.java:63) >> >> [INFO] at >> org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:166) >> >> [INFO] at >> org.eclipse.tycho.p2.resolver.P2ResolverImpl.resolveDependencies(P2ResolverImpl.java:103) >> >> [INFO] at >> org.eclipse.tycho.p2.resolver.P2DependencyResolver.doResolveDependencies(P2DependencyResolver.java:352) >> >> [INFO] at >> org.eclipse.tycho.p2.resolver.P2DependencyResolver.resolveDependencies(P2DependencyResolver.java:325) >> >> [INFO] at >> org.eclipse.tycho.core.resolver.DefaultTychoResolver.resolveProject(DefaultTychoResolver.java:107) >> >> [INFO] at >> org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:75) >> >> [INFO] at >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:310) >> [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154) >> [INFO] ... 11 more >> [INFO] [ERROR] >> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven >> with the -e switch. >> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug >> logging. >> [INFO] [ERROR] >> [INFO] [ERROR] For more information about the errors and possible >> solutions, please read the following articles: >> [INFO] [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException >> [INFO] ..FAILED (71.2 s) >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev From pleacu at redhat.com Wed Jan 28 09:25:27 2015 From: pleacu at redhat.com (Paul Leacu) Date: Wed, 28 Jan 2015 09:25:27 -0500 (EST) Subject: [jbosstools-dev] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <307033272.1909599.1422454724705.JavaMail.zimbra@redhat.com> Message-ID: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> Greetings - A proposal to change the JBTIS target platform is described here: https://issues.jboss.org/browse/JBTIS-382 PR: https://github.com/jbosstools/jbosstools-integration-stack/pull/280 Synopsis: 1. Split the JBTIS target platform along release/final and non-release/early access lines so as to not expose non .Final features to the stable capture that appears when performing an 'uncategorized' install. No dependent component version change from 4.2.0.Final. http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ Please respond by COB on Thursday, Jan 29 to the specified Jira if there are any issues. Thanks, --paull From rcernich at redhat.com Wed Jan 28 09:32:26 2015 From: rcernich at redhat.com (Rob Cernich) Date: Wed, 28 Jan 2015 09:32:26 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> Message-ID: <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> I think the better solution is to remove product bits from the TP and have them included directly through the site/p2 repo. Splitting up the TP is likely to cause issues down, especially as versions change. Also, I assume this is for product bits and not community bits (i.e. JBDS-IS vs JBTIS). ----- Original Message ----- > > Greetings - > A proposal to change the JBTIS target platform is described here: > > https://issues.jboss.org/browse/JBTIS-382 > > PR: https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > > Synopsis: > > 1. Split the JBTIS target platform along release/final and > non-release/early access lines > so as to not expose non .Final features to the stable capture that > appears when performing > an 'uncategorized' install. No dependent component version change from > 4.2.0.Final. > > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > > Please respond by COB on Thursday, Jan 29 to the specified Jira if there > are any issues. > > Thanks, > --paull > > _______________________________________________ > Soa-tools-list mailing list > Soa-tools-list at redhat.com > https://www.redhat.com/mailman/listinfo/soa-tools-list > From pleacu at redhat.com Wed Jan 28 09:51:59 2015 From: pleacu at redhat.com (Paul Leacu) Date: Wed, 28 Jan 2015 09:51:59 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> Message-ID: <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> Hey Rob, I'd love to remove product bits from the TP but that hasn't happened. Having a release based JBTIS TP that is guaranteed to have only .Final components and then having an early-access TP seems to give component developers the option of adding non fully released dependencies that are not our own product bits while their component is still in Beta. The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers could use either with 4.2.1.EA being the full set of dependencies. We can revisit removing the JBoss product bits from the TP but for the JDV release this change removes uncategorized non .Final bits that's needed now. --paull ----- Original Message ----- > From: "Rob Cernich" > To: "Paul Leacu" > Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" , "jbosstools-dev jbosstools-dev" > > Sent: Wednesday, January 28, 2015 9:32:26 AM > Subject: Re: [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA > > I think the better solution is to remove product bits from the TP and have > them included directly through the site/p2 repo. Splitting up the TP is > likely to cause issues down, especially as versions change. Also, I assume > this is for product bits and not community bits (i.e. JBDS-IS vs JBTIS). > > ----- Original Message ----- > > > > Greetings - > > A proposal to change the JBTIS target platform is described here: > > > > https://issues.jboss.org/browse/JBTIS-382 > > > > PR: https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > > > > Synopsis: > > > > 1. Split the JBTIS target platform along release/final and > > non-release/early access lines > > so as to not expose non .Final features to the stable capture that > > appears when performing > > an 'uncategorized' install. No dependent component version change > > from > > 4.2.0.Final. > > > > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > > > > Please respond by COB on Thursday, Jan 29 to the specified Jira if there > > are any issues. > > > > Thanks, > > --paull > > > > _______________________________________________ > > Soa-tools-list mailing list > > Soa-tools-list at redhat.com > > https://www.redhat.com/mailman/listinfo/soa-tools-list > > > From manderse at redhat.com Wed Jan 28 10:25:18 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 28 Jan 2015 16:25:18 +0100 Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> Message-ID: <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> i'm a bit confused what is it you consider product bits in the TP here ? I'm not seeing any in here - am I missing something ? I believe this change is done to ensure we don't leak in bad dependencies between the earlyaccess site that exists in both community and product shipment. /max > Hey Rob, > > I'd love to remove product bits from the TP but that hasn't happened. > Having > a release based JBTIS TP that is guaranteed to have only .Final > components and > then having an early-access TP seems to give component developers the > option of > adding non fully released dependencies that are not our own product > bits while > their component is still in Beta. > > The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers > could use either > with 4.2.1.EA being the full set of dependencies. > > We can revisit removing the JBoss product bits from the TP but for the > JDV release > this change removes uncategorized non .Final bits that's needed now. > > --paull > > ----- Original Message ----- >> From: "Rob Cernich" >> To: "Paul Leacu" >> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" >> , "jbosstools-dev jbosstools-dev" >> >> Sent: Wednesday, January 28, 2015 9:32:26 AM >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target >> platform - 4.2.1.Final/ 4.2.1.EA >> >> I think the better solution is to remove product bits from the TP and >> have >> them included directly through the site/p2 repo. Splitting up the TP >> is >> likely to cause issues down, especially as versions change. Also, I >> assume >> this is for product bits and not community bits (i.e. JBDS-IS vs >> JBTIS). >> >> ----- Original Message ----- >>> >>> Greetings - >>> A proposal to change the JBTIS target platform is described here: >>> >>> https://issues.jboss.org/browse/JBTIS-382 >>> >>> PR: >>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 >>> >>> Synopsis: >>> >>> 1. Split the JBTIS target platform along release/final and >>> non-release/early access lines >>> so as to not expose non .Final features to the stable capture >>> that >>> appears when performing >>> an 'uncategorized' install. No dependent component version >>> change >>> from >>> 4.2.0.Final. >>> >>> >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ >>> >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ >>> >>> Please respond by COB on Thursday, Jan 29 to the specified Jira if >>> there >>> are any issues. >>> >>> Thanks, >>> --paull >>> >>> _______________________________________________ >>> Soa-tools-list mailing list >>> Soa-tools-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>> >> /max http://about.me/maxandersen From pleacu at redhat.com Wed Jan 28 11:04:47 2015 From: pleacu at redhat.com (Paul Leacu) Date: Wed, 28 Jan 2015 11:04:47 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> Message-ID: <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> Hey Max - The BPMN2 Modeler and BPEL appear in both the JBTIS TP and as p2 update site components. Your statement below is really the principle issue: > I believe this change is done to ensure we don't leak in bad dependencies between > the earlyaccess site that exists in both community and product shipment. --paull ----- Original Message ----- > From: "Max Rydahl Andersen" > To: "Paul Leacu" > Cc: "Rob Cernich" , "soa-tools-list" , jbds-is-pm-list at redhat.com, > "jbosstools-dev jbosstools-dev" > Sent: Wednesday, January 28, 2015 10:25:18 AM > Subject: Re: [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA > > i'm a bit confused what is it you consider product bits in the TP here ? > > I'm not seeing any in here - am I missing something ? > > I believe this change is done to ensure we don't leak in bad > dependencies between > the earlyaccess site that exists in both community and product shipment. > > /max > > Hey Rob, > > > > I'd love to remove product bits from the TP but that hasn't happened. > > Having > > a release based JBTIS TP that is guaranteed to have only .Final > > components and > > then having an early-access TP seems to give component developers the > > option of > > adding non fully released dependencies that are not our own product > > bits while > > their component is still in Beta. > > > > The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers > > could use either > > with 4.2.1.EA being the full set of dependencies. > > > > We can revisit removing the JBoss product bits from the TP but for the > > JDV release > > this change removes uncategorized non .Final bits that's needed now. > > > > --paull > > > > ----- Original Message ----- > >> From: "Rob Cernich" > >> To: "Paul Leacu" > >> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" > >> , "jbosstools-dev jbosstools-dev" > >> > >> Sent: Wednesday, January 28, 2015 9:32:26 AM > >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > >> platform - 4.2.1.Final/ 4.2.1.EA > >> > >> I think the better solution is to remove product bits from the TP and > >> have > >> them included directly through the site/p2 repo. Splitting up the TP > >> is > >> likely to cause issues down, especially as versions change. Also, I > >> assume > >> this is for product bits and not community bits (i.e. JBDS-IS vs > >> JBTIS). > >> > >> ----- Original Message ----- > >>> > >>> Greetings - > >>> A proposal to change the JBTIS target platform is described here: > >>> > >>> https://issues.jboss.org/browse/JBTIS-382 > >>> > >>> PR: > >>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > >>> > >>> Synopsis: > >>> > >>> 1. Split the JBTIS target platform along release/final and > >>> non-release/early access lines > >>> so as to not expose non .Final features to the stable capture > >>> that > >>> appears when performing > >>> an 'uncategorized' install. No dependent component version > >>> change > >>> from > >>> 4.2.0.Final. > >>> > >>> > >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > >>> > >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > >>> > >>> Please respond by COB on Thursday, Jan 29 to the specified Jira if > >>> there > >>> are any issues. > >>> > >>> Thanks, > >>> --paull > >>> > >>> _______________________________________________ > >>> Soa-tools-list mailing list > >>> Soa-tools-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/soa-tools-list > >>> > >> > > > /max > http://about.me/maxandersen > From rcernich at redhat.com Wed Jan 28 11:08:48 2015 From: rcernich at redhat.com (Rob Cernich) Date: Wed, 28 Jan 2015 11:08:48 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> Message-ID: <1510399528.2149051.1422461328321.JavaMail.zimbra@redhat.com> My preference would be to remove those from the TP and include them through the site/p2 repo directly, i.e. treat them the same way we treat our early access components. The benefit of this approach is that if those components need to be updated, we can simply respin JBTIS/JBDS-IS instead of respinning the TP. This would allow us to provide a more stable TP (i.e. we don't have to update it every time a bug is fixed upstream in bpmn2 or bpel). ----- Original Message ----- > > Hey Max - > The BPMN2 Modeler and BPEL appear in both the JBTIS TP and as p2 > update site components. > Your statement below is really the principle issue: > > > I believe this change is done to ensure we don't leak in bad dependencies > > between > > the earlyaccess site that exists in both community and product shipment. > > --paull > > > > ----- Original Message ----- > > From: "Max Rydahl Andersen" > > To: "Paul Leacu" > > Cc: "Rob Cernich" , "soa-tools-list" > > , jbds-is-pm-list at redhat.com, > > "jbosstools-dev jbosstools-dev" > > Sent: Wednesday, January 28, 2015 10:25:18 AM > > Subject: Re: [Soa-tools-list] Proposed change for JBTIS target platform - > > 4.2.1.Final/ 4.2.1.EA > > > > i'm a bit confused what is it you consider product bits in the TP here ? > > > > I'm not seeing any in here - am I missing something ? > > > > I believe this change is done to ensure we don't leak in bad > > dependencies between > > the earlyaccess site that exists in both community and product shipment. > > > > /max > > > Hey Rob, > > > > > > I'd love to remove product bits from the TP but that hasn't happened. > > > Having > > > a release based JBTIS TP that is guaranteed to have only .Final > > > components and > > > then having an early-access TP seems to give component developers the > > > option of > > > adding non fully released dependencies that are not our own product > > > bits while > > > their component is still in Beta. > > > > > > The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers > > > could use either > > > with 4.2.1.EA being the full set of dependencies. > > > > > > We can revisit removing the JBoss product bits from the TP but for the > > > JDV release > > > this change removes uncategorized non .Final bits that's needed now. > > > > > > --paull > > > > > > ----- Original Message ----- > > >> From: "Rob Cernich" > > >> To: "Paul Leacu" > > >> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" > > >> , "jbosstools-dev jbosstools-dev" > > >> > > >> Sent: Wednesday, January 28, 2015 9:32:26 AM > > >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > > >> platform - 4.2.1.Final/ 4.2.1.EA > > >> > > >> I think the better solution is to remove product bits from the TP and > > >> have > > >> them included directly through the site/p2 repo. Splitting up the TP > > >> is > > >> likely to cause issues down, especially as versions change. Also, I > > >> assume > > >> this is for product bits and not community bits (i.e. JBDS-IS vs > > >> JBTIS). > > >> > > >> ----- Original Message ----- > > >>> > > >>> Greetings - > > >>> A proposal to change the JBTIS target platform is described here: > > >>> > > >>> https://issues.jboss.org/browse/JBTIS-382 > > >>> > > >>> PR: > > >>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > > >>> > > >>> Synopsis: > > >>> > > >>> 1. Split the JBTIS target platform along release/final and > > >>> non-release/early access lines > > >>> so as to not expose non .Final features to the stable capture > > >>> that > > >>> appears when performing > > >>> an 'uncategorized' install. No dependent component version > > >>> change > > >>> from > > >>> 4.2.0.Final. > > >>> > > >>> > > >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > > >>> > > >>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > > >>> > > >>> Please respond by COB on Thursday, Jan 29 to the specified Jira if > > >>> there > > >>> are any issues. > > >>> > > >>> Thanks, > > >>> --paull > > >>> > > >>> _______________________________________________ > > >>> Soa-tools-list mailing list > > >>> Soa-tools-list at redhat.com > > >>> https://www.redhat.com/mailman/listinfo/soa-tools-list > > >>> > > >> > > > > > > /max > > http://about.me/maxandersen > > > From manderse at redhat.com Wed Jan 28 11:21:28 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Wed, 28 Jan 2015 17:21:28 +0100 Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> Message-ID: <8606DF9C-6D44-485E-92D8-583895421F14@redhat.com> On 28 Jan 2015, at 17:04, Paul Leacu wrote: > Hey Max - > The BPMN2 Modeler and BPEL appear in both the JBTIS TP and as p2 > update site components. okey - but both BPMN2 and BPEL is part of community release too so i'm confused why called product only ;) > Your statement below is really the principle issue: > >> I believe this change is done to ensure we don't leak in bad >> dependencies between >> the earlyaccess site that exists in both community and product >> shipment. > > --paull > > > > ----- Original Message ----- >> From: "Max Rydahl Andersen" >> To: "Paul Leacu" >> Cc: "Rob Cernich" , "soa-tools-list" >> , jbds-is-pm-list at redhat.com, >> "jbosstools-dev jbosstools-dev" >> Sent: Wednesday, January 28, 2015 10:25:18 AM >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target >> platform - 4.2.1.Final/ 4.2.1.EA >> >> i'm a bit confused what is it you consider product bits in the TP >> here ? >> >> I'm not seeing any in here - am I missing something ? >> >> I believe this change is done to ensure we don't leak in bad >> dependencies between >> the earlyaccess site that exists in both community and product >> shipment. >> >> /max >>> Hey Rob, >>> >>> I'd love to remove product bits from the TP but that hasn't >>> happened. >>> Having >>> a release based JBTIS TP that is guaranteed to have only .Final >>> components and >>> then having an early-access TP seems to give component developers >>> the >>> option of >>> adding non fully released dependencies that are not our own product >>> bits while >>> their component is still in Beta. >>> >>> The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers >>> could use either >>> with 4.2.1.EA being the full set of dependencies. >>> >>> We can revisit removing the JBoss product bits from the TP but for >>> the >>> JDV release >>> this change removes uncategorized non .Final bits that's needed now. >>> >>> --paull >>> >>> ----- Original Message ----- >>>> From: "Rob Cernich" >>>> To: "Paul Leacu" >>>> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" >>>> , "jbosstools-dev jbosstools-dev" >>>> >>>> Sent: Wednesday, January 28, 2015 9:32:26 AM >>>> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target >>>> platform - 4.2.1.Final/ 4.2.1.EA >>>> >>>> I think the better solution is to remove product bits from the TP >>>> and >>>> have >>>> them included directly through the site/p2 repo. Splitting up the >>>> TP >>>> is >>>> likely to cause issues down, especially as versions change. Also, >>>> I >>>> assume >>>> this is for product bits and not community bits (i.e. JBDS-IS vs >>>> JBTIS). >>>> >>>> ----- Original Message ----- >>>>> >>>>> Greetings - >>>>> A proposal to change the JBTIS target platform is described here: >>>>> >>>>> https://issues.jboss.org/browse/JBTIS-382 >>>>> >>>>> PR: >>>>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 >>>>> >>>>> Synopsis: >>>>> >>>>> 1. Split the JBTIS target platform along release/final and >>>>> non-release/early access lines >>>>> so as to not expose non .Final features to the stable capture >>>>> that >>>>> appears when performing >>>>> an 'uncategorized' install. No dependent component version >>>>> change >>>>> from >>>>> 4.2.0.Final. >>>>> >>>>> >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ >>>>> >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ >>>>> >>>>> Please respond by COB on Thursday, Jan 29 to the specified Jira if >>>>> there >>>>> are any issues. >>>>> >>>>> Thanks, >>>>> --paull >>>>> >>>>> _______________________________________________ >>>>> Soa-tools-list mailing list >>>>> Soa-tools-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list >>>>> >>>> >> >> >> /max >> http://about.me/maxandersen >> /max http://about.me/maxandersen From pleacu at redhat.com Wed Jan 28 12:49:47 2015 From: pleacu at redhat.com (Paul Leacu) Date: Wed, 28 Jan 2015 12:49:47 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <8606DF9C-6D44-485E-92D8-583895421F14@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> <8606DF9C-6D44-485E-92D8-583895421F14@redhat.com> Message-ID: <1404461509.2075378.1422467387662.JavaMail.zimbra@redhat.com> Okay - I'm in complete agreement that bpel/ bpmn2 modeler should migrate out of the JBTIS TP but it will take time for the existing tools which rely on it (SwitchYard + ??) to change. So - since this is for a CR2 IS release (soon to be .Final/.GA) and a .Final/EA TP release - let me propose the following: 1. I create a Jira for the removal of bpel/ bpmn2 modeler from the JBTIS TP. 2. We go ahead with the JBTIS TP split as specified in JBTIS-382 so we can get CR2 to QE for JDV. If we find other dependent features that are pre-release we can continue with the split TP theme. Agreed? Thanks for the feedback, --paull ----- Original Message ----- > From: "Max Rydahl Andersen" > To: "Paul Leacu" > Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" , "jbosstools-dev jbosstools-dev" > > Sent: Wednesday, January 28, 2015 11:21:28 AM > Subject: Re: [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA > > On 28 Jan 2015, at 17:04, Paul Leacu wrote: > > > Hey Max - > > The BPMN2 Modeler and BPEL appear in both the JBTIS TP and as p2 > > update site components. > > okey - but both BPMN2 and BPEL is part of community release too so i'm > confused why called product only ;) > > > Your statement below is really the principle issue: > > > > >> I believe this change is done to ensure we don't leak in bad > >> dependencies between > >> the earlyaccess site that exists in both community and product > >> shipment. > > > > --paull > > > > > > > > ----- Original Message ----- > >> From: "Max Rydahl Andersen" > >> To: "Paul Leacu" > >> Cc: "Rob Cernich" , "soa-tools-list" > >> , jbds-is-pm-list at redhat.com, > >> "jbosstools-dev jbosstools-dev" > >> Sent: Wednesday, January 28, 2015 10:25:18 AM > >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > >> platform - 4.2.1.Final/ 4.2.1.EA > >> > >> i'm a bit confused what is it you consider product bits in the TP > >> here ? > >> > >> I'm not seeing any in here - am I missing something ? > >> > >> I believe this change is done to ensure we don't leak in bad > >> dependencies between > >> the earlyaccess site that exists in both community and product > >> shipment. > >> > >> /max > >>> Hey Rob, > >>> > >>> I'd love to remove product bits from the TP but that hasn't > >>> happened. > >>> Having > >>> a release based JBTIS TP that is guaranteed to have only .Final > >>> components and > >>> then having an early-access TP seems to give component developers > >>> the > >>> option of > >>> adding non fully released dependencies that are not our own product > >>> bits while > >>> their component is still in Beta. > >>> > >>> The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers > >>> could use either > >>> with 4.2.1.EA being the full set of dependencies. > >>> > >>> We can revisit removing the JBoss product bits from the TP but for > >>> the > >>> JDV release > >>> this change removes uncategorized non .Final bits that's needed now. > >>> > >>> --paull > >>> > >>> ----- Original Message ----- > >>>> From: "Rob Cernich" > >>>> To: "Paul Leacu" > >>>> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" > >>>> , "jbosstools-dev jbosstools-dev" > >>>> > >>>> Sent: Wednesday, January 28, 2015 9:32:26 AM > >>>> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > >>>> platform - 4.2.1.Final/ 4.2.1.EA > >>>> > >>>> I think the better solution is to remove product bits from the TP > >>>> and > >>>> have > >>>> them included directly through the site/p2 repo. Splitting up the > >>>> TP > >>>> is > >>>> likely to cause issues down, especially as versions change. Also, > >>>> I > >>>> assume > >>>> this is for product bits and not community bits (i.e. JBDS-IS vs > >>>> JBTIS). > >>>> > >>>> ----- Original Message ----- > >>>>> > >>>>> Greetings - > >>>>> A proposal to change the JBTIS target platform is described here: > >>>>> > >>>>> https://issues.jboss.org/browse/JBTIS-382 > >>>>> > >>>>> PR: > >>>>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > >>>>> > >>>>> Synopsis: > >>>>> > >>>>> 1. Split the JBTIS target platform along release/final and > >>>>> non-release/early access lines > >>>>> so as to not expose non .Final features to the stable capture > >>>>> that > >>>>> appears when performing > >>>>> an 'uncategorized' install. No dependent component version > >>>>> change > >>>>> from > >>>>> 4.2.0.Final. > >>>>> > >>>>> > >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > >>>>> > >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > >>>>> > >>>>> Please respond by COB on Thursday, Jan 29 to the specified Jira if > >>>>> there > >>>>> are any issues. > >>>>> > >>>>> Thanks, > >>>>> --paull > >>>>> > >>>>> _______________________________________________ > >>>>> Soa-tools-list mailing list > >>>>> Soa-tools-list at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list > >>>>> > >>>> > >> > >> > >> /max > >> http://about.me/maxandersen > >> > > > /max > http://about.me/maxandersen > From rcernich at redhat.com Wed Jan 28 13:24:23 2015 From: rcernich at redhat.com (Rob Cernich) Date: Wed, 28 Jan 2015 13:24:23 -0500 (EST) Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <1404461509.2075378.1422467387662.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> <1907164677.2038816.1422455546313.JavaMail.zimbra@redhat.com> <2105361652.1935236.1422456719150.JavaMail.zimbra@redhat.com> <5BE56C66-4DB9-4BB5-B543-9A1A0EA4295F@redhat.com> <273575204.2003723.1422461087092.JavaMail.zimbra@redhat.com> <8606DF9C-6D44-485E-92D8-583895421F14@redhat.com> <1404461509.2075378.1422467387662.JavaMail.zimbra@redhat.com> Message-ID: <1681031581.2262972.1422469463875.JavaMail.zimbra@redhat.com> Switchyard does not pull bpmn2 modeller from the TP, so it's removal will not affect SwitchYard builds, FYI. ----- Original Message ----- > > Okay - I'm in complete agreement that bpel/ bpmn2 modeler should migrate > out of the JBTIS > TP but it will take time for the existing tools which rely on it > (SwitchYard + ??) to change. > So - since this is for a CR2 IS release (soon to be .Final/.GA) and a > .Final/EA TP release - > let me propose the following: > > 1. I create a Jira for the removal of bpel/ bpmn2 modeler from the JBTIS > TP. > 2. We go ahead with the JBTIS TP split as specified in JBTIS-382 so we > can get CR2 to QE for JDV. > > If we find other dependent features that are pre-release we can continue > with the split TP > theme. > > Agreed? > > Thanks for the feedback, > --paull > > ----- Original Message ----- > > From: "Max Rydahl Andersen" > > To: "Paul Leacu" > > Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" > > , "jbosstools-dev jbosstools-dev" > > > > Sent: Wednesday, January 28, 2015 11:21:28 AM > > Subject: Re: [Soa-tools-list] Proposed change for JBTIS target platform - > > 4.2.1.Final/ 4.2.1.EA > > > > On 28 Jan 2015, at 17:04, Paul Leacu wrote: > > > > > Hey Max - > > > The BPMN2 Modeler and BPEL appear in both the JBTIS TP and as p2 > > > update site components. > > > > okey - but both BPMN2 and BPEL is part of community release too so i'm > > confused why called product only ;) > > > > > Your statement below is really the principle issue: > > > > > > > >> I believe this change is done to ensure we don't leak in bad > > >> dependencies between > > >> the earlyaccess site that exists in both community and product > > >> shipment. > > > > > > --paull > > > > > > > > > > > > ----- Original Message ----- > > >> From: "Max Rydahl Andersen" > > >> To: "Paul Leacu" > > >> Cc: "Rob Cernich" , "soa-tools-list" > > >> , jbds-is-pm-list at redhat.com, > > >> "jbosstools-dev jbosstools-dev" > > >> Sent: Wednesday, January 28, 2015 10:25:18 AM > > >> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > > >> platform - 4.2.1.Final/ 4.2.1.EA > > >> > > >> i'm a bit confused what is it you consider product bits in the TP > > >> here ? > > >> > > >> I'm not seeing any in here - am I missing something ? > > >> > > >> I believe this change is done to ensure we don't leak in bad > > >> dependencies between > > >> the earlyaccess site that exists in both community and product > > >> shipment. > > >> > > >> /max > > >>> Hey Rob, > > >>> > > >>> I'd love to remove product bits from the TP but that hasn't > > >>> happened. > > >>> Having > > >>> a release based JBTIS TP that is guaranteed to have only .Final > > >>> components and > > >>> then having an early-access TP seems to give component developers > > >>> the > > >>> option of > > >>> adding non fully released dependencies that are not our own product > > >>> bits while > > >>> their component is still in Beta. > > >>> > > >>> The TPs are identical (JBTIS TP/ JBDSIS TP) - component developers > > >>> could use either > > >>> with 4.2.1.EA being the full set of dependencies. > > >>> > > >>> We can revisit removing the JBoss product bits from the TP but for > > >>> the > > >>> JDV release > > >>> this change removes uncategorized non .Final bits that's needed now. > > >>> > > >>> --paull > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Rob Cernich" > > >>>> To: "Paul Leacu" > > >>>> Cc: jbds-is-pm-list at redhat.com, "soa-tools-list" > > >>>> , "jbosstools-dev jbosstools-dev" > > >>>> > > >>>> Sent: Wednesday, January 28, 2015 9:32:26 AM > > >>>> Subject: Re: [Soa-tools-list] Proposed change for JBTIS target > > >>>> platform - 4.2.1.Final/ 4.2.1.EA > > >>>> > > >>>> I think the better solution is to remove product bits from the TP > > >>>> and > > >>>> have > > >>>> them included directly through the site/p2 repo. Splitting up the > > >>>> TP > > >>>> is > > >>>> likely to cause issues down, especially as versions change. Also, > > >>>> I > > >>>> assume > > >>>> this is for product bits and not community bits (i.e. JBDS-IS vs > > >>>> JBTIS). > > >>>> > > >>>> ----- Original Message ----- > > >>>>> > > >>>>> Greetings - > > >>>>> A proposal to change the JBTIS target platform is described here: > > >>>>> > > >>>>> https://issues.jboss.org/browse/JBTIS-382 > > >>>>> > > >>>>> PR: > > >>>>> https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > > >>>>> > > >>>>> Synopsis: > > >>>>> > > >>>>> 1. Split the JBTIS target platform along release/final and > > >>>>> non-release/early access lines > > >>>>> so as to not expose non .Final features to the stable capture > > >>>>> that > > >>>>> appears when performing > > >>>>> an 'uncategorized' install. No dependent component version > > >>>>> change > > >>>>> from > > >>>>> 4.2.0.Final. > > >>>>> > > >>>>> > > >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > > >>>>> > > >>>>> http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > > >>>>> > > >>>>> Please respond by COB on Thursday, Jan 29 to the specified Jira if > > >>>>> there > > >>>>> are any issues. > > >>>>> > > >>>>> Thanks, > > >>>>> --paull > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Soa-tools-list mailing list > > >>>>> Soa-tools-list at redhat.com > > >>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list > > >>>>> > > >>>> > > >> > > >> > > >> /max > > >> http://about.me/maxandersen > > >> > > > > > > /max > > http://about.me/maxandersen > > > From mgagyi at redhat.com Thu Jan 29 06:32:42 2015 From: mgagyi at redhat.com (Matej Gagyi) Date: Thu, 29 Jan 2015 06:32:42 -0500 (EST) Subject: [jbosstools-dev] Proposed change to JBT 4.50.0 target platform: In-Reply-To: <1714561076.857381.1422523807928.JavaMail.zimbra@redhat.com> Message-ID: <262625909.874038.1422531162913.JavaMail.zimbra@redhat.com> Here is a proposal for a change to the JBoss Tools 4.50.0 target platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/119 It consists in the following changes: * JBIDE-JBIDE-19110: Add Mockito to Target platform 4.50.0 p2diff reports are attached to the related JIRA(s). Please review the above PR(s), as it will be applied ASAP. You can use the following to build & test the target-platform locally against your component(s). Build target-platform: $ cd jbosstools-target-platforms $ git fetch origin 4.50.x $ git checkout FETCH_HEAD $ cd jbosstools/multiple $ mvn clean install Try with just built target-platform: $ cd /path/to/your/component $ mvn clean verify -Dtpc.version=4.50.x -Pmultiple.target -- If you want to perform a scripted install of the entire target platform into your local Eclipse or JBDS instance, you can now do so with this script: https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/installFromTarget.sh Usage is documented in the above script, and in this README: https://github.com/jbosstools/jbosstools-target-platforms/tree/master#updating-versions-of-ius-in-target-files From manderse at redhat.com Thu Jan 29 06:44:19 2015 From: manderse at redhat.com (Max Rydahl Andersen) Date: Thu, 29 Jan 2015 12:44:19 +0100 Subject: [jbosstools-dev] [Soa-tools-list] Proposed change for JBTIS target platform - 4.2.1.Final/ 4.2.1.EA In-Reply-To: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> References: <1533555605.1912221.1422455127829.JavaMail.zimbra@redhat.com> Message-ID: <82C1C1CA-82BA-4D40-BDBA-22E43FCBEAF5@redhat.com> On 28 Jan 2015, at 15:25, Paul Leacu wrote: > Greetings - > A proposal to change the JBTIS target platform is described here: > > https://issues.jboss.org/browse/JBTIS-382 > > PR: > https://github.com/jbosstools/jbosstools-integration-stack/pull/280 > > Synopsis: > > 1. Split the JBTIS target platform along release/final and > non-release/early access lines > so as to not expose non .Final features to the stable capture that > appears when performing > an 'uncategorized' install. No dependent component version change > from 4.2.0.Final. > > > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.Final/ > > http://download.jboss.org/jbosstools/targetplatforms/jbtistarget/4.2.1.EA/ > Please respond by COB on Thursday, Jan 29 to the specified Jira if > there are any issues. I only have limited time today but I put main comments on the PR. main "bug" is that you are using the version to differentiate where IMO it is a *new* artifact that is being introduced, not a new new version. Also even that was the case, 4.2.1.EA is *not* an allowed/valid version - so I suggest using it as a separate artifact instead with shared version since that is actually what is done here. split in Two TP's (or updatesites) for one version. I also believe that would remove the need for all the profiling switching ? (but can't say that for sure since I haven't had time to run the build to completeness) /max > Thanks, > --paull > > _______________________________________________ > Soa-tools-list mailing list > Soa-tools-list at redhat.com > https://www.redhat.com/mailman/listinfo/soa-tools-list /max http://about.me/maxandersen From mgagyi at redhat.com Thu Jan 29 09:13:59 2015 From: mgagyi at redhat.com (Matej Gagyi) Date: Thu, 29 Jan 2015 09:13:59 -0500 (EST) Subject: [jbosstools-dev] Proposed change to JBT 4.50.0 target platform: In-Reply-To: <262625909.874038.1422531162913.JavaMail.zimbra@redhat.com> Message-ID: <1147152179.913042.1422540839712.JavaMail.zimbra@redhat.com> Here is a proposal for a change to the JBoss Tools 4.50.0 target platform: https://github.com/jbosstools/jbosstools-target-platforms/pull/119 It consists in the following changes: * JBIDE-JBIDE-19110: Add Mockito to Target platform 4.50.0 p2diff reports are attached to the related JIRA(s). Please review the above PR(s), as it will be applied ASAP. You can use the following to build & test the target-platform locally against your component(s). Build target-platform: $ cd jbosstools-target-platforms $ git fetch origin 4.50.x $ git checkout FETCH_HEAD $ cd jbosstools/multiple $ mvn clean install Try with just built target-platform: $ cd /path/to/your/component $ mvn clean verify -Dtpc.version=4.50.x -Pmultiple.target -- If you want to perform a scripted install of the entire target platform into your local Eclipse or JBDS instance, you can now do so with this script: https://github.com/jbosstools/jbosstools-build-ci/blob/master/util/installFromTarget.sh Usage is documented in the above script, and in this README: https://github.com/jbosstools/jbosstools-target-platforms/tree/master#updating-versions-of-ius-in-target-files -------------- next part -------------- A non-text attachment was scrubbed... Name: p2diff-pr199.diff Type: text/x-patch Size: 233 bytes Desc: not available Url : http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20150129/509e69f2/attachment.bin From nboldt at redhat.com Thu Jan 29 14:15:14 2015 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 29 Jan 2015 14:15:14 -0500 Subject: [jbosstools-dev] JBoss Tools 4.2.3 / JBDS 8.1.0 schedule updated in JIRA (now with CR1!) Message-ID: <54CA86C2.2050802@redhat.com> In order to encourage more community participation [1] and earlier access to new features (like FeedHenry support), we will be releasing milestones sooner than we have in the past. I've updated the schedule in JIRA [2] to reflect that new change. [1] http://tools.jboss.org/cat/ [2] https://issues.jboss.org/browse/JBIDE?selectedTab=com.atlassian.jira.jira-projects-plugin%3Aversions-panel Since we now have more time between CR1 and GA release dates, I've also added a CR1 fixversion so we can target bugfixes appropriately. Cheers, -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com From nboldt at redhat.com Thu Jan 29 22:20:03 2015 From: nboldt at redhat.com (Nick Boldt) Date: Thu, 29 Jan 2015 22:20:03 -0500 Subject: [jbosstools-dev] ACTION REQUIRED: Prepare for JBT 4.2.3.Beta1! Message-ID: <54CAF863.3020908@redhat.com> These projects have approved changes coming (or already built) in JBT 4.2.3, so must ensure they've upversioned and are using the latest parent pom & target platform (including new Tern 0.7 and forthcoming Luna SR2 bits next week): Aerogear : https://issues.jboss.org/browse/JBIDE-19125 JST : https://issues.jboss.org/browse/JBIDE-19126 VPE : https://issues.jboss.org/browse/JBIDE-19127 Forge : https://issues.jboss.org/browse/JBIDE-19128 Server : https://issues.jboss.org/browse/JBIDE-19129 Hibernate : https://issues.jboss.org/browse/JBIDE-19130 Base : https://issues.jboss.org/browse/JBIDE-19131 OpenShift : https://issues.jboss.org/browse/JBIDE-19132 -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com