October 2013 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-14555) Wrong warning "Could not initialize class my.pkg.ArchiveBuilder" by Arquillian

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14555?page=com.atlassian.jira.plugi... ] Snjezana Peco resolved JBIDE-14555. ----------------------------------- Fix Version/s: 4.2.0.Alpha1 (was: 4.1.x) (was: 4.2.x) Resolution: Out of Date > Wrong warning "Could not initialize class my.pkg.ArchiveBuilder" by Arquillian > ------------------------------------------------------------------------------ > > Key: JBIDE-14555 > URL: https://issues.jboss.org/browse/JBIDE-14555 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: testing-tools > Affects Versions: 4.1.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Snjezana Peco > Priority: Critical > Fix For: 4.2.0.Alpha1 > > > I'm using JBoss Tools 41-Update-2013-05-19_01-13-51-B207 having the new Arquillian component. > I'm getting a warning "Could not initialize class my.pkg.ArchiveBuilder" in all Arquillian-based test classes. > In fact my ArchiveBuilder isn't a regular class, but it's an enum: > public enum ArchiveBuilder { > INSTANCE; > private final WebArchive archive = ShrinkWrap.create(WebArchive.class, "shop.war"); > private ArchiveBuilder() {...} > public static ArchiveBuilder getInstance() { return INSTANCE; } > public Archive<? extends Archive<?>> getArchive() { return archive; } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-14780) Add ShrinkWrap Archive name/type validation

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-14780?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-14780: --------------------------------------- Screencast http://screencast.com/t/1zGLUgYVLBY is showing the validation has been added by JBIDE-14780 and JBIDE-14781. > Add ShrinkWrap Archive name/type validation > ------------------------------------------- > > Key: JBIDE-14780 > URL: https://issues.jboss.org/browse/JBIDE-14780 > Project: Tools (JBoss Tools) > Issue Type: Sub-task > Components: testing-tools > Reporter: Aslak Knutsen > Assignee: Snjezana Peco > Labels: new_and_noteworthy > Fix For: 4.2.0.Alpha1 > > > *Given* > {code} > ShrinkWrap.create(WebArchive.class, "test.jar") > ShrinkWrap.create(WebArchive.class, "test.ear") > ShrinkWrap.create(JavaArchive.class, "test.ear") > ShrinkWrap.create(WebArchive.class, "test") > {code} > *When* > User is creating a Archive > *Then* > The known Archive types should match given archive name extensions. > *Expected* > Warning; Creating an archive of type WebArchive but given name does not match to predefined name extension; .war > *Actual* > Nothing.. waits for Arquillian to fail. > This is a very common and annoying user error. The Container/Server will 99% of the time rely on the deployment file extension to determine what type of archive this is. While our 'WebArchive' Archive types are only convenience views on how to add data to correct locations within the target archive and can be any type; we choose to validate this runtime in Arquillian core to warn that 'hey, this is probably not what you intended to do' to hopefully save users from a few hours pointless debugging. > See https://github.com/arquillian/arquillian-core/blob/master/container/spi/s... for our extension type mapping. > Our validation logic is; if extension does not match, but Archive is of Type then warn. > That allows users to use Custom views without warning. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15428) No JAX-RS problems when importing a project that contains HTTPMethod annotation without @Target and @Retention

