January 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-19056) A Mojo to validate a version (compared to baseline)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19056?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19056: ------------------------------------ {quote} [10:43:29 AM] Rob Stryker: im not sure this mojo thing works as intended for me [10:43:32 AM] Rob Stryker: but thats fine [10:43:43 AM] Rob Stryker: it probably works in reality or something [10:43:49 AM] Rob Stryker: Failed to execute goal org.jboss.tools.tycho-plugins:repository-utils:0.22.1-SNAPSHOT:compare-version-with-baselines (default) on project org.jboss.tools.archives.scanner: Version of 'org.jboss.tools.archives.scanner/3.5.1.Alpha1-v20150129-1540) must be bigger than baseline one (3.6.0.Alpha1-v20150129-1119) -> [Help 1] [10:44:07 AM] Rob Stryker: basically it's complaining my 3.5.1 (maintenance) is not higher than 3.6.0 (master) [10:44:20 AM] Rob Stryker: bc i changed the parent pom to master i assume [10:45:06 AM] Rob Stryker: so i still haven't seen the error i want to see [10:45:13 AM] Rob Stryker: which is 'you made changes but didnt upversion yet' [10:50:05 AM] Rob Stryker: amirite? [10:53:10 AM] Nick Boldt: you ran the mojo from master branch (0.22.1-SNAPSHOT) against your 4.2.x sources, right? [10:55:58 AM] Nick Boldt: afaict, the mojo SHOULD be comparing your jbosstools-server/archives/plugins/org.jboss.tools.archives.scanner Bundle-Version: 3.5.1.qualifier [10:56:19 AM] Nick Boldt: against org.jboss.tools.archives.scanner 3.5.1.Final-v20141209-0156-B106 in http://download.jboss.org/jbosstools/updates/stable/luna [10:56:44 AM] Nick Boldt: so I don't know what happened there. when I ran it I got no error [10:56:51 AM] Nick Boldt: because 3.5.1 == 3.5.1 {code} > A Mojo to validate a version (compared to baseline) > --------------------------------------------------- > > Key: JBIDE-19056 > URL: https://issues.jboss.org/browse/JBIDE-19056 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.2.2.Final > Reporter: Mickael Istria > Assignee: Mickael Istria > > We need a mojo that compares a newly-built artifact with other versions of this IU that we have already released. > Such a mojo would fail is version isn't correct (lower than same one on that stream, equal to another one already released but with different content...) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19116) itests not being linked from build page

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19116?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-19116 at 1/29/15 10:50 AM: -------------------------------------------------------------- The above worked, but using "sources/*/\*tests/\*/target/surefire-reports/TEST-\*.xml" might be simpler. Running now: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=664 Incidentally, I thought we wanted to NOT run all the itests in CI build jobs. Do they need to run every time? Maybe we want to have ONE job that runs weekly to run ALL the ITests across all the components? [~maxandersen] WDYT? was (Author: nickboldt): The above worked, but using "sources/*/*tests/*/target/surefire-reports/TEST-*.xml" might be simpler. Running now: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=664 Incidentally, I thought we wanted to NOT run all the itests in CI build jobs. Do they need to run every time? Maybe we want to have ONE job that runs weekly to run ALL the ITests across all the components? [~maxandersen] WDYT? > itests not being linked from build page > --------------------------------------- > > Key: JBIDE-19116 > URL: https://issues.jboss.org/browse/JBIDE-19116 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Rob Stryker > Assignee: Mickael Istria > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > There is no link to the itests, and yet the build has failed. This makes it troublesome to browse the failing tests. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19115) Include FeedHenry feature in Mobile Category

