April 2012 - jbosstools-dev - Jboss List Archives

Re: [jbosstools-dev] Maven Configurator Plugin for GWT

by Max Rydahl Andersen

Moved to jbosstools-dev list. Denis - thanks for the writeup. > Fred, > > here is the small article about what was implemented in Maven GWT Configurator plugin https://community.jboss.org/wiki/MavenConfiguratorPluginForGWT. > > Denis

12 years

1
0
0 / 0

Re: [jbosstools-dev] Make the "How To Build" page a favorite in your browser

by Mickael Istria

-------- Original Message -------- Subject: Re: Make the "How To Build" page a favorite in your browser Date: Wed, 25 Apr 2012 10:15:56 +0200 From: Mickael Istria <mistria(a)redhat.com> To: external-exadel-list(a)redhat.com Hey, A major change happened for end-users of the build (ie you): you now need to configure repositories in your ~/.m2/settings.xml to resolve parent pom. This is intended to make us more "Maven-friendly" regarding repositories and conform to the Maven practice of other projects. You should read that immediatly to correctly set up your settings.xml and stay able to run builds locally: https://community.jboss.org/wiki/HowToBuildJBossToolsWithMaven3#Maven_set... Work and feedback tracked here: https://issues.jboss.org/browse/JBIDE-11615 Cheers -- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

12 years

1
0
0 / 0

Re: [jbosstools-dev] Processing JAX-RS operation URLs with parameters

by Max Rydahl Andersen

Hey Brian, moved this to the right mailinglist. > JBIDE-11337 is fixed in trunk. URL are now properly exported into the WS Tester. > Have fun ;-) > cool. >> I've been looking at the issue about the JAX-RS operation URLs with parameters (for the JIRA I can't seem to locate but I know exists) in the WS Tester. It may be JBIDE-11337, but I think that actually is related and not exactly the same. What I've run into are a few intriguing issues... >> >> **Problem #1** >> >> So let's say that we have a REST application, such as the Kitchen sink example. It by default has two GET methods - one without any parameters and one that takes a single id parameter. In the Project Explorer, you see the following tree: >> >> * jboss-as-kitchensink >> - GET /rest/members >> - GET /rest/members/{id:[0-9][0-9]*} >> >> The "Uri Path Template" associated with the second parameterized GET (that you see in the tree) is: "/rest/members/{id:[0-9][0-9]*}" >> >> When it gets translated to an actual server-based URL (when you do Run As... and test it in the WS Tester), it becomes: "http://localhost:8080/jboss-as-kitchensink/[0-9][0-9]*}" >> >> Notice anything odd about the URL vs. the URI? In WSTesterClientDelegate, the computeEndpointURI method translates the URI to an Eclipse IPath object, which seems to truncate the leading part of the parameter text - "{id:" disappears, leaving an odd (and invalid) URL without the extra bits. I think this is what's actually happening with JBIDE-11337. >> >> The actual URL should be: "http://localhost:8080/jboss-as-kitchensink/rest/members/{id:[0-9][0-9]*}" >> >> So something is happening in that computeEndpointURI method that's doing a hatchet job on the URL. That's problem #1. If we can solve that, we can deal with the other issue which is also entertaining. yeah, sounds like that is fixed by xavier now. Using IPath is not right here though - IPath obeys OS filesystem "laws" I believe ? >> **Problem #2** >> >> With a valid URL that includes the "shape" of the URL parameters as RegEx, we need the user to change it and provide his or her own value that is valid based on that Regular Expression. I'm guessing the number of parameters could be anything from none to 100, though I'm not sure why anyone would want to go that crazy. So that makes an educated guess at probably 1-5 parameters to deal with on the URL. >> >> Here are the possibilities I've come up with for handling parameter input: >> >> 1) Leave it as is, showing the full URL with the parameter data as it comes out of the JAX-RS tooling. >> >> 2) Pop up a dialog requesting & validating values for the named parameters included in the URL, then replace the expressions with the user-provided values. On the dialog have an option to turn off this feature and allow the user to turn it back on in the Tester Preferences (which don't exist currently). >> >> Though I'm not a fan of automatically throwing dialogs in the user's face, this would present the user with the options they need at the time they need them. >> >> I'm open to suggestions on how to handle this. IMO, I would lave the URL as it is and then when you press Run detect this is an URL with {} stuff in it which needs to be replaced. Show the dialog in that case and ask for input and when user press ok, remember the values for that URL, execute the generated url but keep the original URL in the dialog. Next time I press Ok, the dialog is still shown but now remembering the values so a simply press on Ok works. That allows rapid execution while still allowing user to actually enter values he might want changed. At some point you could have a [ ] replace URL with generated URL checkbox that would allow for skipping the dialog since it is no longer a {} based url. WDYT ? >> Max, do you have any clue what that JIRA was for the URL-parameter-processing request? not yet, i'll find it eventually :) /max >> >> --Fitz >> >> _______________________________ >> Brian Fitzpatrick (aka "Fitz") >> Senior Software Engineer, SOA-P >> JBoss by Red Hat >> >

12 years

3
6
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 4714 - Failure!

by jboss-qa-internal＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 4714 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/4714/ to view the results.

12 years

1
4
0 / 0

Changes to JBoss Tools' parent pom affecting all JBT/JBDS Core & SOA Tooling builds -- please read!

by Nick Boldt

Recently, we moved the parent pom from version 0.0.4-SNAPSHOT to 3.3.0.Beta3-SNAPSHOT in trunk. When we branch next week for the Beta3 code freeze, this version will become the parent pom in the branch, and trunk will move to version 3.3.0.CR1-SNAPSHOT (then later to 3.3.0.GA-SNAPHOT, etc.) Anyone who depends on the parent pom 0.0.4 can continue to do so (as it's now in Nexus) but should sooner or later move up to use the correct 3.3.0.x version of the parent pom before the 0.0.4 snapshot disappears from Nexus. Details on this change: https://issues.jboss.org/browse/JBIDE-11157 If I've forgotten to cc: a SOA Tools project lead, please fwd this on. If there's a soa-tooling mailing list you'd like me to cc: in future for these sorts of changes, let me know. Cheers, -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

12 years

3
4
0 / 0

OpenShift Tooling : migrating the client plugins to the new REST API

by Xavier Coulon

Hi, I just committed a bunch of changes in relation with JBIDE-11400 (Migrate current openshift plugins to the new RESTful client library) since work on JBIDE-11339 (Create an openshift client library for the new OpenShift REST service) that André and I have been working on for the last few weeks in now taking a good shape. Everything has not been tested yet, and we'll keep testing and fixing issues in the next days, so don't hesitate to ping us if you have issues. If you're interested in the java client library, it is living here for now: https://github.com/adietish/openshift-java-client/tree/rest, and it'll be merged into the openshift repo on github later this month, once work is done and Eclipse tooling is stabilized. Best regards, /Xavier

12 years

2
2
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 4703 - Failure!

by jboss-qa-internal＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 4703 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/4703/ to view the results.

12 years

1
0
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 4700 - Failure!

by jboss-qa-internal＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 4700 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/4700/ to view the results.

12 years

1
0
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 4694 - Failure!

by jboss-qa-internal＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 4694 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/4694/ to view the results.

12 years

1
0
0 / 0

jbosstools-3.3_trunk.aggregate - Build # 4692 - Failure!

by jboss-qa-internal＠redhat.com

jbosstools-3.3_trunk.aggregate - Build # 4692 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/4692/ to view the results.

12 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev April 2012