by Xavier Coulon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15428?page=com.atlassian.jira.plugi... ] Xavier Coulon commented on JBIDE-15428: --------------------------------------- [~maxandersen] I updated the PR by using a ReadWriteLock instead of the synchronized() blocks, and bypassed the Java ElementChangeEvents when the Java Project is not open (ie, during the import). This removes the race conditions (validator called on the whole project before the metamodel was fully built), and it also reduces the time to import the project ;-) > No JAX-RS problems when importing a project that contains HTTPMethod annotation without @Target and @Retention > -------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15428 > URL: https://issues.jboss.org/browse/JBIDE-15428 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: webservices > Affects Versions: 4.1.0.Final > Reporter: Radoslav Rábara > Assignee: Max Rydahl Andersen > Fix For: 4.1.1.Beta1, 4.2.0.Alpha1 > > Attachments: After import.png, After workaround.png, Before import.png > > > After importing Dynamic Web Project with JAX-RS support with HTTPMethod annotation without @Target and @Retention annotations, there is no error. > This looks like a regression of JBIDE-12690. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15482: ------------------------------------ So you want http://download.jboss.org/jbosstools/builds/staging/<jobName>/all/repo/<build#>/all/repo/ ? Why do we need two all/repo/ paths? What maintenance effort? The staging/CI folder is self cleaning. The old staging/ folder (and staging.previous/) is not, requiring MY manual maintenance effort. This new approach actually REDUCES the maintenance effort by automating the cleanup so I don't have to anymore. * builds/staging/ = old builds using old system (JBT 3.3, SOA Tooling 3.3, JBT 4.0, JBT 4.1, JBT IS 4.1) * builds/staging/CI = new builds using new system (JBT 4.2) If you dislike the notion of builds/staging/CI/ simply because of the name, then how about another name like "builds/CI" or "builds/snapshots/" ? What do you mean, "part of another iteration?" Iteration of what? > Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15482 > URL: https://issues.jboss.org/browse/JBIDE-15482 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, updatesite > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Alpha2 > > > Be it proposed: > {quote} > that instead of an in-place move which reuses > generic folder names like "staging" and "staging.previous", we > composite build output using unique names like > 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255 > {quote} > We therefore need: > a) to regenerate the composite site each time there's a new build > published, in order to remove the oldest and add the newest (keeping > only the Nth and N-1rst builds) > (I have a script that might already work for this, or would need > tweaking.) > b) heuristics to determine when an older (N-2, N-3, ... N-z) build is > no longer needed, perhaps simply by assuming no one needs it after > 24hrs? > 24 hours should be more that enough. > c) a cleanup script which can purge all but the builds which are no > more than 1 day old, keeping at all times at least two builds (N and > N-1) > (I have a script that already does this for folders like > http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but > might need to be tweaked to work for a new pattern of > staging/\$\{JOB_NAME}/<BUILD_ID>/ .) > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15655) openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15655?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-15655: ------------------------------------- Priority: Minor (was: Major) > openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app > ----------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15655 > URL: https://issues.jboss.org/browse/JBIDE-15655 > Project: Tools (JBoss Tools) > Issue Type: Bug > Affects Versions: 4.2.0.Alpha1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Priority: Minor > Fix For: 4.2.0.Alpha1 > > Attachments: have-to-choose-application-name.png > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15655) openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app

by Andre Dietisheim (JIRA)

Andre Dietisheim created JBIDE-15655: ---------------------------------------- Summary: openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app Key: JBIDE-15655 URL: https://issues.jboss.org/browse/JBIDE-15655 Project: Tools (JBoss Tools) Issue Type: Bug Affects Versions: 4.2.0.Alpha1 Reporter: Andre Dietisheim Assignee: Andre Dietisheim Fix For: 4.2.0.Alpha1 Attachments: have-to-choose-application-name.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15655) openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15655?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-15655: ------------------------------------- Attachment: have-to-choose-application-name.png > openshift import wizard: errors "you have to choose an application name" even though I have chose an existing app > ----------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15655 > URL: https://issues.jboss.org/browse/JBIDE-15655 > Project: Tools (JBoss Tools) > Issue Type: Bug > Affects Versions: 4.2.0.Alpha1 > Reporter: Andre Dietisheim > Assignee: Andre Dietisheim > Fix For: 4.2.0.Alpha1 > > Attachments: have-to-choose-application-name.png > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-15482: ---------------------------------------- > Mickael Istria Are you really suggesting we use http://download.jboss.org/jbosstools/builds/staging/<jobName>/all/repo/<jobName>/<build#>/all/repo ? that's longer and more redundant than just using builds/staging/CI/<jobName><build#>/all/repo/ ... and since builds/staging/CI/<jobName> is *already* a composite of the child builds, we already have a static URL for "latest build of a given component's job for a given stream". In such case, we can get rid of one <jobName>. What I don't understand is the benefit of renaming staging to staging/CI . It just adds maintenance effort. What kind of other suff will we have in this builds/staging? To me it just seems like there are and there will only be output of CI. And even if we want to adopt this "CI", shouldn't it be part of another iteration? > Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15482 > URL: https://issues.jboss.org/browse/JBIDE-15482 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, updatesite > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Alpha2 > > > Be it proposed: > {quote} > that instead of an in-place move which reuses > generic folder names like "staging" and "staging.previous", we > composite build output using unique names like > 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255 > {quote} > We therefore need: > a) to regenerate the composite site each time there's a new build > published, in order to remove the oldest and add the newest (keeping > only the Nth and N-1rst builds) > (I have a script that might already work for this, or would need > tweaking.) > b) heuristics to determine when an older (N-2, N-3, ... N-z) build is > no longer needed, perhaps simply by assuming no one needs it after > 24hrs? > 24 hours should be more that enough. > c) a cleanup script which can purge all but the builds which are no > more than 1 day old, keeping at all times at least two builds (N and > N-1) > (I have a script that already does this for folders like > http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but > might need to be tweaked to work for a new pattern of > staging/\$\{JOB_NAME}/<BUILD_ID>/ .) > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15652) JSF EL is proposed by content assist for plain HTML projects