by Burr Sutter (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19115?page=com.atlassian.jira.plugi... ] Burr Sutter commented on JBIDE-19115: ------------------------------------- No, at least, there is no "visual" impact to those areas, right [~gercan]? > Include FeedHenry feature in Mobile Category > -------------------------------------------- > > Key: JBIDE-19115 > URL: https://issues.jboss.org/browse/JBIDE-19115 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Reporter: Pavol Srna > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha1 > > > Currently the code base for FeedHenry integration is in github repository, but the build artefacts are not picked up by nightly job. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19116) itests not being linked from build page

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19116?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19116: ------------------------------------ The above worked, but using "sources/*/*tests/*/target/surefire-reports/TEST-*.xml" might be simpler. Running now: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... >=664 Incidentally, I thought we wanted to NOT run all the itests in CI build jobs. Do they need to run every time? Maybe we want to have ONE job that runs weekly to run ALL the ITests across all the components? [~maxandersen] WDYT? > itests not being linked from build page > --------------------------------------- > > Key: JBIDE-19116 > URL: https://issues.jboss.org/browse/JBIDE-19116 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Rob Stryker > Assignee: Mickael Istria > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > There is no link to the itests, and yet the build has failed. This makes it troublesome to browse the failing tests. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19115) Include FeedHenry feature in Mobile Category

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19115?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19115: ------------------------------------ [~maxandersen] [~burrsutter] Should this new Feed Henry stuff also be exposed in any of these places? * JBoss Tools Central * JBDS Early Access * JBDS Central * JBDS "BYOE" / installer > Include FeedHenry feature in Mobile Category > -------------------------------------------- > > Key: JBIDE-19115 > URL: https://issues.jboss.org/browse/JBIDE-19115 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Reporter: Pavol Srna > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha1 > > > Currently the code base for FeedHenry integration is in github repository, but the build artefacts are not picked up by nightly job. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19110) Add Mockito to Target platform 4.50.0

