Re: [jbosstools-dev] Respinning for Beta1d today -- any last requests?
by Nick Boldt
Only 3 builds left:
JBT Aggregate >= 117 [~1hr left]
JBDS Aggregate/Extras >= 98 [waiting for upstream]
JBDS Installers >= 101 [waiting for upstream]
When these are done, there should be good builds to test at the
following locations. When I wake up in a few hours, I'll stage them to
the usual /development/ paths - but feel free to start on them sooner.
== Updates ==
http://download.jboss.org/jbosstools/updates/nightly/core/3.3.indigo/ >=
H117
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_stable...
>= H98
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_stable...
>= 101
== Installers ==
http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio-5.0_stable...
On 03/06/2012 06:44 PM, Nick Boldt wrote:
> Current build todo list is:
>
> JBT TP >= 360 [waiting for a slave; must pick up new m2e-wtp 0.15.2]
>
> VPE >= 57 [waiting for upstream; new commits]
> Openshift >= 53 [waiting for upstream; new commits]
> Forge >=53 [waiting for upstream; respin to verify m2e-wtp change]
> Maven >= 79 [waiting for upstream; respin to verify m2e-wtp change]
>
> JBT Aggregate >= 115 [waiting for upstream]
> JBDS TP >= 319 [waiting for upstream; must pick up new m2e-wtp 0.15.2]
> JBDS Aggregate/Extras >= 97 [waiting for upstream]
> JBDS Installers >= 100 [waiting for upstream]
>
> Hopefully this will all complete tonight and I'll have something for QE
> first thing tomorrow morning (Europe time).
>
> Fingers crossed... we're having a bit of a slave shortage atm.
>
> On 03/06/2012 01:08 PM, Daniel Azarov wrote:
>> Yes, Nick we need this Respinning it looks like changes from JBIDE-11136
>> did not go to Beta1c
>>
>> On 03/06/2012 07:31 AM, Nick Boldt wrote:
>>> As far as I can tell from SVN logs & Jenkins change logs, there is ONE
>>> remaining commit which has not yet made it to a build.
>>>
>>> ------------------------------------------------------------------------
>>> r39299 | xcoulon | 2012-03-06 05:02:05 -0500 (Tue, 06 Mar 2012)
>>> M
>>> ws/plugins/org.jboss.tools.ws.jaxrs.core/src/org/jboss/tools/ws/jaxrs/core/internal/metamodel/domain/JaxrsResourceMethod.java
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> So, these builds are pending:
>>>
>>> https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.compo...
>>>
>>> >=77
>>> https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.aggre...
>>>
>>> >= 112
>>> https://hudson.qa.jboss.com/hudson/job/devstudio-5.0_stable_branch.update...
>>>
>>> >= 95
>>> https://hudson.qa.jboss.com/hudson/job/devstudio-5.0_stable_branch.product/
>>>
>>> >= 99
>>>
>>> Does anyone have anything else to slide into Beta1d today? For
>>> example, do we need to respin anything/everything if we move to
>>> m2e-wtp 0.15.2?
>>>
>>
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years, 10 months
Wizards for Java2WSDL and WSDL2Java
by Rob Cernich
Hey all,
One of the things missing from our toolset that would really improve productivity when developing SwitchYard applications is a mechansim for generating WSDL from Java, and, to a lesser degree, Java from WSDL. Currently, SY relies on wsconsume and wsprovide for this functionality.
>From a tooling perspective, it seems that all the translators require a dyanmic web project to invoke them. Is this a correct assessment? Have I missed something?
So far, the best tool I've found (that meets the needs of SY) is the Axis2 code gen plugin. The functionality is a bit sparse, but it works rather well, requiring minimal cleanup. I think if the interface were improved, it might easily produce results that don't require any cleanup.
In addition to the translators, SY would need transformers created (or stubbed out) so the runtime could manage conversion between the types (e.g. Java2XML). This makes me lean toward a custom SY solution, but I think it would be nice if the core could be shared.
Any ideas, opinions, comments, concerns...
Thanks in advance,
Rob
13 years, 10 months
Build Question
by Rob Cernich
Hey all,
Recently, we (SwitchYard) have been working on adding support for referencing artifacts from SOA repositories. Tooling has been added to allow the creation of these references in generic form or by referencing a package from a Guvnor repository. All is well and good for the generic tooling, but the Guvnor integration requires v 5.4 of the Guvnor/Drools tooling. So...
Since v. 5.4 is not in the nightly SOA repo, how would one go about setting up the SY tooling project to reference the Drools tools 5.4 snapshot builds?
Thanks in advance,
Rob
P.S. The Guvnor support is contained within its own feature. Thus, the requirement on Drools 5.4 only applies if the user wishes to install the SY Guvnor integration feature. If that is the case, they will need to install v. 5.4 of the Guvnor tooling from a snapshot build (since it is not in the nightly SOA repo). This is known and acceptable to the SY team.
13 years, 10 months
Refactoring Hudson views for DevStudio
by Mickael Istria
Hi all,
In order to make Hudson clearer to consume for us and for automated
work, we plan to refactor the Hudson views in order to have a single
"top-level" view (DevStudio) which contains nested views (such as
DevStudio_Trunk, DevStudio_Stable_Branch and so on). Nested views won't
appear on the list of all views on Hudson home, but will be listed and
available from DevStudio view. The DevStudio view will be the actual
container of all DevStudio stuff (it is not exactly the case currently).
From a end-user point of view, it will only replace 3 "DevStudio"
buttons on the main Hudson page by a single one that will contain the
same stuff as the current DevStudio view.
From an internal point of view, we do not have to deal with links and
so on to manipulate views, so it will make automated tasks easier to
perform, configure and write.
This change will be applied at the beginning of next week.
You feedback is welcome, especially if you can think of a good reason to
not performing this refactoring.
--
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>
13 years, 10 months
Modeling Management Objects (was: birth of "console ui" in eclipse)
by Rob Cernich
Hey folks,
I've spent a brief amount of time adding SwitchYard specific console features into the Eclipse Servers View. It would be a *huge* help if the models used in the GWT console could be used in Eclipse.
That said, there is a lot of mileage to be gained by simply being able to use the AutoBean framework within Eclipse. Does anyone have any experience using AutoBeans in an Eclipse or OSGi environment? (In SY land, we're slowly moving to a place where our core management/configuration model API can be used in the tooling as well.)
Best,
Rob
> > you know eclipse better then me and your concerns about embedding
> > may
> > be right. but if you guys could work towards something decoupled
> > from it's view technology, I might be able to re-use large parts of
> > it.
>
> I certainly think there may be opportunity here from a model
> perspective. For example, creating higher level types than
> "resource" (e.g. data source), that encapsulate specific resource
> types within the server. That said, I'm not sure if there is any
> support available for the AutoBean framework in Eclipse (knowing the
> console makes heavy use of AutoBean). If there is, that would
> certainly simplify adding more detailed capabilities.
>
> The model used in the Eclipse POC is simply a model around the low
> level, generic resource API, nothing more. It's simple, complete,
> but not very pretty (or usable, in my opinion).
>
> Best,
> Rob
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
13 years, 10 months