by Victor Rubezhny (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15652?page=com.atlassian.jira.plugi... ] Victor Rubezhny commented on JBIDE-15652: ----------------------------------------- Are you sure you're not starting the studio while having some test ELResolver that came from some test plug-in? In case of plain HTML project we should have NO EL Resolvers defined for that project, so NO EL Proposals should be shown in Content Assist. We had such issue some time ago (JBIDE-5449) but we've fixed it. As for now, I suppose that org.jboss.tools.common.el.core.test.resolver.ResolverProjectNature1 EL Resolver from org.jboss.tools.common.el.core.test plug-in (which is not to be used in the product) is the reason of this issue. > JSF EL is proposed by content assist for plain HTML projects > ------------------------------------------------------------ > > Key: JBIDE-15652 > URL: https://issues.jboss.org/browse/JBIDE-15652 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: jsp/jsf/xml/html source editing > Affects Versions: 4.2.0.Alpha1 > Reporter: Alexey Kazakov > Assignee: Victor Rubezhny > Fix For: 4.2.0.Alpha1 > > Attachments: scr.png > > > JBT should propose JSF ELs only for JSF projects. > !scr.png! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-15482: ------------------------------------ [~maxandersen] The idea behind the URL pattern change was so that the automated cleanup would only apply to the NEW builds, not the old ones. So staging/CI/ is a folder under which automated cleanup occurs, but staging/ is not. This is to prevent data loss and screw up any JBDS SOA 5.x builds which will not migrate to the new scheme. And since everyone should be building based on the composite sites [1], [2], not the individual components' staging sites, this is an internal detail that shouldn't affect anyone anyway. [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.... with human-managed children (publish.sh, old way) [2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.... with script-generated children (publish_new.sh, new way) IMHO, it **IS** necessary and doesn't hurt anything. What's the concern here? Change might be scary sometimes, but evolution requires it. [~mmalina] As to putting in a readme, sure, we could, but isn't the fact that there's a nested <build#> folder enough to make it obvious we're using the newer publish_new.sh instead of the old one? [~mickael_istria] Are you really suggesting we use http://download.jboss.org/jbosstools/builds/staging/<jobName>/all/repo/<jobName>/<build#>/all/repo ? that's longer and more redundant than just using builds/staging/CI/<jobName><build#>/all/repo/ ... and since builds/staging/CI/<jobName> is **already** a composite of the child builds, we already have a static URL for "latest build of a given component's job for a given stream". > Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-15482 > URL: https://issues.jboss.org/browse/JBIDE-15482 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: build, updatesite > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.1.1.Alpha2 > > > Be it proposed: > {quote} > that instead of an in-place move which reuses > generic folder names like "staging" and "staging.previous", we > composite build output using unique names like > 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255 > {quote} > We therefore need: > a) to regenerate the composite site each time there's a new build > published, in order to remove the oldest and add the newest (keeping > only the Nth and N-1rst builds) > (I have a script that might already work for this, or would need > tweaking.) > b) heuristics to determine when an older (N-2, N-3, ... N-z) build is > no longer needed, perhaps simply by assuming no one needs it after > 24hrs? > 24 hours should be more that enough. > c) a cleanup script which can purge all but the builds which are no > more than 1 day old, keeping at all times at least two builds (N and > N-1) > (I have a script that already does this for folders like > http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but > might need to be tweaked to work for a new pattern of > staging/\$\{JOB_NAME}/<BUILD_ID>/ .) > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 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 October 2013