by Matej Gagyi (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19110?page=com.atlassian.jira.plugi... ] Matej Gagyi commented on JBIDE-19110: ------------------------------------- Seems Mockito from Locus works fine for me. [~adietish] might be able to justify tough. JBIDE-18053 (powermock) is not required in our use case. > Add Mockito to Target platform 4.50.0 > ------------------------------------- > > Key: JBIDE-19110 > URL: https://issues.jboss.org/browse/JBIDE-19110 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: target-platform > Reporter: Matej Gagyi > Priority: Optional > Fix For: 4.3.0.Final > > > *Reason:* Needed to simplify testing of jbosstools-openshift > *Project page/sources:* https://github.com/mockito/mockito > *Version:* 1.9.5 > *License and owner:* MIT > *Original p2 repo:* http://download.eclipse.org/tools/orbit/downloads/drops/R20140525021250/r... > *JBoss mirror:* http://download.jboss.org/jbosstools/updates/requirements/orbit/S20141129... > *Include Sources:* Yes > *Affected projects:* > *Include in JBDS:* No > *Type of dependency:* testing > *List of bundles added/removed:* > {code} > diff --git a/jbosstools/multiple/jbosstools-multiple.target b/jbosstools/multiple/jbosstools-multiple.ta > index c17fb92..51f6076 100644 > --- a/jbosstools/multiple/jbosstools-multiple.target > +++ b/jbosstools/multiple/jbosstools-multiple.target > @@ -10,8 +10,6 @@ >  >  > @@ -86,6 +84,10 @@ > <unit id="org.apache.jasper.glassfish" version="2.2.2.v201205150955"/> >  > <unit id="org.slf4j.api" version="1.7.2.v20121108-1250"/> > + > +  > + <unit id="org.mockito" version="1.9.5.v201311280930"/> > + <unit id="org.objenesis" version="1.0.0.v201105211943"/> > </location> > > <!-- TODO: make sure these versions match up across JBT/JBDS/Central target platforms (JBIDE-17429) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-15135: --------------------------------------------- {quote} knownReferences allow to know from which tag or branch the build was triggered. I feel this might be useful one day{quote} About the name I was just not sure what "knownReferences" means and why there are multiple of them. But now I grok it - the knownReferences are what symbolic names matches the HEAD sha1. {code} "revision": { "knownReferences": [ { "ref": "HEAD", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" }, { "ref": "JBIDE-19076", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" }, { "ref": "master", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" } ], "HEAD": "789667220e157a2dc0e0c325ca4845ad87f1a88d" }, {code} It just threw me off that the actual used SHA was coming *After* known references. Is there a way to actually have it state what the active branch was instead of just HEAD ? i.e. I would have expected something like this when building from jbosstools-4.2.x: "revision": { "knownReferences": [ { "ref": "HEAD", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" }, { "ref": "JBIDE-19076", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" }, { "ref": "jbosstools-4.2.x", "name": "origin", "url": "git@github.com:jbosstools/jbosstools-openshift.git" } ], name: "jbosstools-4.2.x" sha1: "789667220e157a2dc0e0c325ca4845ad87f1a88d" } i.e. where it can be seen not only the sha1 used, but lists the symbolic name used for the checkout. {quote}but I didn't figure out any real use-case yet. We can get rid of it if you want.{quote} Knowing what the build actually used for symbolic name + the used sha1 is the important one. the knownReferences does not hurt, but it could be informative. > Attach metadata during assembly instead of publish time > ------------------------------------------------------- > > Key: JBIDE-15135 > URL: https://issues.jboss.org/browse/JBIDE-15135 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha1 > > > In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site. > Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19047) Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19047?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-19047: ------------------------------------- OK so I see error markers on the projects which look pretty serious. Not sure what you expect the tooling to do then? > Issue deploying EAR project from eclipse to Wildfly using JBoss Tools Plugin > ---------------------------------------------------------------------------- > > Key: JBIDE-19047 > URL: https://issues.jboss.org/browse/JBIDE-19047 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: maven, server, upstream > Environment: Ubuntu 14.04, Wildfly 8.2.0 FInal, Eclipse Luna > Reporter: Nick . > Assignee: Fred Bricon > Fix For: 4.3.x > > Attachments: sample-with-unresolved-dep.zip, sample.zip, settings.zip > > > Hi, > I have a maven EAR project, which contains a couple of WAR and JAR files. I'm using Eclipse Luna (tried STS and IntelliJ ) IDE with JBoss Tools 1.6.0 (latest). > When I try to deploy my EAR to Wildfly (as well as in EAP 6.2.0) with JBoss Tools from eclipse i'm facing the following issues. > My Jars (external jars and project jar) are getting copied into WEB-INF/lib and EAR/lib, where i expected it to be only in EAR/lib. > EAR application.xml is not getting copied into EAR/META-INF/ folder > But when i use command line to build my project , i'm not experiencing the above issue. > FYI : We are using <skinnyWars>true</skinnyWars>. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-19056) A Mojo to validate a version (compared to baseline)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19056?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-19056: ------------------------------------ Make it so, +1. > A Mojo to validate a version (compared to baseline) > --------------------------------------------------- > > Key: JBIDE-19056 > URL: https://issues.jboss.org/browse/JBIDE-19056 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.2.2.Final > Reporter: Mickael Istria > Assignee: Mickael Istria > > We need a mojo that compares a newly-built artifact with other versions of this IU that we have already released. > Such a mojo would fail is version isn't correct (lower than same one on that stream, equal to another one already released but with different content...) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15135: ------------------------------------ My only remaining concern is that since implementing this mojo, we can't build JBDS. {code:title=https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_Master/job/devstudio.product_master/} [ERROR] Failed to execute goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.22.0:publish-products (default-publish-products) on project installer: Execution default-publish-products of goal org.eclipse.tycho:tycho-p2-publisher-plugin:0.22.0:publish-products failed: org.eclipse.equinox.p2.core.ProvisionException: Unable to read repository at file:/mnt/hudson_workspace/workspace/devstudio.product_master/sources/product/installer/target/. No repository found at file:/mnt/hudson_workspace/workspace/devstudio.product_master/sources/product/installer/target/jbds/. -> [Help 1] {code} There needs to be a way to disable this mojo for update site builds which do not require it, such as the build of the p2-director embedded in JBDS. On the other hand, if that's an issue w/ Tycho 0.22.0, then we need a way to build JBDS (for now) with 0.21.0, and be able to disable all this new awesomeness in the parent pom (or else the build fails because it's trying to use a combination of Tycho 0.21.0 and repo-utils 0.22.1, which is incompatible). > Attach metadata during assembly instead of publish time > ------------------------------------------------------- > > Key: JBIDE-15135 > URL: https://issues.jboss.org/browse/JBIDE-15135 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha1 > > > In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site. > Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues January 2015