Menu
▾
▴
openoss-devel — OpenOSS Developer Mailing List
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(53) |
Aug
(86) |
Sep
(55) |
Oct
(19) |
Nov
(12) |
Dec
(9) |
| 2010 |
Jan
(8) |
Feb
(32) |
Mar
(31) |
Apr
(70) |
May
(67) |
Jun
(71) |
Jul
(26) |
Aug
(47) |
Sep
(25) |
Oct
(16) |
Nov
(11) |
Dec
(16) |
| 2011 |
Jan
(30) |
Feb
(31) |
Mar
(71) |
Apr
(64) |
May
(55) |
Jun
(25) |
Jul
(3) |
Aug
(24) |
Sep
(20) |
Oct
(18) |
Nov
(21) |
Dec
(1) |
| 2012 |
Jan
(9) |
Feb
(21) |
Mar
(29) |
Apr
(9) |
May
(9) |
Jun
(54) |
Jul
(37) |
Aug
(24) |
Sep
(43) |
Oct
(34) |
Nov
(25) |
Dec
(27) |
| 2013 |
Jan
(5) |
Feb
(13) |
Mar
(23) |
Apr
(9) |
May
(11) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <cg...@op...> - 2012-07-31 09:08:25
|
Marc, Yuval, I have found a problem in the PM dependency model. As you know the Java API we are using for the RI / CTK is based upon the OSS/J design patterns. This means that every Java value type we generate has a reserved field VALUE_TYPE and an operator getValueType(). As a result it is important that 'valueType' is not used as a name for an attribute of an Entity, DataType or Facade in the model. This has not been a problem to date but I have found an issue in the PM Dependencies model; org.tmforum.tip.cbe.perf.spec.PerformanceIndicatorSpecification has the field valueType; // A kind of value that the PerformanceIndicator can take on, such as numeric, text, and so forth. org.tmforum.tip.cbe.perf.IndicatorType valueType Could we please change the name of the field in the model from valueType to indicatorType Thanks Craig |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-31 08:00:57
|
Hi Craig I have checkined the project to the SVN. Some rare behaivour was detected in the SVN, the commit takes a long time and seems that the new version doesn't upload rigth (the new files was deleted from the version!!!), so I need to upload again. The package is also updated. Regards El 30/07/2012 17:21, Craig Gallen (entimoss) escribió: > Hi, > This all appears to work now. Thanks for all your hard work. Could you > commit the changes from your sandbox to the TRUNK version of the soap > generator before we move on to the next phase of work. > > Thanks > > Craig > > > > On 30/07/2012 08:54, Xose Ramon Sousa Vazquez wrote: >> I have checkin the code to the URI anURL support in the sandbox area. >> I have tested with the Common model project and it is working. >> >> >> Regards >> El 27/07/2012 10:13, Xose Ramon Sousa Vazquez escribió: >>> I will try to perform the primitive.URI and primitive.URL. >>> >>> One question related with. I have taken the hierarchy of types in >>> xsds from http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ and it >>> is clear the map from primitive.URI to a anyURI type, but it is not >>> clear which is the map with the URL. Should be mapped also to a >>> anyURI type? >>> >>> >>> Regards >>> >>> Diagram of built-in type hierarchy >>> El 27/07/2012 8:53, Craig Gallen (entimoss) escribió: >>>> Hi Xose >>>> I tried the new soap plugin this morning 27/7 and it appeared to >>>> work for me. I'm not sure if you have updated it since Marc's >>>> reported problem yesterday at 14.28. >>>> >>>> If Marc's bug is fixed, could you look at the primitive.URI and >>>> primitive.URL mappings as these are the next blocker. (should be a >>>> simple fix I think). >>>> >>>> Thanks >>>> Craig >>>> >>>> >>>> On 26/07/2012 14:28, Flauw, Marc wrote: >>>>> >>>>> Hi Xose, >>>>> >>>>> I have updated to latest SOAP Gen in the sandbox. >>>>> >>>>> I still have the error in both Dependencies and Model while >>>>> compiling RAM. >>>>> >>>>> However the text of the error message is a bit different, >>>>> referring to a $Proxy8. >>>>> >>>>> [exec] Error: Unexpected error while merging >>>>> 'templates/IteratorAnalyzer.vm' template: Invocation of method >>>>> 'collectBulkPotentialTypes' in class >>>>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>>>> threw exception java.lang.ClassCastException: $Proxy8 cannot be >>>>> cast to >>>>> org.eclipse.tigerstripe.workbench.internal.core.model.ManagedEntityArtifact >>>>> @ templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>>> *Sent:* Thursday, July 26, 2012 9:05 AM >>>>> *To:* Flauw, Marc >>>>> *Cc:* Craig Gallen; 'Craig Gallen (opennms)'; >>>>> ope...@li... >>>>> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >>>>> >>>>> Hi again, I have found the problem. I have created a new clean >>>>> scenario and then I could reproduce the error. >>>>> >>>>> It was because of the new version of Tigerstripe doesn't support >>>>> the function >>>>> TigerstripeCore.findModelProjectByID(ifArtifact.getProjectDescriptor().getIProjectDetails().getModelId()). >>>>> >>>>> This function was used to solve the problem derived of found a >>>>> null value in some use cases in the function call >>>>> getProject().getArtifactManagerSession(); >>>>> in the ISessionArtifact class. >>>>> >>>>> Fortuntately the method now works well so the prior workaround >>>>> was removed. >>>>> >>>>> I have commited the change again in the sandbox. >>>>> >>>>> Please, if you can ,check it and feedback the result. >>>>> >>>>> >>>>> Best regards. >>>>> >>>>> El 24/07/2012 13:18, Flauw, Marc escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I recompiled RAM using mvn clean, then mvn install and I have >>>>> the same error as Craig: >>>>> >>>>> /[exec] [TIP_Soap_Generator(1.1)Project: >>>>> org.tmforum.tip.ram.dep version=1.0, Plugin: >>>>> TIP_Soap_Generator(1.1) version=1.1]/ >>>>> >>>>> /[exec] Error: Unexpected error while merging >>>>> 'templates/IteratorAnalyzer.vm' template: Invocation of method >>>>> 'collectBulkPotentialTypes' in class >>>>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw >>>>> exception java.lang.NullPointerException @ >>>>> templates/IteratorAnalyzer.vm[6,19]. Generation may be >>>>> incomplete./ >>>>> >>>>> /[exec] >>>>> org.eclipse.tigerstripe.workbench.TigerstripeException: >>>>> Unexpected error while merging 'templates/IteratorAnalyzer.vm' >>>>> template: Invocation of method 'collectBulkPotentialTypes' in >>>>> class >>>>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw >>>>> exception java.lang.NullPointerException @ >>>>> templates/IteratorAnalyzer.vm[6,19]/ >>>>> >>>>> I have this error in both Dependencies and Model project. >>>>> >>>>> RAM projects are aligned with SVN. >>>>> >>>>> My environment: >>>>> >>>>> Windows 7, 64 bits, >>>>> >>>>> Eclipse Java EE IDE for Web Developers. Version: Helios >>>>> Service Release 2 Build id: 20110301-1815 >>>>> >>>>> Tigerstripe 0.7.0.201206291233 >>>>> >>>>> Generators uploaded on Friday July 13. SOAP Generator coming >>>>> from your sandbox (also loaded on July 13). >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Craig Gallen [mailto:gal...@go...] *On >>>>> Behalf Of *Craig Gallen >>>>> *Sent:* Tuesday, July 24, 2012 11:37 AM >>>>> *To:* 'Xose Ramon Sousa Vazquez'; 'Craig Gallen (opennms)' >>>>> *Cc:* Flauw, Marc; ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* RE: [Openoss-devel] Urgent questions on SOAP Generator >>>>> >>>>> Hi, >>>>> >>>>> Thanks for investigating. I thought i was using the latest >>>>> tigerstripe release from >>>>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>>>> which was update by tigerstripe recently. >>>>> >>>>> However I am not near my computer today so i cant check until >>>>> later.. I'll get you the version tomorrow. >>>>> >>>>> Craig >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez >>>>> [mailto:xr...@op...] >>>>> *Sent:* 24 July 2012 09:52 >>>>> *To:* Craig Gallen (opennms) >>>>> *Cc:* Flauw, Marc; ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >>>>> >>>>> Hi Craig I have evaluated the use case and I can reproduce >>>>> your error with the Tigerstripe version v0.7.0.201207021234. >>>>> But with the recommended version included in the URL >>>>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>>>> (version v0.7.0.201206291233) this problem doesn't happen. >>>>> Please could you give me details about which Tigerstripe >>>>> version are you using and test the deployment with the version >>>>> v0.7.0.201206291233. Meanwhile I will check the problem in the >>>>> new Tigerstripe version. >>>>> >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>> >>>>> El 23/07/2012 10:34, Craig Gallen (opennms) escribió: >>>>> >>>>> Hi, >>>>> The dependencies project is built as part of the Maven >>>>> build and the generated artefacts are used in the RI. So >>>>> the dependencies project has to work properly on its own. >>>>> BTW I would be suspicious if the project cannot be built >>>>> stand alone before it is imported into the Model project >>>>> Cheers >>>>> Craig >>>>> >>>>> >>>>> On 23/07/2012 09:29, Xose Ramón Sousa wrote: >>>>> >>>>> Hi Craig I am going to perform that test. I have not >>>>> performed because of I believe that the dependencies >>>>> project only would be exported to be included in the >>>>> model project. >>>>> >>>>> For my understanding I thought that the Soap >>>>> generation only is passed on the model project >>>>> >>>>> I will review this use case and fix the code >>>>> >>>>> Best regards >>>>> >>>>> Enviado desde mi iPhone >>>>> >>>>> >>>>> El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" >>>>> <cg...@op... <mailto:cg...@op...>> >>>>> escribió: >>>>> >>>>> Hi >>>>> Have you tried running tigerstripe on the >>>>> dependencies project itself from the dashboard? >>>>> The RAM Model project works OK but the >>>>> dependencies project cannot be built on its own. >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> On 23/07/2012 02:01, Xose Ramón Sousa wrote: >>>>> >>>>> Hi Craig thanks for the feedback. I have >>>>> tested in the RAM project, importing the >>>>> dependencies project as a module and it worked. >>>>> >>>>> Please could you give me the details of how do >>>>> you perform the test to be sure that I can >>>>> reporduce the error. >>>>> >>>>> Regards >>>>> >>>>> 2012/7/21 Craig Gallen (opennms) >>>>> <cg...@op... <mailto:cg...@op...>> >>>>> >>>>> Hi, >>>>> >>>>> I tried out the soap generator in the sandbox. >>>>> I'm using the latest tiger-stripe josif >>>>> release and the soap generator in the sandbox at >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>>>> >>>>> On the RAM Dependencies project I get the >>>>> following error when I try to generate using >>>>> the Soap Generator. >>>>> Unexpected error while merging >>>>> 'templates/IteratorAnalyzer.vm' template: >>>>> Invocation of method >>>>> 'collectBulkPotentialTypes' in class >>>>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>>>> threw exception java.lang.NullPointerException >>>>> @ templates/IteratorAnalyzer.vm[6,19]. >>>>> Generation may be incomplete. >>>>> >>>>> Cheers >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12/07/2012 16:08, Flauw, Marc wrote: >>>>> >>>>> Hi Xose, >>>>> >>>>> Thanks, I will give a try to your SOAP >>>>> generator in the sandbox. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez >>>>> [mailto:xr...@op...] >>>>> *Sent:* Thursday, July 12, 2012 5:05 PM >>>>> *To:* Flauw, Marc >>>>> *Cc:* ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* Re: Urgent questions on SOAP >>>>> Generator >>>>> >>>>> Hi Marc at the moment I don't have full >>>>> avialability but I am going to speed up >>>>> the developments that you detail. >>>>> >>>>> I have developed a workaround to solve the >>>>> issue around the allPackages context >>>>> variable. The new version of Tigerstripe >>>>> solves the problem of get the rigth >>>>> package elements but using a Proxy >>>>> implementation inside makes errors in some >>>>> casts performed in the calculation of the >>>>> closure. The workaround in my tests works >>>>> with the three versions of Tigerstripe in >>>>> the RAM and SPM projects but I cannot >>>>> perform more tests. It will be interesting >>>>> if someone could also test it. The >>>>> workaround change a lot of clasess so I >>>>> put the workaround in the sandbox to be >>>>> tested prior to checkin in the trunk of >>>>> Soap Generator. If the test are ok, then I >>>>> will checkin to the Trunk >>>>> >>>>> This issue takes me a lot of time and now >>>>> we follow with the URI support that expect >>>>> to get as soon as possible, but these days >>>>> I don't have availability because of my >>>>> surgery. >>>>> >>>>> >>>>> Regards >>>>> >>>>> El 11/07/2012 16:06, Flauw, Marc escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> There is no update following your last >>>>> mail on this topic and the SOAP >>>>> Generator trunk is not updated, so >>>>> would it be possible from you or one >>>>> of your backup to get a status on the >>>>> test of this workaround. >>>>> >>>>> Also, the support of uri and url in >>>>> the SOAP Generator is needed for JOSIF >>>>> V1.1.2 and I haven't seen any update >>>>> on this. >>>>> >>>>> These 2 points would be critical for >>>>> the release of JOSIF V1.1.2. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez >>>>> [mailto:xr...@op...] >>>>> *Sent:* Wednesday, July 04, 2012 9:31 AM >>>>> *To:* Flauw, Marc >>>>> *Cc:* >>>>> ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* Re: [Openoss-devel] FW: >>>>> [tigerstripe-dev] Critical bug for JOSIF >>>>> >>>>> Thanks Marc I've uploaded a workaround >>>>> in JOSIF development in URL >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>>>> >>>>> I will test the new version now. >>>>> >>>>> >>>>> Regards >>>>> >>>>> El 04/07/2012 7:36, Flauw, Marc escribió: >>>>> >>>>> FYI >>>>> >>>>> *From:*tig...@ec... >>>>> <mailto:tig...@ec...> >>>>> [mailto:tig...@ec...] >>>>> *On Behalf Of *Duncan Keysell >>>>> (dkeysell) >>>>> *Sent:* Tuesday, July 03, 2012 7:04 PM >>>>> *To:* Tigerstripe developers list >>>>> *Subject:* Re: [tigerstripe-dev] >>>>> Critical bug for JOSIF >>>>> >>>>> Hi, >>>>> >>>>> This fix has now been pushed to >>>>> the josif update site. >>>>> >>>>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>>>> >>>>> Thanks >>>>> >>>>> Duncan >>>>> >>>>> *From: *<Flauw>, Marc >>>>> <Mar...@hp... >>>>> <mailto:Mar...@hp...>> >>>>> *Reply-To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Date: *Friday, 29 June 2012 16:39 >>>>> *To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Subject: *Re: [tigerstripe-dev] >>>>> Critical bug for JOSIF >>>>> >>>>> Duncan, >>>>> >>>>> Thanks for the investigation. >>>>> >>>>> If you fixed a bug, then please >>>>> yes, push the fix to the josif >>>>> update site. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*tig...@ec... >>>>> <mailto:tig...@ec...> >>>>> [mailto:tig...@ec...] >>>>> *On Behalf Of *Duncan Keysell >>>>> (dkeysell) >>>>> *Sent:* Friday, June 29, 2012 5:27 PM >>>>> *To:* Tigerstripe developers list >>>>> *Subject:* Re: [tigerstripe-dev] >>>>> Critical bug for JOSIF >>>>> >>>>> Hi Marc, >>>>> >>>>> It took me quite a bit of >>>>> investigation but I don't think >>>>> there is an issue here: >>>>> >>>>> In order to get $all* collections >>>>> of the TS Velocity context >>>>> populated the user needs to >>>>> uncheck the "Run All Rules as >>>>> Local" checkbox in the Generation >>>>> section of the Advanced tab of the >>>>> tigerstripe.xml or the model >>>>> project. This is probably a new >>>>> feature since you last updated (it >>>>> was new to me). >>>>> >>>>> Please can you give this a try? >>>>> >>>>> However, when I was looking at >>>>> this I found it was not possible >>>>> to add a new Module Dependency to >>>>> a Tigerstripe model project. This >>>>> bug has now been fixed. Do you >>>>> want us to push another release to >>>>> the JOSIF update site with this fix? >>>>> >>>>> Thanks, >>>>> >>>>> Duncan >>>>> >>>>> *From: *<Flauw>, Marc >>>>> <Mar...@hp... >>>>> <mailto:Mar...@hp...>> >>>>> *Reply-To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Date: *Thursday, 28 June 2012 09:55 >>>>> *To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Subject: *[tigerstripe-dev] >>>>> Critical bug for JOSIF >>>>> >>>>> Hi Tigerstripe team, >>>>> >>>>> In our current version of JOSIF, >>>>> we are using an old version of >>>>> Tigerstripe from Feb 2011. >>>>> >>>>> We are testing the new Tigerstripe >>>>> version you made for us, which >>>>> corresponds to I53 for integration >>>>> in our new JOSIF version and we >>>>> have found a critical bug that >>>>> xose has filled in bugzilla: *Bug >>>>> 383728 >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728> >>>>> * >>>>> >>>>> We are using dependency modules >>>>> systematically in our projects and >>>>> the behavior has changed from the >>>>> version we use in the previous >>>>> version of JOSIF, >>>>> >>>>> When trying to get all the >>>>> artifacts inside the project with >>>>> the variable $allPackages we got >>>>> different responses in the two >>>>> versions of Tigerstripe. In the >>>>> new version, only the model >>>>> packages are shown. >>>>> >>>>> Is there now a different way of >>>>> getting model and dependency >>>>> packages all together? >>>>> >>>>> This is a show-stopper for us. >>>>> >>>>> Thanks for your support, >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Live Security Virtual Conference >>>>> >>>>> Exclusive live event will cover all the ways today's security and >>>>> >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> >>>>> will include endpoint security, mobile security and the latest in malware >>>>> >>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> Openoss-devel mailing list >>>>> >>>>> Ope...@li... <mailto:Ope...@li...> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director >>>>> OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 >>>>> <tel:%2B%2034%20986%20410%20091> (ext) >>>>> 206 | M/ +34 675 550 029 >>>>> <tel:%2B34%20675%20550%20029> >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> <mime-attachment.jpg> >>>>> <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 >>>>> <tel:%2B%2034%20986%20410%20091> (ext) 206 >>>>> | M/ +34 675 550 029 >>>>> <tel:%2B34%20675%20550%20029> >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> <mime-attachment.jpg> >>>>> <http://optarecoolvendor.com> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Live Security Virtual Conference >>>>> >>>>> Exclusive live event will cover all the ways today's security and >>>>> >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> >>>>> will include endpoint security, mobile security and the latest in malware >>>>> >>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> >>>>> _______________________________________________ >>>>> >>>>> Openoss-devel mailing list >>>>> >>>>> Ope...@li... <mailto:Ope...@li...> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>>> >>>>> >>>>> >>>>> -- >>>>> Antes de imprimir este mensaje, asegúrese de >>>>> que es necesario. Proteger el medio ambiente >>>>> está en nuestra mano >>>>> >>>>> Before printing this message, be sure it's >>>>> needed. Protecting the enviroment is in our hands >>>>> >>>>> >>>>> >>>>> Este mensaje se dirige exclusivamente a su >>>>> destinatario y puede contener información >>>>> CONFIDENCIAL sometida a secreto profesional o >>>>> cuya divulgación esté prohibida en virtud de >>>>> la legislación vigente. Cualquier opinión en >>>>> él contenida es exclusiva de su autor y no >>>>> representa necesariamente la opinión de la >>>>> empresa. Si ha recibido este mensaje por >>>>> error, le rogamos nos lo comunique >>>>> inmediatamente por esta misma vía y proceda a >>>>> su destrucción. >>>>> >>>>> This message contains information that may be >>>>> privileged or confidential and is the property >>>>> of Optare Solutions. It is intended only for >>>>> the person to whom it is addressed. If you are >>>>> not the intended recipient, you are not >>>>> authorized to read, print, retain, copy, >>>>> disseminate, distribute, or use this message >>>>> or any part thereof. If you receive this >>>>> message in error, please notify the sender >>>>> immediately and delete all copies of this message. >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Description: Description: Optare Solutions >>>>> <http://optarecoolvendor.com/> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Description: Optare Solutions <http://optarecoolvendor.com/> >>>>> >>>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions >>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-30 07:56:38
|
I have checkin the code to the URI anURL support in the sandbox area. I have tested with the Common model project and it is working. Regards El 27/07/2012 10:13, Xose Ramon Sousa Vazquez escribió: > I will try to perform the primitive.URI and primitive.URL. > > One question related with. I have taken the hierarchy of types in xsds > from http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ and it is > clear the map from primitive.URI to a anyURI type, but it is not clear > which is the map with the URL. Should be mapped also to a anyURI type? > > > Regards > > Diagram of built-in type hierarchy > El 27/07/2012 8:53, Craig Gallen (entimoss) escribió: >> Hi Xose >> I tried the new soap plugin this morning 27/7 and it appeared to work >> for me. I'm not sure if you have updated it since Marc's reported >> problem yesterday at 14.28. >> >> If Marc's bug is fixed, could you look at the primitive.URI and >> primitive.URL mappings as these are the next blocker. (should be a >> simple fix I think). >> >> Thanks >> Craig >> >> >> On 26/07/2012 14:28, Flauw, Marc wrote: >>> >>> Hi Xose, >>> >>> I have updated to latest SOAP Gen in the sandbox. >>> >>> I still have the error in both Dependencies and Model while >>> compiling RAM. >>> >>> However the text of the error message is a bit different, referring >>> to a $Proxy8. >>> >>> [exec] Error: Unexpected error while merging >>> 'templates/IteratorAnalyzer.vm' template: Invocation of method >>> 'collectBulkPotentialTypes' in class >>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>> threw exception java.lang.ClassCastException: $Proxy8 cannot be cast >>> to >>> org.eclipse.tigerstripe.workbench.internal.core.model.ManagedEntityArtifact >>> @ templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>> *Sent:* Thursday, July 26, 2012 9:05 AM >>> *To:* Flauw, Marc >>> *Cc:* Craig Gallen; 'Craig Gallen (opennms)'; >>> ope...@li... >>> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >>> >>> Hi again, I have found the problem. I have created a new clean >>> scenario and then I could reproduce the error. >>> >>> It was because of the new version of Tigerstripe doesn't support the >>> function >>> TigerstripeCore.findModelProjectByID(ifArtifact.getProjectDescriptor().getIProjectDetails().getModelId()). >>> >>> This function was used to solve the problem derived of found a null >>> value in some use cases in the function call >>> getProject().getArtifactManagerSession(); >>> in the ISessionArtifact class. >>> >>> Fortuntately the method now works well so the prior workaround was >>> removed. >>> >>> I have commited the change again in the sandbox. >>> >>> Please, if you can ,check it and feedback the result. >>> >>> >>> Best regards. >>> >>> El 24/07/2012 13:18, Flauw, Marc escribió: >>> >>> Hi Xose, >>> >>> I recompiled RAM using mvn clean, then mvn install and I have >>> the same error as Craig: >>> >>> /[exec] [TIP_Soap_Generator(1.1)Project: org.tmforum.tip.ram.dep >>> version=1.0, Plugin: TIP_Soap_Generator(1.1) version=1.1]/ >>> >>> /[exec] Error: Unexpected error while merging >>> 'templates/IteratorAnalyzer.vm' template: Invocation of method >>> 'collectBulkPotentialTypes' in class >>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>> threw exception java.lang.NullPointerException @ >>> templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete./ >>> >>> /[exec] org.eclipse.tigerstripe.workbench.TigerstripeException: >>> Unexpected error while merging 'templates/IteratorAnalyzer.vm' >>> template: Invocation of method 'collectBulkPotentialTypes' in >>> class >>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>> threw exception java.lang.NullPointerException @ >>> templates/IteratorAnalyzer.vm[6,19]/ >>> >>> I have this error in both Dependencies and Model project. >>> >>> RAM projects are aligned with SVN. >>> >>> My environment: >>> >>> Windows 7, 64 bits, >>> >>> Eclipse Java EE IDE for Web Developers. Version: Helios Service >>> Release 2 Build id: 20110301-1815 >>> >>> Tigerstripe 0.7.0.201206291233 >>> >>> Generators uploaded on Friday July 13. SOAP Generator coming >>> from your sandbox (also loaded on July 13). >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Craig Gallen [mailto:gal...@go...] *On >>> Behalf Of *Craig Gallen >>> *Sent:* Tuesday, July 24, 2012 11:37 AM >>> *To:* 'Xose Ramon Sousa Vazquez'; 'Craig Gallen (opennms)' >>> *Cc:* Flauw, Marc; ope...@li... >>> <mailto:ope...@li...> >>> *Subject:* RE: [Openoss-devel] Urgent questions on SOAP Generator >>> >>> Hi, >>> >>> Thanks for investigating. I thought i was using the latest >>> tigerstripe release from >>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>> which was update by tigerstripe recently. >>> >>> However I am not near my computer today so i cant check until >>> later.. I'll get you the version tomorrow. >>> >>> Craig >>> >>> *From:*Xose Ramon Sousa Vazquez >>> [mailto:xr...@op...] >>> *Sent:* 24 July 2012 09:52 >>> *To:* Craig Gallen (opennms) >>> *Cc:* Flauw, Marc; ope...@li... >>> <mailto:ope...@li...> >>> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >>> >>> Hi Craig I have evaluated the use case and I can reproduce your >>> error with the Tigerstripe version v0.7.0.201207021234. But with >>> the recommended version included in the URL >>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>> (version v0.7.0.201206291233) this problem doesn't happen. >>> Please could you give me details about which Tigerstripe version >>> are you using and test the deployment with the version >>> v0.7.0.201206291233. Meanwhile I will check the problem in the >>> new Tigerstripe version. >>> >>> >>> Regards >>> >>> >>> >>> >>> El 23/07/2012 10:34, Craig Gallen (opennms) escribió: >>> >>> Hi, >>> The dependencies project is built as part of the Maven build >>> and the generated artefacts are used in the RI. So the >>> dependencies project has to work properly on its own. BTW I >>> would be suspicious if the project cannot be built stand >>> alone before it is imported into the Model project >>> Cheers >>> Craig >>> >>> >>> On 23/07/2012 09:29, Xose Ramón Sousa wrote: >>> >>> Hi Craig I am going to perform that test. I have not >>> performed because of I believe that the dependencies >>> project only would be exported to be included in the >>> model project. >>> >>> For my understanding I thought that the Soap generation >>> only is passed on the model project >>> >>> I will review this use case and fix the code >>> >>> Best regards >>> >>> Enviado desde mi iPhone >>> >>> >>> El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" >>> <cg...@op... <mailto:cg...@op...>> escribió: >>> >>> Hi >>> Have you tried running tigerstripe on the >>> dependencies project itself from the dashboard? The >>> RAM Model project works OK but the dependencies >>> project cannot be built on its own. >>> >>> Craig >>> >>> >>> >>> On 23/07/2012 02:01, Xose Ramón Sousa wrote: >>> >>> Hi Craig thanks for the feedback. I have tested >>> in the RAM project, importing the dependencies >>> project as a module and it worked. >>> >>> Please could you give me the details of how do >>> you perform the test to be sure that I can >>> reporduce the error. >>> >>> Regards >>> >>> 2012/7/21 Craig Gallen (opennms) >>> <cg...@op... <mailto:cg...@op...>> >>> >>> Hi, >>> >>> I tried out the soap generator in the sandbox. >>> I'm using the latest tiger-stripe josif release >>> and the soap generator in the sandbox at >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>> >>> On the RAM Dependencies project I get the >>> following error when I try to generate using the >>> Soap Generator. >>> Unexpected error while merging >>> 'templates/IteratorAnalyzer.vm' template: >>> Invocation of method 'collectBulkPotentialTypes' >>> in class >>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>> threw exception java.lang.NullPointerException @ >>> templates/IteratorAnalyzer.vm[6,19]. Generation >>> may be incomplete. >>> >>> Cheers >>> Craig >>> >>> >>> >>> >>> >>> On 12/07/2012 16:08, Flauw, Marc wrote: >>> >>> Hi Xose, >>> >>> Thanks, I will give a try to your SOAP >>> generator in the sandbox. >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez >>> [mailto:xr...@op...] >>> *Sent:* Thursday, July 12, 2012 5:05 PM >>> *To:* Flauw, Marc >>> *Cc:* ope...@li... >>> <mailto:ope...@li...> >>> *Subject:* Re: Urgent questions on SOAP >>> Generator >>> >>> Hi Marc at the moment I don't have full >>> avialability but I am going to speed up the >>> developments that you detail. >>> >>> I have developed a workaround to solve the >>> issue around the allPackages context >>> variable. The new version of Tigerstripe >>> solves the problem of get the rigth package >>> elements but using a Proxy implementation >>> inside makes errors in some casts performed >>> in the calculation of the closure. The >>> workaround in my tests works with the three >>> versions of Tigerstripe in the RAM and SPM >>> projects but I cannot perform more tests. It >>> will be interesting if someone could also >>> test it. The workaround change a lot of >>> clasess so I put the workaround in the >>> sandbox to be tested prior to checkin in the >>> trunk of Soap Generator. If the test are ok, >>> then I will checkin to the Trunk >>> >>> This issue takes me a lot of time and now we >>> follow with the URI support that expect to >>> get as soon as possible, but these days I >>> don't have availability because of my surgery. >>> >>> >>> Regards >>> >>> El 11/07/2012 16:06, Flauw, Marc escribió: >>> >>> Hi Xose, >>> >>> There is no update following your last >>> mail on this topic and the SOAP >>> Generator trunk is not updated, so would >>> it be possible from you or one of your >>> backup to get a status on the test of >>> this workaround. >>> >>> Also, the support of uri and url in the >>> SOAP Generator is needed for JOSIF >>> V1.1.2 and I haven't seen any update on >>> this. >>> >>> These 2 points would be critical for the >>> release of JOSIF V1.1.2. >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez >>> [mailto:xr...@op...] >>> *Sent:* Wednesday, July 04, 2012 9:31 AM >>> *To:* Flauw, Marc >>> *Cc:* >>> ope...@li... >>> <mailto:ope...@li...> >>> *Subject:* Re: [Openoss-devel] FW: >>> [tigerstripe-dev] Critical bug for JOSIF >>> >>> Thanks Marc I've uploaded a workaround >>> in JOSIF development in URL >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>> >>> I will test the new version now. >>> >>> >>> Regards >>> >>> El 04/07/2012 7:36, Flauw, Marc escribió: >>> >>> FYI >>> >>> *From:*tig...@ec... >>> <mailto:tig...@ec...> >>> [mailto:tig...@ec...] >>> *On Behalf Of *Duncan Keysell (dkeysell) >>> *Sent:* Tuesday, July 03, 2012 7:04 PM >>> *To:* Tigerstripe developers list >>> *Subject:* Re: [tigerstripe-dev] >>> Critical bug for JOSIF >>> >>> Hi, >>> >>> This fix has now been pushed to the >>> josif update site. >>> >>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>> >>> Thanks >>> >>> Duncan >>> >>> *From: *<Flauw>, Marc >>> <Mar...@hp... >>> <mailto:Mar...@hp...>> >>> *Reply-To: *Tigerstripe Developers >>> <tig...@ec... >>> <mailto:tig...@ec...>> >>> *Date: *Friday, 29 June 2012 16:39 >>> *To: *Tigerstripe Developers >>> <tig...@ec... >>> <mailto:tig...@ec...>> >>> *Subject: *Re: [tigerstripe-dev] >>> Critical bug for JOSIF >>> >>> Duncan, >>> >>> Thanks for the investigation. >>> >>> If you fixed a bug, then please yes, >>> push the fix to the josif update site. >>> >>> Best regards >>> >>> Marc >>> >>> *From:*tig...@ec... >>> <mailto:tig...@ec...> >>> [mailto:tig...@ec...] >>> *On Behalf Of *Duncan Keysell (dkeysell) >>> *Sent:* Friday, June 29, 2012 5:27 PM >>> *To:* Tigerstripe developers list >>> *Subject:* Re: [tigerstripe-dev] >>> Critical bug for JOSIF >>> >>> Hi Marc, >>> >>> It took me quite a bit of >>> investigation but I don't think >>> there is an issue here: >>> >>> In order to get $all* collections of >>> the TS Velocity context populated >>> the user needs to uncheck the "Run >>> All Rules as Local" checkbox in the >>> Generation section of the Advanced >>> tab of the tigerstripe.xml or the >>> model project. This is probably a >>> new feature since you last updated >>> (it was new to me). >>> >>> Please can you give this a try? >>> >>> However, when I was looking at this >>> I found it was not possible to add a >>> new Module Dependency to a >>> Tigerstripe model project. This bug >>> has now been fixed. Do you want us >>> to push another release to the JOSIF >>> update site with this fix? >>> >>> Thanks, >>> >>> Duncan >>> >>> *From: *<Flauw>, Marc >>> <Mar...@hp... >>> <mailto:Mar...@hp...>> >>> *Reply-To: *Tigerstripe Developers >>> <tig...@ec... >>> <mailto:tig...@ec...>> >>> *Date: *Thursday, 28 June 2012 09:55 >>> *To: *Tigerstripe Developers >>> <tig...@ec... >>> <mailto:tig...@ec...>> >>> *Subject: *[tigerstripe-dev] >>> Critical bug for JOSIF >>> >>> Hi Tigerstripe team, >>> >>> In our current version of JOSIF, we >>> are using an old version of >>> Tigerstripe from Feb 2011. >>> >>> We are testing the new Tigerstripe >>> version you made for us, which >>> corresponds to I53 for integration >>> in our new JOSIF version and we have >>> found a critical bug that xose has >>> filled in bugzilla: *Bug 383728 >>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728> >>> * >>> >>> We are using dependency modules >>> systematically in our projects and >>> the behavior has changed from the >>> version we use in the previous >>> version of JOSIF, >>> >>> When trying to get all the artifacts >>> inside the project with the variable >>> $allPackages we got different >>> responses in the two versions of >>> Tigerstripe. In the new version, >>> only the model packages are shown. >>> >>> Is there now a different way of >>> getting model and dependency >>> packages all together? >>> >>> This is a show-stopper for us. >>> >>> Thanks for your support, >>> >>> Best regards >>> >>> Marc >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Live Security Virtual Conference >>> >>> Exclusive live event will cover all the ways today's security and >>> >>> threat landscape has changed and how IT managers can respond. Discussions >>> >>> will include endpoint security, mobile security and the latest in malware >>> >>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Openoss-devel mailing list >>> >>> Ope...@li... <mailto:Ope...@li...> >>> >>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 >>> <tel:%2B%2034%20986%20410%20091> (ext) >>> 206 | M/ +34 675 550 029 >>> <tel:%2B34%20675%20550%20029> >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> <mime-attachment.jpg> >>> <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 >>> <tel:%2B%2034%20986%20410%20091> (ext) 206 | >>> M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> <mime-attachment.jpg> >>> <http://optarecoolvendor.com> >>> >>> ------------------------------------------------------------------------------ >>> >>> Live Security Virtual Conference >>> >>> Exclusive live event will cover all the ways today's security and >>> >>> threat landscape has changed and how IT managers can respond. Discussions >>> >>> will include endpoint security, mobile security and the latest in malware >>> >>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> >>> _______________________________________________ >>> >>> Openoss-devel mailing list >>> >>> Ope...@li... <mailto:Ope...@li...> >>> >>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> >>> >>> >>> -- >>> Antes de imprimir este mensaje, asegúrese de que >>> es necesario. Proteger el medio ambiente está en >>> nuestra mano >>> >>> Before printing this message, be sure it's >>> needed. Protecting the enviroment is in our hands >>> >>> >>> >>> Este mensaje se dirige exclusivamente a su >>> destinatario y puede contener información >>> CONFIDENCIAL sometida a secreto profesional o >>> cuya divulgación esté prohibida en virtud de la >>> legislación vigente. Cualquier opinión en él >>> contenida es exclusiva de su autor y no >>> representa necesariamente la opinión de la >>> empresa. Si ha recibido este mensaje por error, >>> le rogamos nos lo comunique inmediatamente por >>> esta misma vía y proceda a su destrucción. >>> >>> This message contains information that may be >>> privileged or confidential and is the property >>> of Optare Solutions. It is intended only for >>> the person to whom it is addressed. If you are >>> not the intended recipient, you are not >>> authorized to read, print, retain, copy, >>> disseminate, distribute, or use this message or >>> any part thereof. If you receive this message in >>> error, please notify the sender immediately and >>> delete all copies of this message. >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Description: Description: Optare Solutions >>> <http://optarecoolvendor.com/> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Description: Optare Solutions <http://optarecoolvendor.com/> >>> >> > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions > <http://optarecoolvendor.com><http://optarecoolvendor.com> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-27 08:15:04
|
I will try to perform the primitive.URI and primitive.URL. One question related with. I have taken the hierarchy of types in xsds from http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ and it is clear the map from primitive.URI to a anyURI type, but it is not clear which is the map with the URL. Should be mapped also to a anyURI type? Regards Diagram of built-in type hierarchy El 27/07/2012 8:53, Craig Gallen (entimoss) escribió: > Hi Xose > I tried the new soap plugin this morning 27/7 and it appeared to work > for me. I'm not sure if you have updated it since Marc's reported > problem yesterday at 14.28. > > If Marc's bug is fixed, could you look at the primitive.URI and > primitive.URL mappings as these are the next blocker. (should be a > simple fix I think). > > Thanks > Craig > > > On 26/07/2012 14:28, Flauw, Marc wrote: >> >> Hi Xose, >> >> I have updated to latest SOAP Gen in the sandbox. >> >> I still have the error in both Dependencies and Model while compiling >> RAM. >> >> However the text of the error message is a bit different, referring >> to a $Proxy8. >> >> [exec] Error: Unexpected error while merging >> 'templates/IteratorAnalyzer.vm' template: Invocation of method >> 'collectBulkPotentialTypes' in class >> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw >> exception java.lang.ClassCastException: $Proxy8 cannot be cast to >> org.eclipse.tigerstripe.workbench.internal.core.model.ManagedEntityArtifact >> @ templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* Thursday, July 26, 2012 9:05 AM >> *To:* Flauw, Marc >> *Cc:* Craig Gallen; 'Craig Gallen (opennms)'; >> ope...@li... >> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >> >> Hi again, I have found the problem. I have created a new clean >> scenario and then I could reproduce the error. >> >> It was because of the new version of Tigerstripe doesn't support the >> function >> TigerstripeCore.findModelProjectByID(ifArtifact.getProjectDescriptor().getIProjectDetails().getModelId()). >> >> This function was used to solve the problem derived of found a null >> value in some use cases in the function call >> getProject().getArtifactManagerSession(); >> in the ISessionArtifact class. >> >> Fortuntately the method now works well so the prior workaround was >> removed. >> >> I have commited the change again in the sandbox. >> >> Please, if you can ,check it and feedback the result. >> >> >> Best regards. >> >> El 24/07/2012 13:18, Flauw, Marc escribió: >> >> Hi Xose, >> >> I recompiled RAM using mvn clean, then mvn install and I have the >> same error as Craig: >> >> /[exec] [TIP_Soap_Generator(1.1)Project: org.tmforum.tip.ram.dep >> version=1.0, Plugin: TIP_Soap_Generator(1.1) version=1.1]/ >> >> /[exec] Error: Unexpected error while merging >> 'templates/IteratorAnalyzer.vm' template: Invocation of method >> 'collectBulkPotentialTypes' in class >> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >> threw exception java.lang.NullPointerException @ >> templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete./ >> >> /[exec] org.eclipse.tigerstripe.workbench.TigerstripeException: >> Unexpected error while merging 'templates/IteratorAnalyzer.vm' >> template: Invocation of method 'collectBulkPotentialTypes' in >> class >> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >> threw exception java.lang.NullPointerException @ >> templates/IteratorAnalyzer.vm[6,19]/ >> >> I have this error in both Dependencies and Model project. >> >> RAM projects are aligned with SVN. >> >> My environment: >> >> Windows 7, 64 bits, >> >> Eclipse Java EE IDE for Web Developers. Version: Helios Service >> Release 2 Build id: 20110301-1815 >> >> Tigerstripe 0.7.0.201206291233 >> >> Generators uploaded on Friday July 13. SOAP Generator coming from >> your sandbox (also loaded on July 13). >> >> Best regards >> >> Marc >> >> *From:*Craig Gallen [mailto:gal...@go...] *On >> Behalf Of *Craig Gallen >> *Sent:* Tuesday, July 24, 2012 11:37 AM >> *To:* 'Xose Ramon Sousa Vazquez'; 'Craig Gallen (opennms)' >> *Cc:* Flauw, Marc; ope...@li... >> <mailto:ope...@li...> >> *Subject:* RE: [Openoss-devel] Urgent questions on SOAP Generator >> >> Hi, >> >> Thanks for investigating. I thought i was using the latest >> tigerstripe release from >> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >> which was update by tigerstripe recently. >> >> However I am not near my computer today so i cant check until >> later.. I'll get you the version tomorrow. >> >> Craig >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* 24 July 2012 09:52 >> *To:* Craig Gallen (opennms) >> *Cc:* Flauw, Marc; ope...@li... >> <mailto:ope...@li...> >> *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator >> >> Hi Craig I have evaluated the use case and I can reproduce your >> error with the Tigerstripe version v0.7.0.201207021234. But with >> the recommended version included in the URL >> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >> (version v0.7.0.201206291233) this problem doesn't happen. Please >> could you give me details about which Tigerstripe version are you >> using and test the deployment with the version >> v0.7.0.201206291233. Meanwhile I will check the problem in the >> new Tigerstripe version. >> >> >> Regards >> >> >> >> >> El 23/07/2012 10:34, Craig Gallen (opennms) escribió: >> >> Hi, >> The dependencies project is built as part of the Maven build >> and the generated artefacts are used in the RI. So the >> dependencies project has to work properly on its own. BTW I >> would be suspicious if the project cannot be built stand >> alone before it is imported into the Model project >> Cheers >> Craig >> >> >> On 23/07/2012 09:29, Xose Ramón Sousa wrote: >> >> Hi Craig I am going to perform that test. I have not >> performed because of I believe that the dependencies >> project only would be exported to be included in the >> model project. >> >> For my understanding I thought that the Soap generation >> only is passed on the model project >> >> I will review this use case and fix the code >> >> Best regards >> >> Enviado desde mi iPhone >> >> >> El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" >> <cg...@op... <mailto:cg...@op...>> escribió: >> >> Hi >> Have you tried running tigerstripe on the >> dependencies project itself from the dashboard? The >> RAM Model project works OK but the dependencies >> project cannot be built on its own. >> >> Craig >> >> >> >> On 23/07/2012 02:01, Xose Ramón Sousa wrote: >> >> Hi Craig thanks for the feedback. I have tested >> in the RAM project, importing the dependencies >> project as a module and it worked. >> >> Please could you give me the details of how do >> you perform the test to be sure that I can >> reporduce the error. >> >> Regards >> >> 2012/7/21 Craig Gallen (opennms) >> <cg...@op... <mailto:cg...@op...>> >> >> Hi, >> >> I tried out the soap generator in the sandbox. >> I'm using the latest tiger-stripe josif release >> and the soap generator in the sandbox at >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >> >> On the RAM Dependencies project I get the >> following error when I try to generate using the >> Soap Generator. >> Unexpected error while merging >> 'templates/IteratorAnalyzer.vm' template: >> Invocation of method 'collectBulkPotentialTypes' >> in class >> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >> threw exception java.lang.NullPointerException @ >> templates/IteratorAnalyzer.vm[6,19]. Generation >> may be incomplete. >> >> Cheers >> Craig >> >> >> >> >> >> On 12/07/2012 16:08, Flauw, Marc wrote: >> >> Hi Xose, >> >> Thanks, I will give a try to your SOAP >> generator in the sandbox. >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez >> [mailto:xr...@op...] >> *Sent:* Thursday, July 12, 2012 5:05 PM >> *To:* Flauw, Marc >> *Cc:* ope...@li... >> <mailto:ope...@li...> >> *Subject:* Re: Urgent questions on SOAP Generator >> >> Hi Marc at the moment I don't have full >> avialability but I am going to speed up the >> developments that you detail. >> >> I have developed a workaround to solve the >> issue around the allPackages context >> variable. The new version of Tigerstripe >> solves the problem of get the rigth package >> elements but using a Proxy implementation >> inside makes errors in some casts performed >> in the calculation of the closure. The >> workaround in my tests works with the three >> versions of Tigerstripe in the RAM and SPM >> projects but I cannot perform more tests. It >> will be interesting if someone could also >> test it. The workaround change a lot of >> clasess so I put the workaround in the >> sandbox to be tested prior to checkin in the >> trunk of Soap Generator. If the test are ok, >> then I will checkin to the Trunk >> >> This issue takes me a lot of time and now we >> follow with the URI support that expect to >> get as soon as possible, but these days I >> don't have availability because of my surgery. >> >> >> Regards >> >> El 11/07/2012 16:06, Flauw, Marc escribió: >> >> Hi Xose, >> >> There is no update following your last >> mail on this topic and the SOAP Generator >> trunk is not updated, so would it be >> possible from you or one of your backup >> to get a status on the test of this >> workaround. >> >> Also, the support of uri and url in the >> SOAP Generator is needed for JOSIF V1.1.2 >> and I haven't seen any update on this. >> >> These 2 points would be critical for the >> release of JOSIF V1.1.2. >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez >> [mailto:xr...@op...] >> *Sent:* Wednesday, July 04, 2012 9:31 AM >> *To:* Flauw, Marc >> *Cc:* ope...@li... >> <mailto:ope...@li...> >> *Subject:* Re: [Openoss-devel] FW: >> [tigerstripe-dev] Critical bug for JOSIF >> >> Thanks Marc I've uploaded a workaround in >> JOSIF development in URL >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >> >> I will test the new version now. >> >> >> Regards >> >> El 04/07/2012 7:36, Flauw, Marc escribió: >> >> FYI >> >> *From:*tig...@ec... >> <mailto:tig...@ec...> >> [mailto:tig...@ec...] >> *On Behalf Of *Duncan Keysell (dkeysell) >> *Sent:* Tuesday, July 03, 2012 7:04 PM >> *To:* Tigerstripe developers list >> *Subject:* Re: [tigerstripe-dev] >> Critical bug for JOSIF >> >> Hi, >> >> This fix has now been pushed to the >> josif update site. >> >> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >> >> Thanks >> >> Duncan >> >> *From: *<Flauw>, Marc >> <Mar...@hp... >> <mailto:Mar...@hp...>> >> *Reply-To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Date: *Friday, 29 June 2012 16:39 >> *To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Subject: *Re: [tigerstripe-dev] >> Critical bug for JOSIF >> >> Duncan, >> >> Thanks for the investigation. >> >> If you fixed a bug, then please yes, >> push the fix to the josif update site. >> >> Best regards >> >> Marc >> >> *From:*tig...@ec... >> <mailto:tig...@ec...> >> [mailto:tig...@ec...] >> *On Behalf Of *Duncan Keysell (dkeysell) >> *Sent:* Friday, June 29, 2012 5:27 PM >> *To:* Tigerstripe developers list >> *Subject:* Re: [tigerstripe-dev] >> Critical bug for JOSIF >> >> Hi Marc, >> >> It took me quite a bit of >> investigation but I don't think there >> is an issue here: >> >> In order to get $all* collections of >> the TS Velocity context populated the >> user needs to uncheck the "Run All >> Rules as Local" checkbox in the >> Generation section of the Advanced >> tab of the tigerstripe.xml or the >> model project. This is probably a new >> feature since you last updated (it >> was new to me). >> >> Please can you give this a try? >> >> However, when I was looking at this I >> found it was not possible to add a >> new Module Dependency to a >> Tigerstripe model project. This bug >> has now been fixed. Do you want us to >> push another release to the JOSIF >> update site with this fix? >> >> Thanks, >> >> Duncan >> >> *From: *<Flauw>, Marc >> <Mar...@hp... >> <mailto:Mar...@hp...>> >> *Reply-To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Date: *Thursday, 28 June 2012 09:55 >> *To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Subject: *[tigerstripe-dev] Critical >> bug for JOSIF >> >> Hi Tigerstripe team, >> >> In our current version of JOSIF, we >> are using an old version of >> Tigerstripe from Feb 2011. >> >> We are testing the new Tigerstripe >> version you made for us, which >> corresponds to I53 for integration in >> our new JOSIF version and we have >> found a critical bug that xose has >> filled in bugzilla: *Bug 383728 >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728> >> * >> >> We are using dependency modules >> systematically in our projects and >> the behavior has changed from the >> version we use in the previous >> version of JOSIF, >> >> When trying to get all the artifacts >> inside the project with the variable >> $allPackages we got different >> responses in the two versions of >> Tigerstripe. In the new version, only >> the model packages are shown. >> >> Is there now a different way of >> getting model and dependency packages >> all together? >> >> This is a show-stopper for us. >> >> Thanks for your support, >> >> Best regards >> >> Marc >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> >> Exclusive live event will cover all the ways today's security and >> >> threat landscape has changed and how IT managers can respond. Discussions >> >> will include endpoint security, mobile security and the latest in malware >> >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> >> >> _______________________________________________ >> >> Openoss-devel mailing list >> >> Ope...@li... <mailto:Ope...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 >> <tel:%2B%2034%20986%20410%20091> (ext) >> 206 | M/ +34 675 550 029 >> <tel:%2B34%20675%20550%20029> >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> <mime-attachment.jpg> >> <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 >> <tel:%2B%2034%20986%20410%20091> (ext) 206 | >> M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> <mime-attachment.jpg> >> <http://optarecoolvendor.com> >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> >> Exclusive live event will cover all the ways today's security and >> >> threat landscape has changed and how IT managers can respond. Discussions >> >> will include endpoint security, mobile security and the latest in malware >> >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> _______________________________________________ >> >> Openoss-devel mailing list >> >> Ope...@li... <mailto:Ope...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> >> >> >> -- >> Antes de imprimir este mensaje, asegúrese de que >> es necesario. Proteger el medio ambiente está en >> nuestra mano >> >> Before printing this message, be sure it's >> needed. Protecting the enviroment is in our hands >> >> >> >> Este mensaje se dirige exclusivamente a su >> destinatario y puede contener información >> CONFIDENCIAL sometida a secreto profesional o >> cuya divulgación esté prohibida en virtud de la >> legislación vigente. Cualquier opinión en él >> contenida es exclusiva de su autor y no >> representa necesariamente la opinión de la >> empresa. Si ha recibido este mensaje por error, >> le rogamos nos lo comunique inmediatamente por >> esta misma vía y proceda a su destrucción. >> >> This message contains information that may be >> privileged or confidential and is the property >> of Optare Solutions. It is intended only for the >> person to whom it is addressed. If you are not >> the intended recipient, you are not authorized to >> read, print, retain, copy, disseminate, >> distribute, or use this message or any part >> thereof. If you receive this message in error, >> please notify the sender immediately and delete >> all copies of this message. >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Description: Description: Optare Solutions >> <http://optarecoolvendor.com/> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Description: Optare Solutions <http://optarecoolvendor.com/> >> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-26 07:06:05
|
Hi again, I have found the problem. I have created a new clean scenario and then I could reproduce the error. It was because of the new version of Tigerstripe doesn't support the function TigerstripeCore.findModelProjectByID(ifArtifact.getProjectDescriptor().getIProjectDetails().getModelId()). This function was used to solve the problem derived of found a null value in some use cases in the function call getProject().getArtifactManagerSession(); in the ISessionArtifact class. Fortuntately the method now works well so the prior workaround was removed. I have commited the change again in the sandbox. Please, if you can ,check it and feedback the result. Best regards. El 24/07/2012 13:18, Flauw, Marc escribió: > > Hi Xose, > > I recompiled RAM using mvn clean, then mvn install and I have the same > error as Craig: > > /[exec] [TIP_Soap_Generator(1.1)Project: org.tmforum.tip.ram.dep > version=1.0, Plugin: TIP_Soap_Generator(1.1) version=1.1]/ > > /[exec] Error: Unexpected error while merging > 'templates/IteratorAnalyzer.vm' template: Invocation of method > 'collectBulkPotentialTypes' in class > org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw > exception java.lang.NullPointerException @ > templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete./ > > /[exec] org.eclipse.tigerstripe.workbench.TigerstripeException: > Unexpected error while merging 'templates/IteratorAnalyzer.vm' > template: Invocation of method 'collectBulkPotentialTypes' in class > org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw > exception java.lang.NullPointerException @ > templates/IteratorAnalyzer.vm[6,19]/ > > I have this error in both Dependencies and Model project. > > RAM projects are aligned with SVN. > > My environment: > > Windows 7, 64 bits, > > Eclipse Java EE IDE for Web Developers. Version: Helios Service > Release 2 Build id: 20110301-1815 > > Tigerstripe 0.7.0.201206291233 > > Generators uploaded on Friday July 13. SOAP Generator coming from your > sandbox (also loaded on July 13). > > Best regards > > Marc > > *From:*Craig Gallen [mailto:gal...@go...] *On Behalf Of > *Craig Gallen > *Sent:* Tuesday, July 24, 2012 11:37 AM > *To:* 'Xose Ramon Sousa Vazquez'; 'Craig Gallen (opennms)' > *Cc:* Flauw, Marc; ope...@li... > *Subject:* RE: [Openoss-devel] Urgent questions on SOAP Generator > > Hi, > > Thanks for investigating. I thought i was using the latest tigerstripe > release from > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > which was update by tigerstripe recently. > > However I am not near my computer today so i cant check until later.. > I'll get you the version tomorrow. > > Craig > > *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] > *Sent:* 24 July 2012 09:52 > *To:* Craig Gallen (opennms) > *Cc:* Flauw, Marc; ope...@li... > *Subject:* Re: [Openoss-devel] Urgent questions on SOAP Generator > > Hi Craig I have evaluated the use case and I can reproduce your error > with the Tigerstripe version v0.7.0.201207021234. But with the > recommended version included in the URL > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > (version v0.7.0.201206291233) this problem doesn't happen. Please > could you give me details about which Tigerstripe version are you > using and test the deployment with the version v0.7.0.201206291233. > Meanwhile I will check the problem in the new Tigerstripe version. > > > Regards > > > > > El 23/07/2012 10:34, Craig Gallen (opennms) escribió: > > Hi, > The dependencies project is built as part of the Maven build and > the generated artefacts are used in the RI. So the dependencies > project has to work properly on its own. BTW I would be suspicious > if the project cannot be built stand alone before it is imported > into the Model project > Cheers > Craig > > On 23/07/2012 09:29, Xose Ramón Sousa wrote: > > Hi Craig I am going to perform that test. I have not performed > because of I believe that the dependencies project only would > be exported to be included in the model project. > > For my understanding I thought that the Soap generation only > is passed on the model project > > I will review this use case and fix the code > > Best regards > > Enviado desde mi iPhone > > > El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" > <cg...@op... <mailto:cg...@op...>> escribió: > > Hi > Have you tried running tigerstripe on the dependencies > project itself from the dashboard? The RAM Model project > works OK but the dependencies project cannot be built on > its own. > > Craig > > > On 23/07/2012 02:01, Xose Ramón Sousa wrote: > > Hi Craig thanks for the feedback. I have tested in the > RAM project, importing the dependencies project as a > module and it worked. > > Please could you give me the details of how do you > perform the test to be sure that I can reporduce the > error. > > Regards > > 2012/7/21 Craig Gallen (opennms) <cg...@op... > <mailto:cg...@op...>> > > Hi, > > I tried out the soap generator in the sandbox. > I'm using the latest tiger-stripe josif release and > the soap generator in the sandbox at > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > On the RAM Dependencies project I get the following > error when I try to generate using the Soap Generator. > Unexpected error while merging > 'templates/IteratorAnalyzer.vm' template: Invocation > of method 'collectBulkPotentialTypes' in class > org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer > threw exception java.lang.NullPointerException @ > templates/IteratorAnalyzer.vm[6,19]. Generation may be > incomplete. > > Cheers > Craig > > > > > On 12/07/2012 16:08, Flauw, Marc wrote: > > Hi Xose, > > Thanks, I will give a try to your SOAP generator > in the sandbox. > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez > [mailto:xr...@op...] > *Sent:* Thursday, July 12, 2012 5:05 PM > *To:* Flauw, Marc > *Cc:* ope...@li... > <mailto:ope...@li...> > *Subject:* Re: Urgent questions on SOAP Generator > > Hi Marc at the moment I don't have full > avialability but I am going to speed up the > developments that you detail. > > I have developed a workaround to solve the issue > around the allPackages context variable. The new > version of Tigerstripe solves the problem of get > the rigth package elements but using a Proxy > implementation inside makes errors in some casts > performed in the calculation of the closure. The > workaround in my tests works with the three > versions of Tigerstripe in the RAM and SPM > projects but I cannot perform more tests. It will > be interesting if someone could also test it. The > workaround change a lot of clasess so I put the > workaround in the sandbox to be tested prior to > checkin in the trunk of Soap Generator. If the > test are ok, then I will checkin to the Trunk > > This issue takes me a lot of time and now we > follow with the URI support that expect to get as > soon as possible, but these days I don't have > availability because of my surgery. > > > Regards > > El 11/07/2012 16:06, Flauw, Marc escribió: > > Hi Xose, > > There is no update following your last mail on > this topic and the SOAP Generator trunk is not > updated, so would it be possible from you or > one of your backup to get a status on the test > of this workaround. > > Also, the support of uri and url in the SOAP > Generator is needed for JOSIF V1.1.2 and I > haven't seen any update on this. > > These 2 points would be critical for the > release of JOSIF V1.1.2. > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez > [mailto:xr...@op...] > *Sent:* Wednesday, July 04, 2012 9:31 AM > *To:* Flauw, Marc > *Cc:* ope...@li... > <mailto:ope...@li...> > *Subject:* Re: [Openoss-devel] FW: > [tigerstripe-dev] Critical bug for JOSIF > > Thanks Marc I've uploaded a workaround in > JOSIF development in URL > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > I will test the new version now. > > > Regards > > El 04/07/2012 7:36, Flauw, Marc escribió: > > FYI > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] > *On Behalf Of *Duncan Keysell (dkeysell) > *Sent:* Tuesday, July 03, 2012 7:04 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical > bug for JOSIF > > Hi, > > This fix has now been pushed to the josif > update site. > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > Thanks > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... > <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers > <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Friday, 29 June 2012 16:39 > *To: *Tigerstripe Developers > <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *Re: [tigerstripe-dev] Critical > bug for JOSIF > > Duncan, > > Thanks for the investigation. > > If you fixed a bug, then please yes, push > the fix to the josif update site. > > Best regards > > Marc > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] > *On Behalf Of *Duncan Keysell (dkeysell) > *Sent:* Friday, June 29, 2012 5:27 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical > bug for JOSIF > > Hi Marc, > > It took me quite a bit of investigation > but I don't think there is an issue here: > > In order to get $all* collections of the > TS Velocity context populated the user > needs to uncheck the "Run All Rules as > Local" checkbox in the Generation section > of the Advanced tab of the tigerstripe.xml > or the model project. This is probably a > new feature since you last updated (it was > new to me). > > Please can you give this a try? > > However, when I was looking at this I > found it was not possible to add a new > Module Dependency to a Tigerstripe model > project. This bug has now been fixed. Do > you want us to push another release to the > JOSIF update site with this fix? > > Thanks, > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... > <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers > <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Thursday, 28 June 2012 09:55 > *To: *Tigerstripe Developers > <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *[tigerstripe-dev] Critical bug > for JOSIF > > Hi Tigerstripe team, > > In our current version of JOSIF, we are > using an old version of Tigerstripe from > Feb 2011. > > We are testing the new Tigerstripe version > you made for us, which corresponds to I53 > for integration in our new JOSIF version > and we have found a critical bug that xose > has filled in bugzilla: *Bug 383728 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728> > * > > We are using dependency modules > systematically in our projects and the > behavior has changed from the version we > use in the previous version of JOSIF, > > When trying to get all the artifacts > inside the project with the variable > $allPackages we got different responses in > the two versions of Tigerstripe. In the > new version, only the model packages are > shown. > > Is there now a different way of getting > model and dependency packages all together? > > This is a show-stopper for us. > > Thanks for your support, > > Best regards > > Marc > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > > Openoss-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/openoss-devel > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS > Technologies, Director I+D > T/ + 34 986 410 091 > <tel:%2B%2034%20986%20410%20091> (ext) 206 | > M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> > www.optaresolutions.com > <http://www.optaresolutions.com> > <mime-attachment.jpg> > <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS > Technologies, Director I+D > T/ + 34 986 410 091 > <tel:%2B%2034%20986%20410%20091> (ext) 206 | M/ > +34 675 550 029 <tel:%2B34%20675%20550%20029> > www.optaresolutions.com > <http://www.optaresolutions.com> > <mime-attachment.jpg> <http://optarecoolvendor.com> > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Openoss-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/openoss-devel > > > > -- > Antes de imprimir este mensaje, asegúrese de que es > necesario. Proteger el medio ambiente está en nuestra mano > > Before printing this message, be sure it's needed. > Protecting the enviroment is in our hands > > > > Este mensaje se dirige exclusivamente a su > destinatario y puede contener información CONFIDENCIAL > sometida a secreto profesional o cuya divulgación esté > prohibida en virtud de la legislación vigente. > Cualquier opinión en él contenida es exclusiva de su > autor y no representa necesariamente la opinión de la > empresa. Si ha recibido este mensaje por error, le > rogamos nos lo comunique inmediatamente por esta misma > vía y proceda a su destrucción. > > This message contains information that may be > privileged or confidential and is the property of > Optare Solutions. It is intended only for the person > to whom it is addressed. If you are not the intended > recipient, you are not authorized to read, print, > retain, copy, disseminate, distribute, or use this > message or any part thereof. If you receive this > message in error, please notify the sender immediately > and delete all copies of this message. > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Description: Optare Solutions <http://optarecoolvendor.com/> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-24 08:53:05
|
Hi Craig I have evaluated the use case and I can reproduce your error with the Tigerstripe version v0.7.0.201207021234. But with the recommended version included in the URL http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ (version v0.7.0.201206291233) this problem doesn't happen. Please could you give me details about which Tigerstripe version are you using and test the deployment with the version v0.7.0.201206291233. Meanwhile I will check the problem in the new Tigerstripe version. Regards El 23/07/2012 10:34, Craig Gallen (opennms) escribió: > Hi, > The dependencies project is built as part of the Maven build and the > generated artefacts are used in the RI. So the dependencies project > has to work properly on its own. BTW I would be suspicious if the > project cannot be built stand alone before it is imported into the > Model project > Cheers > Craig > > > > On 23/07/2012 09:29, Xose Ramón Sousa wrote: >> Hi Craig I am going to perform that test. I have not performed >> because of I believe that the dependencies project only would be >> exported to be included in the model project. >> >> For my understanding I thought that the Soap generation only is >> passed on the model project >> I will review this use case and fix the code >> >> Best regards >> >> Enviado desde mi iPhone >> >> El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" >> <cg...@op... <mailto:cg...@op...>> escribió: >> >>> Hi >>> Have you tried running tigerstripe on the dependencies project >>> itself from the dashboard? The RAM Model project works OK but the >>> dependencies project cannot be built on its own. >>> >>> Craig >>> >>> >>> >>> >>> On 23/07/2012 02:01, Xose Ramón Sousa wrote: >>>> Hi Craig thanks for the feedback. I have tested in the RAM project, >>>> importing the dependencies project as a module and it worked. >>>> >>>> Please could you give me the details of how do you perform the test >>>> to be sure that I can reporduce the error. >>>> >>>> Regards >>>> >>>> >>>> 2012/7/21 Craig Gallen (opennms) <cg...@op... >>>> <mailto:cg...@op...>> >>>> >>>> Hi, >>>> >>>> I tried out the soap generator in the sandbox. >>>> I'm using the latest tiger-stripe josif release and the soap >>>> generator in the sandbox at >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>>> >>>> On the RAM Dependencies project I get the following error when >>>> I try to generate using the Soap Generator. >>>> Unexpected error while merging 'templates/IteratorAnalyzer.vm' >>>> template: Invocation of method 'collectBulkPotentialTypes' in >>>> class >>>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>>> threw exception java.lang.NullPointerException @ >>>> templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. >>>> >>>> Cheers >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> On 12/07/2012 16:08, Flauw, Marc wrote: >>>>> >>>>> Hi Xose, >>>>> >>>>> Thanks, I will give a try to your SOAP generator in the sandbox. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez >>>>> [mailto:xr...@op...] >>>>> *Sent:* Thursday, July 12, 2012 5:05 PM >>>>> *To:* Flauw, Marc >>>>> *Cc:* ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* Re: Urgent questions on SOAP Generator >>>>> >>>>> Hi Marc at the moment I don't have full avialability but I am >>>>> going to speed up the developments that you detail. >>>>> >>>>> I have developed a workaround to solve the issue around the >>>>> allPackages context variable. The new version of Tigerstripe >>>>> solves the problem of get the rigth package elements but using >>>>> a Proxy implementation inside makes errors in some casts >>>>> performed in the calculation of the closure. The workaround in >>>>> my tests works with the three versions of Tigerstripe in the >>>>> RAM and SPM projects but I cannot perform more tests. It will >>>>> be interesting if someone could also test it. The workaround >>>>> change a lot of clasess so I put the workaround in the sandbox >>>>> to be tested prior to checkin in the trunk of Soap Generator. >>>>> If the test are ok, then I will checkin to the Trunk >>>>> >>>>> This issue takes me a lot of time and now we follow with the >>>>> URI support that expect to get as soon as possible, but these >>>>> days I don't have availability because of my surgery. >>>>> >>>>> >>>>> Regards >>>>> >>>>> El 11/07/2012 16:06, Flauw, Marc escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> There is no update following your last mail on this topic >>>>> and the SOAP Generator trunk is not updated, so would it >>>>> be possible from you or one of your backup to get a status >>>>> on the test of this workaround. >>>>> >>>>> Also, the support of uri and url in the SOAP Generator is >>>>> needed for JOSIF V1.1.2 and I haven’t seen any update on >>>>> this. >>>>> >>>>> These 2 points would be critical for the release of JOSIF >>>>> V1.1.2. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez >>>>> [mailto:xr...@op...] >>>>> *Sent:* Wednesday, July 04, 2012 9:31 AM >>>>> *To:* Flauw, Marc >>>>> *Cc:* ope...@li... >>>>> <mailto:ope...@li...> >>>>> *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] >>>>> Critical bug for JOSIF >>>>> >>>>> Thanks Marc I've uploaded a workaround in JOSIF >>>>> development in URL >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>>>> >>>>> I will test the new version now. >>>>> >>>>> >>>>> Regards >>>>> >>>>> El 04/07/2012 7:36, Flauw, Marc escribió: >>>>> >>>>> FYI >>>>> >>>>> *From:*tig...@ec... >>>>> <mailto:tig...@ec...> >>>>> [mailto:tig...@ec...] *On >>>>> Behalf Of *Duncan Keysell (dkeysell) >>>>> *Sent:* Tuesday, July 03, 2012 7:04 PM >>>>> *To:* Tigerstripe developers list >>>>> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >>>>> >>>>> Hi, >>>>> >>>>> This fix has now been pushed to the josif update site. >>>>> >>>>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>>>> >>>>> Thanks >>>>> >>>>> Duncan >>>>> >>>>> *From: *<Flauw>, Marc <Mar...@hp... >>>>> <mailto:Mar...@hp...>> >>>>> *Reply-To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Date: *Friday, 29 June 2012 16:39 >>>>> *To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF >>>>> >>>>> Duncan, >>>>> >>>>> Thanks for the investigation. >>>>> >>>>> If you fixed a bug, then please yes, push the fix to >>>>> the josif update site. >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*tig...@ec... >>>>> <mailto:tig...@ec...> >>>>> [mailto:tig...@ec...] *On >>>>> Behalf Of *Duncan Keysell (dkeysell) >>>>> *Sent:* Friday, June 29, 2012 5:27 PM >>>>> *To:* Tigerstripe developers list >>>>> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >>>>> >>>>> Hi Marc, >>>>> >>>>> It took me quite a bit of investigation but I don't >>>>> think there is an issue here: >>>>> >>>>> In order to get $all* collections of the TS Velocity >>>>> context populated the user needs to uncheck the "Run >>>>> All Rules as Local" checkbox in the Generation section >>>>> of the Advanced tab of the tigerstripe.xml or the >>>>> model project. This is probably a new feature since >>>>> you last updated (it was new to me). >>>>> >>>>> Please can you give this a try? >>>>> >>>>> However, when I was looking at this I found it was not >>>>> possible to add a new Module Dependency to a >>>>> Tigerstripe model project. This bug has now been >>>>> fixed. Do you want us to push another release to the >>>>> JOSIF update site with this fix? >>>>> >>>>> Thanks, >>>>> >>>>> Duncan >>>>> >>>>> *From: *<Flauw>, Marc <Mar...@hp... >>>>> <mailto:Mar...@hp...>> >>>>> *Reply-To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Date: *Thursday, 28 June 2012 09:55 >>>>> *To: *Tigerstripe Developers >>>>> <tig...@ec... >>>>> <mailto:tig...@ec...>> >>>>> *Subject: *[tigerstripe-dev] Critical bug for JOSIF >>>>> >>>>> Hi Tigerstripe team, >>>>> >>>>> In our current version of JOSIF, we are using an old >>>>> version of Tigerstripe from Feb 2011. >>>>> >>>>> We are testing the new Tigerstripe version you made >>>>> for us, which corresponds to I53 for integration in >>>>> our new JOSIF version and we have found a critical bug >>>>> that xose has filled in bugzilla: *Bug 383728 >>>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728>* >>>>> >>>>> We are using dependency modules systematically in our >>>>> projects and the behavior has changed from the >>>>> version we use in the previous version of JOSIF, >>>>> >>>>> When trying to get all the artifacts inside the >>>>> project with the variable $allPackages we got >>>>> different responses in the two versions of >>>>> Tigerstripe. In the new version, only the model >>>>> packages are shown. >>>>> >>>>> Is there now a different way of getting model and >>>>> dependency packages all together? >>>>> >>>>> This is a show-stopper for us. >>>>> >>>>> Thanks for your support, >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Live Security Virtual Conference >>>>> >>>>> Exclusive live event will cover all the ways today's security and >>>>> >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> >>>>> will include endpoint security, mobile security and the latest in malware >>>>> >>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> Openoss-devel mailing list >>>>> >>>>> Ope...@li... <mailto:Ope...@li...> >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) >>>>> 206 | M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> <mime-attachment.jpg> <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) 206 >>>>> | M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> <mime-attachment.jpg> <http://optarecoolvendor.com> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Openoss-devel mailing list >>>>> Ope...@li... <mailto:Ope...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>> >>>> >>>> >>>> >>>> -- >>>> Antes de imprimir este mensaje, asegúrese de que es necesario. >>>> Proteger el medio ambiente está en nuestra mano >>>> >>>> Before printing this message, be sure it's needed. Protecting the >>>> enviroment is in our hands >>>> >>>> >>>> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede >>>> contener información CONFIDENCIAL sometida a secreto profesional o >>>> cuya divulgación esté prohibida en virtud de la legislación >>>> vigente. Cualquier opinión en él contenida es exclusiva de su autor >>>> y no representa necesariamente la opinión de la empresa. Si ha >>>> recibido este mensaje por error, le rogamos nos lo comunique >>>> inmediatamente por esta misma vía y proceda a su destrucción. >>>> >>>> This message contains information that may be privileged or >>>> confidential and is the property of Optare Solutions. It is >>>> intended only for the person to whom it is addressed. If you are >>>> not the intended recipient, you are not authorized to read, print, >>>> retain, copy, disseminate, distribute, or use this message or any >>>> part thereof. If you receive this message in error, please notify >>>> the sender immediately and delete all copies of this message. >>>> >>>> >>> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-23 08:44:13
|
Hi, I looked at this. The only problem is that WADL is not yet standardised ( its a proposal but not ratified). Rather than rewriting the soap generator we could perhaps use something like XSLT to transform the WSDL into WADL. Alternatively, rather than using a WADL first approach an alternative approach might be to use the CXF ability to expose WSDL generated services services as REST by adding some additional configuration and possibly simple annotations to the generated java. CXF can than generate the WADL in reverse. http://cxf.apache.org/docs/jax-rs-and-jax-ws.html Craig On 12/07/2012 05:16, pierre gauthier wrote: > Hi Craig, > > Let me know what you think. Looks like WADL is getting there at least for Apache CXF. > > Pierre |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-23 08:34:46
|
Hi, The dependencies project is built as part of the Maven build and the generated artefacts are used in the RI. So the dependencies project has to work properly on its own. BTW I would be suspicious if the project cannot be built stand alone before it is imported into the Model project Cheers Craig On 23/07/2012 09:29, Xose Ramón Sousa wrote: > Hi Craig I am going to perform that test. I have not performed because > of I believe that the dependencies project only would be exported to > be included in the model project. > > For my understanding I thought that the Soap generation only is passed > on the model project > I will review this use case and fix the code > > Best regards > > Enviado desde mi iPhone > > El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" > <cg...@op... <mailto:cg...@op...>> escribió: > >> Hi >> Have you tried running tigerstripe on the dependencies project itself >> from the dashboard? The RAM Model project works OK but the >> dependencies project cannot be built on its own. >> >> Craig >> >> >> >> >> On 23/07/2012 02:01, Xose Ramón Sousa wrote: >>> Hi Craig thanks for the feedback. I have tested in the RAM project, >>> importing the dependencies project as a module and it worked. >>> >>> Please could you give me the details of how do you perform the test >>> to be sure that I can reporduce the error. >>> >>> Regards >>> >>> >>> 2012/7/21 Craig Gallen (opennms) <cg...@op... >>> <mailto:cg...@op...>> >>> >>> Hi, >>> >>> I tried out the soap generator in the sandbox. >>> I'm using the latest tiger-stripe josif release and the soap >>> generator in the sandbox at >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>> >>> On the RAM Dependencies project I get the following error when I >>> try to generate using the Soap Generator. >>> Unexpected error while merging 'templates/IteratorAnalyzer.vm' >>> template: Invocation of method 'collectBulkPotentialTypes' in >>> class >>> org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer >>> threw exception java.lang.NullPointerException @ >>> templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. >>> >>> Cheers >>> Craig >>> >>> >>> >>> >>> >>> On 12/07/2012 16:08, Flauw, Marc wrote: >>>> >>>> Hi Xose, >>>> >>>> Thanks, I will give a try to your SOAP generator in the sandbox. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> *From:*Xose Ramon Sousa Vazquez >>>> [mailto:xr...@op...] >>>> *Sent:* Thursday, July 12, 2012 5:05 PM >>>> *To:* Flauw, Marc >>>> *Cc:* ope...@li... >>>> <mailto:ope...@li...> >>>> *Subject:* Re: Urgent questions on SOAP Generator >>>> >>>> Hi Marc at the moment I don't have full avialability but I am >>>> going to speed up the developments that you detail. >>>> >>>> I have developed a workaround to solve the issue around the >>>> allPackages context variable. The new version of Tigerstripe >>>> solves the problem of get the rigth package elements but using >>>> a Proxy implementation inside makes errors in some casts >>>> performed in the calculation of the closure. The workaround in >>>> my tests works with the three versions of Tigerstripe in the >>>> RAM and SPM projects but I cannot perform more tests. It will >>>> be interesting if someone could also test it. The workaround >>>> change a lot of clasess so I put the workaround in the sandbox >>>> to be tested prior to checkin in the trunk of Soap Generator. >>>> If the test are ok, then I will checkin to the Trunk >>>> >>>> This issue takes me a lot of time and now we follow with the >>>> URI support that expect to get as soon as possible, but these >>>> days I don't have availability because of my surgery. >>>> >>>> >>>> Regards >>>> >>>> El 11/07/2012 16:06, Flauw, Marc escribió: >>>> >>>> Hi Xose, >>>> >>>> There is no update following your last mail on this topic >>>> and the SOAP Generator trunk is not updated, so would it be >>>> possible from you or one of your backup to get a status on >>>> the test of this workaround. >>>> >>>> Also, the support of uri and url in the SOAP Generator is >>>> needed for JOSIF V1.1.2 and I haven’t seen any update on this. >>>> >>>> These 2 points would be critical for the release of JOSIF >>>> V1.1.2. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> *From:*Xose Ramon Sousa Vazquez >>>> [mailto:xr...@op...] >>>> *Sent:* Wednesday, July 04, 2012 9:31 AM >>>> *To:* Flauw, Marc >>>> *Cc:* ope...@li... >>>> <mailto:ope...@li...> >>>> *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] >>>> Critical bug for JOSIF >>>> >>>> Thanks Marc I've uploaded a workaround in JOSIF development >>>> in URL >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >>>> >>>> I will test the new version now. >>>> >>>> >>>> Regards >>>> >>>> El 04/07/2012 7:36, Flauw, Marc escribió: >>>> >>>> FYI >>>> >>>> *From:*tig...@ec... >>>> <mailto:tig...@ec...> >>>> [mailto:tig...@ec...] *On Behalf >>>> Of *Duncan Keysell (dkeysell) >>>> *Sent:* Tuesday, July 03, 2012 7:04 PM >>>> *To:* Tigerstripe developers list >>>> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >>>> >>>> Hi, >>>> >>>> This fix has now been pushed to the josif update site. >>>> >>>> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >>>> >>>> Thanks >>>> >>>> Duncan >>>> >>>> *From: *<Flauw>, Marc <Mar...@hp... >>>> <mailto:Mar...@hp...>> >>>> *Reply-To: *Tigerstripe Developers >>>> <tig...@ec... >>>> <mailto:tig...@ec...>> >>>> *Date: *Friday, 29 June 2012 16:39 >>>> *To: *Tigerstripe Developers >>>> <tig...@ec... >>>> <mailto:tig...@ec...>> >>>> *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF >>>> >>>> Duncan, >>>> >>>> Thanks for the investigation. >>>> >>>> If you fixed a bug, then please yes, push the fix to >>>> the josif update site. >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> *From:*tig...@ec... >>>> <mailto:tig...@ec...> >>>> [mailto:tig...@ec...] *On Behalf >>>> Of *Duncan Keysell (dkeysell) >>>> *Sent:* Friday, June 29, 2012 5:27 PM >>>> *To:* Tigerstripe developers list >>>> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >>>> >>>> Hi Marc, >>>> >>>> It took me quite a bit of investigation but I don't >>>> think there is an issue here: >>>> >>>> In order to get $all* collections of the TS Velocity >>>> context populated the user needs to uncheck the "Run >>>> All Rules as Local" checkbox in the Generation section >>>> of the Advanced tab of the tigerstripe.xml or the model >>>> project. This is probably a new feature since you last >>>> updated (it was new to me). >>>> >>>> Please can you give this a try? >>>> >>>> However, when I was looking at this I found it was not >>>> possible to add a new Module Dependency to a >>>> Tigerstripe model project. This bug has now been fixed. >>>> Do you want us to push another release to the JOSIF >>>> update site with this fix? >>>> >>>> Thanks, >>>> >>>> Duncan >>>> >>>> *From: *<Flauw>, Marc <Mar...@hp... >>>> <mailto:Mar...@hp...>> >>>> *Reply-To: *Tigerstripe Developers >>>> <tig...@ec... >>>> <mailto:tig...@ec...>> >>>> *Date: *Thursday, 28 June 2012 09:55 >>>> *To: *Tigerstripe Developers >>>> <tig...@ec... >>>> <mailto:tig...@ec...>> >>>> *Subject: *[tigerstripe-dev] Critical bug for JOSIF >>>> >>>> Hi Tigerstripe team, >>>> >>>> In our current version of JOSIF, we are using an old >>>> version of Tigerstripe from Feb 2011. >>>> >>>> We are testing the new Tigerstripe version you made for >>>> us, which corresponds to I53 for integration in our new >>>> JOSIF version and we have found a critical bug that >>>> xose has filled in bugzilla: *Bug 383728 >>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id83728>* >>>> >>>> We are using dependency modules systematically in our >>>> projects and the behavior has changed from the version >>>> we use in the previous version of JOSIF, >>>> >>>> When trying to get all the artifacts inside the project >>>> with the variable $allPackages we got different >>>> responses in the two versions of Tigerstripe. In the >>>> new version, only the model packages are shown. >>>> >>>> Is there now a different way of getting model and >>>> dependency packages all together? >>>> >>>> This is a show-stopper for us. >>>> >>>> Thanks for your support, >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Live Security Virtual Conference >>>> >>>> Exclusive live event will cover all the ways today's security and >>>> >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> >>>> will include endpoint security, mobile security and the latest in malware >>>> >>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Openoss-devel mailing list >>>> >>>> Ope...@li... <mailto:Ope...@li...> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>> Director I+D >>>> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) >>>> 206 | M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> <mime-attachment.jpg> <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) 206 >>>> | M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> <mime-attachment.jpg> <http://optarecoolvendor.com> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> >>>> >>>> _______________________________________________ >>>> Openoss-devel mailing list >>>> Ope...@li... <mailto:Ope...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/openoss-devel >>> >>> >>> >>> >>> -- >>> Antes de imprimir este mensaje, asegúrese de que es necesario. >>> Proteger el medio ambiente está en nuestra mano >>> >>> Before printing this message, be sure it's needed. Protecting the >>> enviroment is in our hands >>> >>> >>> >>> Este mensaje se dirige exclusivamente a su destinatario y puede >>> contener información CONFIDENCIAL sometida a secreto profesional o >>> cuya divulgación esté prohibida en virtud de la legislación vigente. >>> Cualquier opinión en él contenida es exclusiva de su autor y no >>> representa necesariamente la opinión de la empresa. Si ha recibido >>> este mensaje por error, le rogamos nos lo comunique inmediatamente >>> por esta misma vía y proceda a su destrucción. >>> >>> This message contains information that may be privileged or >>> confidential and is the property of Optare Solutions. It is intended >>> only for the person to whom it is addressed. If you are not the >>> intended recipient, you are not authorized to read, print, retain, >>> copy, disseminate, distribute, or use this message or any part >>> thereof. If you receive this message in error, please notify the >>> sender immediately and delete all copies of this message. >>> >>> >> |
|
From: Xose R. S. <xr...@op...> - 2012-07-23 08:30:06
|
Hi Craig I am going to perform that test. I have not performed because of I believe that the dependencies project only would be exported to be included in the model project. For my understanding I thought that the Soap generation only is passed on the model project I will review this use case and fix the code Best regards Enviado desde mi iPhone El 23/07/2012, a las 10:19, "Craig Gallen (opennms)" <cg...@op...> escribió: Hi Have you tried running tigerstripe on the dependencies project itself from the dashboard? The RAM Model project works OK but the dependencies project cannot be built on its own. Craig On 23/07/2012 02:01, Xose Ramón Sousa wrote: Hi Craig thanks for the feedback. I have tested in the RAM project, importing the dependencies project as a module and it worked. Please could you give me the details of how do you perform the test to be sure that I can reporduce the error. Regards 2012/7/21 Craig Gallen (opennms) <cg...@op...> > Hi, > > I tried out the soap generator in the sandbox. > I'm using the latest tiger-stripe josif release and the soap generator in > the sandbox at > > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > On the RAM Dependencies project I get the following error when I try to > generate using the Soap Generator. > Unexpected error while merging 'templates/IteratorAnalyzer.vm' template: > Invocation of method 'collectBulkPotentialTypes' in class > org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw > exception java.lang.NullPointerException @ > templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. > > Cheers > Craig > > > > > > On 12/07/2012 16:08, Flauw, Marc wrote: > > Hi Xose, > > > > Thanks, I will give a try to your SOAP generator in the sandbox. > > > > Best regards > > > > Marc > > > > *From:* Xose Ramon Sousa Vazquez [mailto:xr...@op...<xr...@op...>] > > *Sent:* Thursday, July 12, 2012 5:05 PM > *To:* Flauw, Marc > *Cc:* ope...@li... > *Subject:* Re: Urgent questions on SOAP Generator > > > > Hi Marc at the moment I don't have full avialability but I am going to > speed up the developments that you detail. > > I have developed a workaround to solve the issue around the allPackages > context variable. The new version of Tigerstripe solves the problem of get > the rigth package elements but using a Proxy implementation inside makes > errors in some casts performed in the calculation of the closure. The > workaround in my tests works with the three versions of Tigerstripe in the > RAM and SPM projects but I cannot perform more tests. It will be > interesting if someone could also test it. The workaround change a lot of > clasess so I put the workaround in the sandbox to be tested prior to > checkin in the trunk of Soap Generator. If the test are ok, then I will > checkin to the Trunk > > This issue takes me a lot of time and now we follow with the URI support > that expect to get as soon as possible, but these days I don't have > availability because of my surgery. > > > Regards > > El 11/07/2012 16:06, Flauw, Marc escribió: > > Hi Xose, > > > > There is no update following your last mail on this topic and the SOAP > Generator trunk is not updated, so would it be possible from you or one of > your backup to get a status on the test of this workaround. > > > > Also, the support of uri and url in the SOAP Generator is needed for JOSIF > V1.1.2 and I haven’t seen any update on this. > > > > These 2 points would be critical for the release of JOSIF V1.1.2. > > > > Best regards > > > > Marc > > > > *From:* Xose Ramon Sousa Vazquez [mailto:xr...@op...<xr...@op...>] > > *Sent:* Wednesday, July 04, 2012 9:31 AM > *To:* Flauw, Marc > *Cc:* ope...@li... > *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] Critical bug for > JOSIF > > > > Thanks Marc I've uploaded a workaround in JOSIF development in URL > > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > I will test the new version now. > > > Regards > > El 04/07/2012 7:36, Flauw, Marc escribió: > > FYI > > > > *From:* tig...@ec... [ > mailto:tig...@ec...<tig...@ec...>] > *On Behalf Of *Duncan Keysell (dkeysell) > *Sent:* Tuesday, July 03, 2012 7:04 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > > > Hi, > > > > This fix has now been pushed to the josif update site. > > > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > > > Thanks > > Duncan > > > > *From: *<Flauw>, Marc <Mar...@hp...> > *Reply-To: *Tigerstripe Developers <tig...@ec...> > *Date: *Friday, 29 June 2012 16:39 > *To: *Tigerstripe Developers <tig...@ec...> > *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF > > > > Duncan, > > > > Thanks for the investigation. > > If you fixed a bug, then please yes, push the fix to the josif update site. > > > > Best regards > > > > Marc > > > > *From:* tig...@ec... [ > mailto:tig...@ec...<tig...@ec...>] > *On Behalf Of *Duncan Keysell (dkeysell) > *Sent:* Friday, June 29, 2012 5:27 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > > > Hi Marc, > > > > It took me quite a bit of investigation but I don't think there is an > issue here: > > > > In order to get $all* collections of the TS Velocity context populated the > user needs to uncheck the "Run All Rules as Local" checkbox in the > Generation section of the Advanced tab of the tigerstripe.xml or the model > project. This is probably a new feature since you last updated (it was new > to me). > > > > Please can you give this a try? > > > > However, when I was looking at this I found it was not possible to add a > new Module Dependency to a Tigerstripe model project. This bug has now been > fixed. Do you want us to push another release to the JOSIF update site with > this fix? > > > > Thanks, > > Duncan > > > > *From: *<Flauw>, Marc <Mar...@hp...> > *Reply-To: *Tigerstripe Developers <tig...@ec...> > *Date: *Thursday, 28 June 2012 09:55 > *To: *Tigerstripe Developers <tig...@ec...> > *Subject: *[tigerstripe-dev] Critical bug for JOSIF > > > > Hi Tigerstripe team, > > > > In our current version of JOSIF, we are using an old version of > Tigerstripe from Feb 2011. > > > > We are testing the new Tigerstripe version you made for us, which > corresponds to I53 for integration in our new JOSIF version and we have > found a critical bug that xose has filled in bugzilla: *Bug 383728<https://bugs.eclipse.org/bugs/show_bug.cgi?id83728> > * > > > > We are using dependency modules systematically in our projects and the > behavior has changed from the version we use in the previous version of > JOSIF, > > > > When trying to get all the artifacts inside the project with the variable > $allPackages we got different responses in the two versions of Tigerstripe. > In the new version, only the model packages are shown. > > > > Is there now a different way of getting model and dependency packages all > together? > > > > This is a show-stopper for us. > > > > Thanks for your support, > > > > Best regards > > > > Marc > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > > _______________________________________________ > > Openoss-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openoss-devel > > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 <%2B%2034%20986%20410%20091> (ext) 206 | M/ +34 675 > 550 029 <%2B34%20675%20550%20029> > www.optaresolutions.com > > <mime-attachment.jpg> <http://optarecoolvendor.com> > > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 <%2B%2034%20986%20410%20091> (ext) 206 | M/ +34 675 > 550 029 <%2B34%20675%20550%20029> > www.optaresolutions.com > > <mime-attachment.jpg> <http://optarecoolvendor.com> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Openoss-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/openoss-devel > > > -- Antes de imprimir este mensaje, asegúrese de que es necesario. Proteger el medio ambiente está en nuestra mano Before printing this message, be sure it's needed. Protecting the enviroment is in our hands Este mensaje se dirige exclusivamente a su destinatario y puede contener información CONFIDENCIAL sometida a secreto profesional o cuya divulgación esté prohibida en virtud de la legislación vigente. Cualquier opinión en él contenida es exclusiva de su autor y no representa necesariamente la opinión de la empresa. Si ha recibido este mensaje por error, le rogamos nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message contains information that may be privileged or confidential and is the property of Optare Solutions. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-23 08:19:50
|
Hi Have you tried running tigerstripe on the dependencies project itself from the dashboard? The RAM Model project works OK but the dependencies project cannot be built on its own. Craig On 23/07/2012 02:01, Xose Ramón Sousa wrote: > Hi Craig thanks for the feedback. I have tested in the RAM project, > importing the dependencies project as a module and it worked. > > Please could you give me the details of how do you perform the test to > be sure that I can reporduce the error. > > Regards > > > 2012/7/21 Craig Gallen (opennms) <cg...@op... > <mailto:cg...@op...>> > > Hi, > > I tried out the soap generator in the sandbox. > I'm using the latest tiger-stripe josif release and the soap > generator in the sandbox at > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > On the RAM Dependencies project I get the following error when I > try to generate using the Soap Generator. > Unexpected error while merging 'templates/IteratorAnalyzer.vm' > template: Invocation of method 'collectBulkPotentialTypes' in > class > org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer > threw exception java.lang.NullPointerException @ > templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. > > Cheers > Craig > > > > > > On 12/07/2012 16:08, Flauw, Marc wrote: >> >> Hi Xose, >> >> Thanks, I will give a try to your SOAP generator in the sandbox. >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* Thursday, July 12, 2012 5:05 PM >> *To:* Flauw, Marc >> *Cc:* ope...@li... >> <mailto:ope...@li...> >> *Subject:* Re: Urgent questions on SOAP Generator >> >> Hi Marc at the moment I don't have full avialability but I am >> going to speed up the developments that you detail. >> >> I have developed a workaround to solve the issue around the >> allPackages context variable. The new version of Tigerstripe >> solves the problem of get the rigth package elements but using a >> Proxy implementation inside makes errors in some casts performed >> in the calculation of the closure. The workaround in my tests >> works with the three versions of Tigerstripe in the RAM and SPM >> projects but I cannot perform more tests. It will be interesting >> if someone could also test it. The workaround change a lot of >> clasess so I put the workaround in the sandbox to be tested prior >> to checkin in the trunk of Soap Generator. If the test are ok, >> then I will checkin to the Trunk >> >> This issue takes me a lot of time and now we follow with the URI >> support that expect to get as soon as possible, but these days I >> don't have availability because of my surgery. >> >> >> Regards >> >> El 11/07/2012 16:06, Flauw, Marc escribió: >> >> Hi Xose, >> >> There is no update following your last mail on this topic and >> the SOAP Generator trunk is not updated, so would it be >> possible from you or one of your backup to get a status on >> the test of this workaround. >> >> Also, the support of uri and url in the SOAP Generator is >> needed for JOSIF V1.1.2 and I haven’t seen any update on this. >> >> These 2 points would be critical for the release of JOSIF V1.1.2. >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez >> [mailto:xr...@op...] >> *Sent:* Wednesday, July 04, 2012 9:31 AM >> *To:* Flauw, Marc >> *Cc:* ope...@li... >> <mailto:ope...@li...> >> *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] Critical >> bug for JOSIF >> >> Thanks Marc I've uploaded a workaround in JOSIF development >> in URL >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator >> >> I will test the new version now. >> >> >> Regards >> >> El 04/07/2012 7:36, Flauw, Marc escribió: >> >> FYI >> >> *From:*tig...@ec... >> <mailto:tig...@ec...> >> [mailto:tig...@ec...] *On Behalf >> Of *Duncan Keysell (dkeysell) >> *Sent:* Tuesday, July 03, 2012 7:04 PM >> *To:* Tigerstripe developers list >> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >> >> Hi, >> >> This fix has now been pushed to the josif update site. >> >> http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ >> >> Thanks >> >> Duncan >> >> *From: *<Flauw>, Marc <Mar...@hp... >> <mailto:Mar...@hp...>> >> *Reply-To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Date: *Friday, 29 June 2012 16:39 >> *To: *Tigerstripe Developers <tig...@ec... >> <mailto:tig...@ec...>> >> *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF >> >> Duncan, >> >> Thanks for the investigation. >> >> If you fixed a bug, then please yes, push the fix to the >> josif update site. >> >> Best regards >> >> Marc >> >> *From:*tig...@ec... >> <mailto:tig...@ec...> >> [mailto:tig...@ec...] *On Behalf >> Of *Duncan Keysell (dkeysell) >> *Sent:* Friday, June 29, 2012 5:27 PM >> *To:* Tigerstripe developers list >> *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF >> >> Hi Marc, >> >> It took me quite a bit of investigation but I don't think >> there is an issue here: >> >> In order to get $all* collections of the TS Velocity >> context populated the user needs to uncheck the "Run All >> Rules as Local" checkbox in the Generation section of the >> Advanced tab of the tigerstripe.xml or the model project. >> This is probably a new feature since you last updated (it >> was new to me). >> >> Please can you give this a try? >> >> However, when I was looking at this I found it was not >> possible to add a new Module Dependency to a Tigerstripe >> model project. This bug has now been fixed. Do you want >> us to push another release to the JOSIF update site with >> this fix? >> >> Thanks, >> >> Duncan >> >> *From: *<Flauw>, Marc <Mar...@hp... >> <mailto:Mar...@hp...>> >> *Reply-To: *Tigerstripe Developers >> <tig...@ec... >> <mailto:tig...@ec...>> >> *Date: *Thursday, 28 June 2012 09:55 >> *To: *Tigerstripe Developers <tig...@ec... >> <mailto:tig...@ec...>> >> *Subject: *[tigerstripe-dev] Critical bug for JOSIF >> >> Hi Tigerstripe team, >> >> In our current version of JOSIF, we are using an old >> version of Tigerstripe from Feb 2011. >> >> We are testing the new Tigerstripe version you made for >> us, which corresponds to I53 for integration in our new >> JOSIF version and we have found a critical bug that xose >> has filled in bugzilla: *Bug 383728 >> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>* >> >> We are using dependency modules systematically in our >> projects and the behavior has changed from the version >> we use in the previous version of JOSIF, >> >> When trying to get all the artifacts inside the project >> with the variable $allPackages we got different responses >> in the two versions of Tigerstripe. In the new version, >> only the model packages are shown. >> >> Is there now a different way of getting model and >> dependency packages all together? >> >> This is a show-stopper for us. >> >> Thanks for your support, >> >> Best regards >> >> Marc >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> >> Exclusive live event will cover all the ways today's security and >> >> threat landscape has changed and how IT managers can respond. Discussions >> >> will include endpoint security, mobile security and the latest in malware >> >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> >> >> >> _______________________________________________ >> >> Openoss-devel mailing list >> >> Ope...@li... <mailto:Ope...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/openoss-devel >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >> Director I+D >> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) >> 206 | M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 <tel:%2B%2034%20986%20410%20091> (ext) 206 | >> M/ +34 675 550 029 <tel:%2B34%20675%20550%20029> >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> _______________________________________________ >> Openoss-devel mailing list >> Ope...@li... <mailto:Ope...@li...> >> https://lists.sourceforge.net/lists/listinfo/openoss-devel > > > > > -- > Antes de imprimir este mensaje, asegúrese de que es necesario. > Proteger el medio ambiente está en nuestra mano > > Before printing this message, be sure it's needed. Protecting the > enviroment is in our hands > > > > Este mensaje se dirige exclusivamente a su destinatario y puede > contener información CONFIDENCIAL sometida a secreto profesional o > cuya divulgación esté prohibida en virtud de la legislación vigente. > Cualquier opinión en él contenida es exclusiva de su autor y no > representa necesariamente la opinión de la empresa. Si ha recibido > este mensaje por error, le rogamos nos lo comunique inmediatamente por > esta misma vía y proceda a su destrucción. > > This message contains information that may be privileged or > confidential and is the property of Optare Solutions. It is intended > only for the person to whom it is addressed. If you are not the > intended recipient, you are not authorized to read, print, retain, > copy, disseminate, distribute, or use this message or any part > thereof. If you receive this message in error, please notify the > sender immediately and delete all copies of this message. > > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-21 12:05:07
|
Hi, The RAM RI uses the latest 1.1.2-SNAPSHOT models and artifacts and so while it worked a month or so ago, it no longer compiles correctly. The problem is that we aren't keeping all the generators in sync as we introduce new features. Hopefully we will have some feature stability over the next month in order to get the 1.1.2 out. Things have not worked properly since Marc has introduced new features into the common model and new profile features have been added (such as URI primitives which are not supported by the Soap generator) . Xose hasn't yet fixed the Soap generator problems and In particular the RAM Dependencies model throws an error with his sandbox soap generator. I need the soap generator problems to be resolved before I can get the RI working again. Then hopefully we can finish the 1.1.2 release. Cheers Craig On 15/07/2012 22:13, Pierre Gauthier wrote: > Hi Craig, > > Looks like I'm unable to compile clean the latest version of the RAM RI. > > Are you able ? > > Pierre > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-21 11:53:21
|
Hi, I tried out the soap generator in the sandbox. I'm using the latest tiger-stripe josif release and the soap generator in the sandbox at https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator On the RAM Dependencies project I get the following error when I try to generate using the Soap Generator. Unexpected error while merging 'templates/IteratorAnalyzer.vm' template: Invocation of method 'collectBulkPotentialTypes' in class org.eclipse.tigerstripe.generators.xml.filters.IteratorAnalyzer threw exception java.lang.NullPointerException @ templates/IteratorAnalyzer.vm[6,19]. Generation may be incomplete. Cheers Craig On 12/07/2012 16:08, Flauw, Marc wrote: > > Hi Xose, > > Thanks, I will give a try to your SOAP generator in the sandbox. > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] > *Sent:* Thursday, July 12, 2012 5:05 PM > *To:* Flauw, Marc > *Cc:* ope...@li... > *Subject:* Re: Urgent questions on SOAP Generator > > Hi Marc at the moment I don't have full avialability but I am going to > speed up the developments that you detail. > > I have developed a workaround to solve the issue around the > allPackages context variable. The new version of Tigerstripe solves > the problem of get the rigth package elements but using a Proxy > implementation inside makes errors in some casts performed in the > calculation of the closure. The workaround in my tests works with the > three versions of Tigerstripe in the RAM and SPM projects but I cannot > perform more tests. It will be interesting if someone could also test > it. The workaround change a lot of clasess so I put the workaround in > the sandbox to be tested prior to checkin in the trunk of Soap > Generator. If the test are ok, then I will checkin to the Trunk > > This issue takes me a lot of time and now we follow with the URI > support that expect to get as soon as possible, but these days I don't > have availability because of my surgery. > > > Regards > > El 11/07/2012 16:06, Flauw, Marc escribió: > > Hi Xose, > > There is no update following your last mail on this topic and the > SOAP Generator trunk is not updated, so would it be possible from > you or one of your backup to get a status on the test of this > workaround. > > Also, the support of uri and url in the SOAP Generator is needed > for JOSIF V1.1.2 and I haven't seen any update on this. > > These 2 points would be critical for the release of JOSIF V1.1.2. > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] > *Sent:* Wednesday, July 04, 2012 9:31 AM > *To:* Flauw, Marc > *Cc:* ope...@li... > <mailto:ope...@li...> > *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] Critical bug > for JOSIF > > Thanks Marc I've uploaded a workaround in JOSIF development in URL > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > I will test the new version now. > > > Regards > > El 04/07/2012 7:36, Flauw, Marc escribió: > > FYI > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] *On Behalf Of > *Duncan Keysell (dkeysell) > *Sent:* Tuesday, July 03, 2012 7:04 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi, > > This fix has now been pushed to the josif update site. > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > Thanks > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... > <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers > <tig...@ec... <mailto:tig...@ec...>> > *Date: *Friday, 29 June 2012 16:39 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF > > Duncan, > > Thanks for the investigation. > > If you fixed a bug, then please yes, push the fix to the josif > update site. > > Best regards > > Marc > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] *On Behalf Of > *Duncan Keysell (dkeysell) > *Sent:* Friday, June 29, 2012 5:27 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi Marc, > > It took me quite a bit of investigation but I don't think > there is an issue here: > > In order to get $all* collections of the TS Velocity context > populated the user needs to uncheck the "Run All Rules as > Local" checkbox in the Generation section of the Advanced tab > of the tigerstripe.xml or the model project. This is probably > a new feature since you last updated (it was new to me). > > Please can you give this a try? > > However, when I was looking at this I found it was not > possible to add a new Module Dependency to a Tigerstripe model > project. This bug has now been fixed. Do you want us to push > another release to the JOSIF update site with this fix? > > Thanks, > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... > <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers > <tig...@ec... <mailto:tig...@ec...>> > *Date: *Thursday, 28 June 2012 09:55 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *[tigerstripe-dev] Critical bug for JOSIF > > Hi Tigerstripe team, > > In our current version of JOSIF, we are using an old version > of Tigerstripe from Feb 2011. > > We are testing the new Tigerstripe version you made for us, > which corresponds to I53 for integration in our new JOSIF > version and we have found a critical bug that xose has filled > in bugzilla: *Bug 383728 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>* > > We are using dependency modules systematically in our projects > and the behavior has changed from the version we use in the > previous version of JOSIF, > > When trying to get all the artifacts inside the project with > the variable $allPackages we got different responses in the > two versions of Tigerstripe. In the new version, only the > model packages are shown. > > Is there now a different way of getting model and dependency > packages all together? > > This is a show-stopper for us. > > Thanks for your support, > > Best regards > > Marc > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > > _______________________________________________ > > Openoss-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/openoss-devel > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > Openoss-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-devel |
|
From: Flauw, M. <Mar...@hp...> - 2012-07-20 13:49:44
|
_______________________________________________ tigerstripe-dev mailing list tig...@ec... https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev |
|
From: Pierre G. <pga...@tm...> - 2012-07-16 03:12:51
|
Hi Craig, I can't compile clean the RI CTK for RAM. Always getting errors related to Iterator. Anything we need to do ? C:\ws-tsempty\TIP_RAM_SoapImplGenSrcPackage\target\generated-sources\src\main\java\org\openoss\tip\model\xml\org\tmforum\tip\org\tmforum\tip\resource\trouble\alarm\GetResourceAlarmsResponseXmlMapper.java:[173,71] cannot find symbol symbol : class ResourceAlarmResultWithIterator location: package org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm C:\ws-tsempty\TIP_RAM_SoapImplGenSrcPackage\target\generated-sources\src\main\java\org\openoss\tip\model\xml\org\tmforum\tip\org\tmforum\tip\resource\trouble\alarm\GetResourceAlarmsResponseXmlMapper.java:[174,107] cannot find symbol symbol : class ResourceAlarmResultWithIteratorImpl location: package org.openoss.tip.model.impl.org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm Pierre |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-12 15:06:25
|
Hi Marc at the moment I don't have full avialability but I am going to speed up the developments that you detail. I have developed a workaround to solve the issue around the allPackages context variable. The new version of Tigerstripe solves the problem of get the rigth package elements but using a Proxy implementation inside makes errors in some casts performed in the calculation of the closure. The workaround in my tests works with the three versions of Tigerstripe in the RAM and SPM projects but I cannot perform more tests. It will be interesting if someone could also test it. The workaround change a lot of clasess so I put the workaround in the sandbox to be tested prior to checkin in the trunk of Soap Generator. If the test are ok, then I will checkin to the Trunk This issue takes me a lot of time and now we follow with the URI support that expect to get as soon as possible, but these days I don't have availability because of my surgery. Regards El 11/07/2012 16:06, Flauw, Marc escribió: > > Hi Xose, > > There is no update following your last mail on this topic and the SOAP > Generator trunk is not updated, so would it be possible from you or > one of your backup to get a status on the test of this workaround. > > Also, the support of uri and url in the SOAP Generator is needed for > JOSIF V1.1.2 and I haven't seen any update on this. > > These 2 points would be critical for the release of JOSIF V1.1.2. > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] > *Sent:* Wednesday, July 04, 2012 9:31 AM > *To:* Flauw, Marc > *Cc:* ope...@li... > *Subject:* Re: [Openoss-devel] FW: [tigerstripe-dev] Critical bug for > JOSIF > > Thanks Marc I've uploaded a workaround in JOSIF development in URL > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator > > I will test the new version now. > > > Regards > > El 04/07/2012 7:36, Flauw, Marc escribió: > > FYI > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] *On Behalf Of *Duncan > Keysell (dkeysell) > *Sent:* Tuesday, July 03, 2012 7:04 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi, > > This fix has now been pushed to the josif update site. > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > Thanks > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Friday, 29 June 2012 16:39 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF > > Duncan, > > Thanks for the investigation. > > If you fixed a bug, then please yes, push the fix to the josif > update site. > > Best regards > > Marc > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] *On Behalf Of *Duncan > Keysell (dkeysell) > *Sent:* Friday, June 29, 2012 5:27 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi Marc, > > It took me quite a bit of investigation but I don't think there is > an issue here: > > In order to get $all* collections of the TS Velocity context > populated the user needs to uncheck the "Run All Rules as Local" > checkbox in the Generation section of the Advanced tab of the > tigerstripe.xml or the model project. This is probably a new > feature since you last updated (it was new to me). > > Please can you give this a try? > > However, when I was looking at this I found it was not possible to > add a new Module Dependency to a Tigerstripe model project. This > bug has now been fixed. Do you want us to push another release to > the JOSIF update site with this fix? > > Thanks, > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Thursday, 28 June 2012 09:55 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *[tigerstripe-dev] Critical bug for JOSIF > > Hi Tigerstripe team, > > In our current version of JOSIF, we are using an old version of > Tigerstripe from Feb 2011. > > We are testing the new Tigerstripe version you made for us, which > corresponds to I53 for integration in our new JOSIF version and we > have found a critical bug that xose has filled in bugzilla: *Bug > 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>* > > We are using dependency modules systematically in our projects and > the behavior has changed from the version we use in the previous > version of JOSIF, > > When trying to get all the artifacts inside the project with the > variable $allPackages we got different responses in the two > versions of Tigerstripe. In the new version, only the model > packages are shown. > > Is there now a different way of getting model and dependency > packages all together? > > This is a show-stopper for us. > > Thanks for your support, > > Best regards > > Marc > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > > _______________________________________________ > > Openoss-devel mailing list > > Ope...@li... <mailto:Ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/openoss-devel > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: KARTHIK K. <kan...@gm...> - 2012-07-10 03:53:53
|
Hi Craig, As per our previous discussion, we were able to access the JVT Objects, which we reflected and obtained the properties of the Alarm. One problem we noticed, is that AlarmType is always null. Checking the logs of CTK showed that jvtObject.toString() indicates that AlarmType is not Populated. But the logs of the Reference Implementation clearly shows that the AlarmType field in the Alarm being sent, has been populated. What may be the reason for this and how can we rectify it? With Regards K.KARTHIK 9677052524 On Mon, Jul 2, 2012 at 7:21 PM, Craig Gallen (opennms) <cg...@op...>wrote: > you can subscribe using your sourceforge account here > http://sourceforge.net/mail/?group_id=122678 > > Craig > > > On 30/06/2012 05:56, KARTHIK KANNAN wrote: > > Hi Craig, > > I am unable to send mails to openoss-devel group. > > Is there a way by which I can register to this group? > I took a look at the mailing list page and couldn't seem to find any to > link for registration. > > With Regards > > K.KARTHIK > 9677052524 > > > > On Fri, Jun 29, 2012 at 9:10 PM, Craig Gallen (opennms) < > cg...@op...> wrote: > >> Hi, >> >> Well done. for getting this far. Getting the project to compile is a very >> good first step. >> >> First, please send all development questions to the openoss-devel list so >> we have a public record. >> >> 1. Difference between TIP_RAM_CompatibilityTestKit and TIP_RAM_CTK >> The code in the TIP_RAM_CTK is the complete set of generated code with >> multiple stubs. This code is regenerated on each build. The >> TIP_RAM_CompatibilityTestKit is intended for developers to copy and extend >> the generated stubs in the TIP_RAM_CTK into a permanent context which will >> not be overwritten on each build. Ultimately the >> TIP_RAM_CompatibilityTestKit will contain a complete test kit with >> developer added tests etc. >> >> 2. Marshalling / Unmarshalling Soap - video explanations >> The marshalling is explained in the videos referenced from >> >> http://sourceforge.net/apps/mediawiki/openoss/index.php?title=Release_Plan_1.1.2#JOSIF_Developer_On-Ramp_Training_Schedule >> Have a look at Deep dive - XML Marshalling Design patterns and generated >> RI and CTK code >> >> http://sourceforge.net/projects/openoss/files/JOSIF/DeveloperOnRamp/JOSIF-developer_On_Ramp_JVT_EJB_design2012-02-09.wmv/download >> >> 3. How the conversion works >> You are right in observing that there are two sets of objects in the >> system. The JVT (Java Value Type) objects follow a TM Forum OSS/J-like >> design pattern and are generated directly from the model. Both a JVT >> interface and implementation classes are generated along with a factory. >> Stub operation tests for the CTK are also generated from the model. This >> shows a forwards direction for OSS/J users. The tests are written using >> these objects so that they are generic and could run against any interface >> profile (SOAP, Rest etc). You should not work directly with the JAXB >> objects but use the JVT objects and translate. If there are bug in the >> translation, we can fix them. >> >> The second set of objects in the system are generated using Apache CXF >> wsdl2java. A visitor design pattern is used to map these JAXB objects to >> the JVT objects (http://en.wikipedia.org/wiki/Visitor_pattern). This is >> equivalent to the pattern in OSS/J of offering a base EJB interface which >> was translated to SOAP/XML for the XVT (XML Value Type) design profile. >> >> The conversion and subsequent marshalling and unmarshalling is initiated >> by >> org.openoss.xml.JvtJaxbTranslator(). >> This identifies the type of the class to be translated to and from SOAP >> and finds an initial instance of the JVT and corresponding JAXB request and >> response objects. It then recursively traverses the tree of objects to >> translate between types. To understand the object conversion to/from SOAP >> have a look at ResourceAlarmRetrievalServiceXmlMapper.java in >> TIP_RAM_SoapImplGenSrcPackage. This is the generated entry point >> implementation code for the soap call to ResourceAlarmRetrievalService. It >> is mapped into Apache CXF's JAX-WS implementation through the generated the >> spring application context; Model_WSAppContext.xml >> >> look at the getResourceAlarms method at line 437 of >> ResourceAlarmRetrievalServiceXmlMapper.java; >> >> @javax.jws.WebService(endpointInterface = >> "org.tmforum.xml.tip.resource.trouble.alarm.ResourceAlarmRetrievalService") >> public >> org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsResponse >> getResourceAlarms( >> org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsRequest >> xmlRequest) { >> ... >> org.openoss.xml.JvtJaxbTranslator jvtJaxbTranslator= >> new org.openoss.xml.JvtJaxbTranslator(); >> jvtJaxbTranslator.setLog(getLog()); >> >> >> org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsRequest >> getResourceAlarmsRequest = >> >> (org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsRequest) >> jvtJaxbTranslator.toJvtObject(xmlRequest); >> >> >> org.tmforum.tip.org.tmforum.tip.resource.trouble.alarm.GetResourceAlarmsResponse >> getResourceAlarmsResponse = >> >> jvtInterface.getResourceAlarms(getResourceAlarmsRequest); >> >> return >> (org.tmforum.xml.tip.resource.trouble.alarm.GetResourceAlarmsResponse)jvtJaxbTranslator.toJaxbObject(getResourceAlarmsResponse); >> ... >> } >> >> Hope this helps >> >> Craig >> >> >> On 29/06/2012 12:48, Flauw, Marc wrote: >> >> Kannan, >> >> >> >> I don’t know. Craig should be able to answer you on these points. >> >> >> >> Best regards >> >> >> >> Marc >> >> >> >> *From:* KARTHIK KANNAN [mailto:kan...@gm...<kan...@gm...>] >> >> *Sent:* Friday, June 29, 2012 1:33 PM >> *To:* Flauw, Marc >> *Cc:* sitaraman >> *Subject:* Re: Missing TIP_RAM_DocSpecPackage-1.0.2.jar (latest) >> >> >> >> Thanks for replying. >> >> We have managed to get the RI and CTK working and we are able to make the >> CTK on one machine to communicate with RI on another machine. >> >> Note : We are using TIP_RAM_CTK and not TIP_RAM_CompatibilityTestKit. >> >> From our understanding, the RI sends the RAM objects to CTK in SOAP >> format. Once, the CTK receives the SOAP object, does it convert it into a >> RAM object? >> >> If so, can you point to the part of the code where this conversion take >> place. >> >> If not, please point to the part where the SOAP message is received, so >> that we can parse it and build the RAM object. >> >> Thanks again, for all your help. >> >> With Regards >> >> >> K.KARTHIK >> 9677052524 >> >> >> >> On Wed, Jun 27, 2012 at 2:31 PM, Flauw, Marc <Mar...@hp...> wrote: >> >> Kannan, >> >> >> >> This is not downloaded but built by the build process. Check the >> Tigerstripe.xml of your model project and go to the generator settings and >> check that it is correctly configured with 1.0.2 >> >> >> >> If this error occurs during the eclipse:eclipse built, then try doing the >> clean install and it has good chances of going away. >> >> >> >> Best regards >> >> >> >> Marc >> >> >> >> *From:* KARTHIK KANNAN [mailto:kan...@gm...] >> *Sent:* Wednesday, June 27, 2012 10:56 AM >> *To:* Flauw, Marc >> *Cc:* sitaraman >> *Subject:* Missing TIP_RAM_DocSpecPackage-1.0.2.jar (latest) >> >> >> >> Hi Marc, >> >> This is Karthik here. I am working with Dr.Sitaraman and we have >> communicated before regarding TIP RAM project. >> >> While we were trying to build the code, Maven tried to download >> TIP_RAM_DocSpecPackage-1.0.2.jar but failed. Can you point to us to the >> site, from where we can download this. >> >> We have TIP_RAM_DocSpecPackage-1.0.1.jar with us. Can we use this as a >> replacement for TIP_RAM_DocSpecPackage-1.0.2.jar >> >> With Regards >> >> >> K.KARTHIK >> 9677052524 >> >> >> >> >> >> >> >> > > > |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-04 07:31:56
|
Thanks Marc I've uploaded a workaround in JOSIF development in URL https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator I will test the new version now. Regards El 04/07/2012 7:36, Flauw, Marc escribió: > > FYI > > *From:*tig...@ec... > [mailto:tig...@ec...] *On Behalf Of *Duncan > Keysell (dkeysell) > *Sent:* Tuesday, July 03, 2012 7:04 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi, > > This fix has now been pushed to the josif update site. > > http://download.eclipse.org/technology/tigerstripe/updates/3.6/josif/ > > Thanks > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Friday, 29 June 2012 16:39 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *Re: [tigerstripe-dev] Critical bug for JOSIF > > Duncan, > > Thanks for the investigation. > > If you fixed a bug, then please yes, push the fix to the josif update > site. > > Best regards > > Marc > > *From:*tig...@ec... > <mailto:tig...@ec...> > [mailto:tig...@ec...] *On Behalf Of *Duncan > Keysell (dkeysell) > *Sent:* Friday, June 29, 2012 5:27 PM > *To:* Tigerstripe developers list > *Subject:* Re: [tigerstripe-dev] Critical bug for JOSIF > > Hi Marc, > > It took me quite a bit of investigation but I don't think there is an > issue here: > > In order to get $all* collections of the TS Velocity context populated > the user needs to uncheck the "Run All Rules as Local" checkbox in the > Generation section of the Advanced tab of the tigerstripe.xml or the > model project. This is probably a new feature since you last updated > (it was new to me). > > Please can you give this a try? > > However, when I was looking at this I found it was not possible to add > a new Module Dependency to a Tigerstripe model project. This bug has > now been fixed. Do you want us to push another release to the JOSIF > update site with this fix? > > Thanks, > > Duncan > > *From: *<Flauw>, Marc <Mar...@hp... <mailto:Mar...@hp...>> > *Reply-To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Date: *Thursday, 28 June 2012 09:55 > *To: *Tigerstripe Developers <tig...@ec... > <mailto:tig...@ec...>> > *Subject: *[tigerstripe-dev] Critical bug for JOSIF > > Hi Tigerstripe team, > > In our current version of JOSIF, we are using an old version of > Tigerstripe from Feb 2011. > > We are testing the new Tigerstripe version you made for us, which > corresponds to I53 for integration in our new JOSIF version and we > have found a critical bug that xose has filled in bugzilla: *Bug > 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>* > > We are using dependency modules systematically in our projects and > the behavior has changed from the version we use in the previous > version of JOSIF, > > When trying to get all the artifacts inside the project with the > variable $allPackages we got different responses in the two versions > of Tigerstripe. In the new version, only the model packages are shown. > > Is there now a different way of getting model and dependency packages > all together? > > This is a show-stopper for us. > > Thanks for your support, > > Best regards > > Marc > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > Openoss-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-devel -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-04 07:30:22
|
I have developed a workaround for solve the bug in tigerstripe, you can download from: https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator Please send me feedback about that Regards El 03/07/2012 21:07, Craig Gallen (opennms) escribió: > Xose, > are you also doing the primitive.uri / primitive.url changes to > support the new profile? > Craig > > > On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: >> Hi all. I am developing a module that get the packages to perform >> the funcionallity desired, but in the models there are changes in the >> way they are instantied so a deeper revision is needed. >> I have got the code to obtain the packages and now we are changing >> the models, but has a lot of dependences in building the closure. I >> am trying to finish it and the publish on the sandbox area better to >> perform tests and avoid regression problems. >> >> >> Regards >> El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >>> Hi Xose, >>> >>> Duncan from Tigerstripe has replied on bugzilla that we need to >>> uncheck the "Run All Rules as Local" >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run >>> the MPAC model with "Run All Rules as Local" checked and then as >>> unchecked to ensure that the property is correctly set in >>> tigerstripe.xml. However this does not appear to fix the problem. >>> Dependencies are not being generated by the soap plugin. Could you >>> run the test in your model and get back to Duncan if it is still the >>> issue. >>> >>> Thanks >>> >>> Craig >>> >>> >>> >>> >>> >>> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>>> I have created the bug >>>> Bug 383728 >>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has been >>>> added to the database >>>> >>>> Email sent to: >>>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>>> Excluding: >>>> |xr...@op...| >>>> >>>> >>>> >>>> Regards >>>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>>> >>>>> Xose, >>>>> >>>>> Send us the bug pointer and I will escalate it . >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>>> *To:* Craig Gallen (opennms) >>>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>>> >>>>> Hi all. >>>>> I have post the problem in the user list as the bug creation >>>>> recommends. Nobody answer that so I am going to create the bug. I >>>>> have a first version of the workaround but aome problems are >>>>> derived in the cast operations in the src_shared classes, so I >>>>> must investigate deeper. If this issue is solved I can send you >>>>> Craig a preeliminary patch and then check the behaivour of the >>>>> other $allxxxx context elements. >>>>> >>>>> >>>>> Regards >>>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>>> >>>>> Xose & Marc, >>>>> >>>>> Is there a plan to complete primitive.url / primitive.uri in >>>>> the soap generator. I have support for it in the Java >>>>> generators but need the Soap generator working with this >>>>> stereotype to test this code. >>>>> >>>>> Also has a bug been raised against Tigerstripe for the >>>>> $allPackage issue ? I'd prefer to fix the problem in >>>>> tigerstripe rather than have Xose get a work around because >>>>> if this isnt working, its possible other 'get all collections' >>>>> of artificates are not working. So this could be a general >>>>> problem for the other generators including Cisco's own. >>>>> >>>>> Xose, have you raised a bug report and if so what is the bug >>>>> number? >>>>> >>>>> Marc, when we have a bug report, can we escalate this directly >>>>> to the tigerstripe team because it is a show stopper for us. >>>>> >>>>> I'm afraid I cannot do any more development until this is fixed. >>>>> >>>>> Thanks for your help >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> I am going to test a workaround to see if this could be >>>>> supported without change the tigerstripe core. >>>>> >>>>> Regards >>>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>>> >>>>> Hi, >>>>> >>>>> So is there a work around or do we have to wait for >>>>> Tigerstripe to sort this out. >>>>> The old version of tigerstripe (6.9.xxx) is no longer >>>>> available to download. >>>>> >>>>> Craig >>>>> >>>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error >>>>> in the Default Velocity context contents. When the >>>>> $allPackage variable is used in the >>>>> dependencyAnalyzer.vm template, it is expected >>>>> that all artifacts, including the dependences, are >>>>> included in that collection. In my tests I've got >>>>> this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.6.935.201102010903 >>>>> org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), >>>>> org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>>> [2012-06-26 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.7.0.201206181258 >>>>> org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>>> 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed >>>>> files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi >>>>> From eclipse, Soap generator subversion; >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> Revision 3453 >>>>> (last change revision 3444 last commit author xrsousa) >>>>> >>>>> Craig >>>>> >>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi Craig, when you talk about the updated Soap >>>>> Plugin, which version (in svn url) are using?, >>>>> because the two first issues seems to be solved in >>>>> the trunk with the other Tigerstripe version. >>>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest >>>>> release 0.7.0.20120618258 but Ialso updated the >>>>> Soap plug-in and have found multiple problems but >>>>> I am not sure if they are all related to the >>>>> tigerstripe upgrade or to the current state of the >>>>> soap plugin. Could you build the RAM project and >>>>> check the generated XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a >>>>> problem with model closure. None of the >>>>> Dependency XSD's get generated in the RAM_Model >>>>> project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as >>>>> 'problem:TrackingRecordResultWithIterator' in >>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>> is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>>> primitive.string differently and generates type >>>>> 'String' instead of 'java.lang.String' this >>>>> results in type :String instead of xsd:string. I >>>>> did a quick fix given in the following patch adding >>>>> || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe >>>>> will work >>>>> >>>>> There is a patch below but havent checked this in >>>>> because I was not sure that else you were doing to >>>>> the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> type = >>>>> mapPrimitivesToXsdType(refType.getName(), >>>>> isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || >>>>> refType.isEnum() >>>>> else if (isDatatype(refType) || >>>>> isEnumeration(refType)) { >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { >>>>> + || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> //will map objectName to >>>>> EntityIdentifier or ArrayOfEntityIdentifier >>>>> if >>>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi all. I think that I have found the error and I >>>>> will try to fix it as soon as possible. There are >>>>> some related issues, one error in the codification >>>>> of a method and a forgetted evaluation of >>>>> filtering in the velocity template and also a case >>>>> related with primitive type filter not supported >>>>> in the build of the closure outside the interfaces. >>>>> >>>>> In the interfaces build the search is performed as >>>>> follows(this works fine as reported Marc): >>>>> >>>>> if >>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'objectName' defines the protocol >>>>> * neutral unique name of >>>>> an object. This data type will >>>>> * be replaced by the >>>>> generators by an EntityIdentifier >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'filter'. This data type will >>>>> * be replaced by the >>>>> generator to >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else { >>>>> // XSD default namespace >>>>> is enough >>>>> } >>>>> >>>>> and in the build of the closure we have got (this >>>>> fails as reported Craig): >>>>> >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> + "\' is an array of primitive."); >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>> }else if >>>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>>> //will map to array of primitive >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>> } else { >>>>> //normal primtive like xsd:int >>>>> } >>>>> >>>>> so the filtering never is considered. >>>>> >>>>> I will perform clean tests because was very >>>>> difficult to find the real cause of the problem, >>>>> the log file is not very clear in debug scenarios >>>>> ( a lot of similar log text, no log from the >>>>> templates and also cannot put the line number in >>>>> the log file (tigerstripe issue)) and these >>>>> problems have delayed my response. >>>>> If the test go ok I will check out the changes to >>>>> the trunk >>>>> >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> >>>>> Best regards >>>>> >>>>> >>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>> >>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>> >>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>> >>>>> shows an error. >>>>> >>>>> >>>>> >>>>> I think Xose is looking into it >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>> >>>>> Sent: 01 June 2012 10:25 >>>>> >>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>> >>>>> gauthier >>>>> >>>>> Subject: RE: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Craig, >>>>> >>>>> >>>>> >>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>> >>>>> argument. >>>>> >>>>> The XPathFilter is defined in the internal_filter.xsd >>>>> >>>>> >>>>> >>>>> Best regards >>>>> >>>>> >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>> >>>>> Gallen (opennms) >>>>> >>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>> >>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>> >>>>> Subject: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>> >>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>> >>>>> >>>>> >>>>> in line 62 we have >>>>> >>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>> >>>>> minOccurs="0" maxOccurs="1"> >>>>> >>>>> >>>>> >>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>> >>>>> it reports this error as: >>>>> >>>>> >>>>> >>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>> >>>>> 'element'. Recorded reason: >>>>> >>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>> >>>>> the prefix 'filter' is not >>>>> >>>>> declared'. >>>>> >>>>> >>>>> >>>>> Is this a known problem or a new bug? >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >>> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Flauw, M. <Mar...@hp...> - 2012-07-04 05:38:34
|
_______________________________________________ tigerstripe-dev mailing list tig...@ec... https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-03 22:52:56
|
No, because it seems that the allPackages was a blocking issue. I am finishing the tests and after that I can follow with that. Regards El 03/07/2012 21:07, Craig Gallen (opennms) escribió: > Xose, > are you also doing the primitive.uri / primitive.url changes to > support the new profile? > Craig > > > On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: >> Hi all. I am developing a module that get the packages to perform >> the funcionallity desired, but in the models there are changes in the >> way they are instantied so a deeper revision is needed. >> I have got the code to obtain the packages and now we are changing >> the models, but has a lot of dependences in building the closure. I >> am trying to finish it and the publish on the sandbox area better to >> perform tests and avoid regression problems. >> >> >> Regards >> El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >>> Hi Xose, >>> >>> Duncan from Tigerstripe has replied on bugzilla that we need to >>> uncheck the "Run All Rules as Local" >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run >>> the MPAC model with "Run All Rules as Local" checked and then as >>> unchecked to ensure that the property is correctly set in >>> tigerstripe.xml. However this does not appear to fix the problem. >>> Dependencies are not being generated by the soap plugin. Could you >>> run the test in your model and get back to Duncan if it is still the >>> issue. >>> >>> Thanks >>> >>> Craig >>> >>> >>> >>> >>> >>> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>>> I have created the bug >>>> Bug 383728 >>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has been >>>> added to the database >>>> >>>> Email sent to: >>>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>>> Excluding: >>>> |xr...@op...| >>>> >>>> >>>> >>>> Regards >>>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>>> >>>>> Xose, >>>>> >>>>> Send us the bug pointer and I will escalate it . >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>>> *To:* Craig Gallen (opennms) >>>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>>> >>>>> Hi all. >>>>> I have post the problem in the user list as the bug creation >>>>> recommends. Nobody answer that so I am going to create the bug. I >>>>> have a first version of the workaround but aome problems are >>>>> derived in the cast operations in the src_shared classes, so I >>>>> must investigate deeper. If this issue is solved I can send you >>>>> Craig a preeliminary patch and then check the behaivour of the >>>>> other $allxxxx context elements. >>>>> >>>>> >>>>> Regards >>>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>>> >>>>> Xose & Marc, >>>>> >>>>> Is there a plan to complete primitive.url / primitive.uri in >>>>> the soap generator. I have support for it in the Java >>>>> generators but need the Soap generator working with this >>>>> stereotype to test this code. >>>>> >>>>> Also has a bug been raised against Tigerstripe for the >>>>> $allPackage issue ? I'd prefer to fix the problem in >>>>> tigerstripe rather than have Xose get a work around because >>>>> if this isnt working, its possible other 'get all collections' >>>>> of artificates are not working. So this could be a general >>>>> problem for the other generators including Cisco's own. >>>>> >>>>> Xose, have you raised a bug report and if so what is the bug >>>>> number? >>>>> >>>>> Marc, when we have a bug report, can we escalate this directly >>>>> to the tigerstripe team because it is a show stopper for us. >>>>> >>>>> I'm afraid I cannot do any more development until this is fixed. >>>>> >>>>> Thanks for your help >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> I am going to test a workaround to see if this could be >>>>> supported without change the tigerstripe core. >>>>> >>>>> Regards >>>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>>> >>>>> Hi, >>>>> >>>>> So is there a work around or do we have to wait for >>>>> Tigerstripe to sort this out. >>>>> The old version of tigerstripe (6.9.xxx) is no longer >>>>> available to download. >>>>> >>>>> Craig >>>>> >>>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error >>>>> in the Default Velocity context contents. When the >>>>> $allPackage variable is used in the >>>>> dependencyAnalyzer.vm template, it is expected >>>>> that all artifacts, including the dependences, are >>>>> included in that collection. In my tests I've got >>>>> this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.6.935.201102010903 >>>>> org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), >>>>> org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>>> [2012-06-26 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.7.0.201206181258 >>>>> org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>>> 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed >>>>> files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi >>>>> From eclipse, Soap generator subversion; >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> Revision 3453 >>>>> (last change revision 3444 last commit author xrsousa) >>>>> >>>>> Craig >>>>> >>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi Craig, when you talk about the updated Soap >>>>> Plugin, which version (in svn url) are using?, >>>>> because the two first issues seems to be solved in >>>>> the trunk with the other Tigerstripe version. >>>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest >>>>> release 0.7.0.20120618258 but Ialso updated the >>>>> Soap plug-in and have found multiple problems but >>>>> I am not sure if they are all related to the >>>>> tigerstripe upgrade or to the current state of the >>>>> soap plugin. Could you build the RAM project and >>>>> check the generated XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a >>>>> problem with model closure. None of the >>>>> Dependency XSD's get generated in the RAM_Model >>>>> project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as >>>>> 'problem:TrackingRecordResultWithIterator' in >>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>> is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>>> primitive.string differently and generates type >>>>> 'String' instead of 'java.lang.String' this >>>>> results in type :String instead of xsd:string. I >>>>> did a quick fix given in the following patch adding >>>>> || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe >>>>> will work >>>>> >>>>> There is a patch below but havent checked this in >>>>> because I was not sure that else you were doing to >>>>> the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> type = >>>>> mapPrimitivesToXsdType(refType.getName(), >>>>> isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || >>>>> refType.isEnum() >>>>> else if (isDatatype(refType) || >>>>> isEnumeration(refType)) { >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { >>>>> + || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> //will map objectName to >>>>> EntityIdentifier or ArrayOfEntityIdentifier >>>>> if >>>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi all. I think that I have found the error and I >>>>> will try to fix it as soon as possible. There are >>>>> some related issues, one error in the codification >>>>> of a method and a forgetted evaluation of >>>>> filtering in the velocity template and also a case >>>>> related with primitive type filter not supported >>>>> in the build of the closure outside the interfaces. >>>>> >>>>> In the interfaces build the search is performed as >>>>> follows(this works fine as reported Marc): >>>>> >>>>> if >>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'objectName' defines the protocol >>>>> * neutral unique name of >>>>> an object. This data type will >>>>> * be replaced by the >>>>> generators by an EntityIdentifier >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'filter'. This data type will >>>>> * be replaced by the >>>>> generator to >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else { >>>>> // XSD default namespace >>>>> is enough >>>>> } >>>>> >>>>> and in the build of the closure we have got (this >>>>> fails as reported Craig): >>>>> >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> + "\' is an array of primitive."); >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>> }else if >>>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>>> //will map to array of primitive >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>> } else { >>>>> //normal primtive like xsd:int >>>>> } >>>>> >>>>> so the filtering never is considered. >>>>> >>>>> I will perform clean tests because was very >>>>> difficult to find the real cause of the problem, >>>>> the log file is not very clear in debug scenarios >>>>> ( a lot of similar log text, no log from the >>>>> templates and also cannot put the line number in >>>>> the log file (tigerstripe issue)) and these >>>>> problems have delayed my response. >>>>> If the test go ok I will check out the changes to >>>>> the trunk >>>>> >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> >>>>> Best regards >>>>> >>>>> >>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>> >>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>> >>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>> >>>>> shows an error. >>>>> >>>>> >>>>> >>>>> I think Xose is looking into it >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>> >>>>> Sent: 01 June 2012 10:25 >>>>> >>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>> >>>>> gauthier >>>>> >>>>> Subject: RE: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Craig, >>>>> >>>>> >>>>> >>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>> >>>>> argument. >>>>> >>>>> The XPathFilter is defined in the internal_filter.xsd >>>>> >>>>> >>>>> >>>>> Best regards >>>>> >>>>> >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>> >>>>> Gallen (opennms) >>>>> >>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>> >>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>> >>>>> Subject: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>> >>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>> >>>>> >>>>> >>>>> in line 62 we have >>>>> >>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>> >>>>> minOccurs="0" maxOccurs="1"> >>>>> >>>>> >>>>> >>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>> >>>>> it reports this error as: >>>>> >>>>> >>>>> >>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>> >>>>> 'element'. Recorded reason: >>>>> >>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>> >>>>> the prefix 'filter' is not >>>>> >>>>> declared'. >>>>> >>>>> >>>>> >>>>> Is this a known problem or a new bug? >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >>> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-03 19:07:30
|
Xose, are you also doing the primitive.uri / primitive.url changes to support the new profile? Craig On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: > Hi all. I am developing a module that get the packages to perform the > funcionallity desired, but in the models there are changes in the way > they are instantied so a deeper revision is needed. > I have got the code to obtain the packages and now we are changing the > models, but has a lot of dependences in building the closure. I am > trying to finish it and the publish on the sandbox area better to > perform tests and avoid regression problems. > > > Regards > El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >> Hi Xose, >> >> Duncan from Tigerstripe has replied on bugzilla that we need to >> uncheck the "Run All Rules as Local" >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the >> MPAC model with "Run All Rules as Local" checked and then as >> unchecked to ensure that the property is correctly set in >> tigerstripe.xml. However this does not appear to fix the problem. >> Dependencies are not being generated by the soap plugin. Could you >> run the test in your model and get back to Duncan if it is still the >> issue. >> >> Thanks >> >> Craig >> >> >> >> >> >> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>> I have created the bug >>> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >>> been added to the database >>> >>> Email sent to: >>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>> Excluding: >>> |xr...@op...| >>> >>> >>> >>> Regards >>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>> >>>> Xose, >>>> >>>> Send us the bug pointer and I will escalate it . >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>> *To:* Craig Gallen (opennms) >>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>> >>>> Hi all. >>>> I have post the problem in the user list as the bug creation >>>> recommends. Nobody answer that so I am going to create the bug. I >>>> have a first version of the workaround but aome problems are >>>> derived in the cast operations in the src_shared classes, so I must >>>> investigate deeper. If this issue is solved I can send you Craig a >>>> preeliminary patch and then check the behaivour of the other >>>> $allxxxx context elements. >>>> >>>> >>>> Regards >>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>> >>>> Xose & Marc, >>>> >>>> Is there a plan to complete primitive.url / primitive.uri in >>>> the soap generator. I have support for it in the Java >>>> generators but need the Soap generator working with this >>>> stereotype to test this code. >>>> >>>> Also has a bug been raised against Tigerstripe for the >>>> $allPackage issue ? I'd prefer to fix the problem in >>>> tigerstripe rather than have Xose get a work around because >>>> if this isnt working, its possible other 'get all collections' >>>> of artificates are not working. So this could be a general >>>> problem for the other generators including Cisco's own. >>>> >>>> Xose, have you raised a bug report and if so what is the bug >>>> number? >>>> >>>> Marc, when we have a bug report, can we escalate this directly >>>> to the tigerstripe team because it is a show stopper for us. >>>> >>>> I'm afraid I cannot do any more development until this is fixed. >>>> >>>> Thanks for your help >>>> >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>> >>>> I am going to test a workaround to see if this could be >>>> supported without change the tigerstripe core. >>>> >>>> Regards >>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>> >>>> Hi, >>>> >>>> So is there a work around or do we have to wait for >>>> Tigerstripe to sort this out. >>>> The old version of tigerstripe (6.9.xxx) is no longer >>>> available to download. >>>> >>>> Craig >>>> >>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Thanks Craig. >>>> I have performed some test and I can see an error >>>> in the Default Velocity context contents. When the >>>> $allPackage variable is used in the >>>> dependencyAnalyzer.vm template, it is expected that >>>> all artifacts, including the dependences, are >>>> included in that collection. In my tests I've got >>>> this behaivour: >>>> >>>> Old version of tigerstripe( Tigerstripe Core >>>> (Incubation) 0.6.935.201102010903 >>>> org.eclipse.tigerstripe.base.feature.group) >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633), >>>> org.tmforum.tip.cbe.perf(1039318676), >>>> org.tmforum.tip.common.notifications(23492680), >>>> org.tmforum.tip.resource.res(1133197283), >>>> org.tmforum.tip.cbe.root(1039387789), >>>> org.tmforum.tip(-660924437), >>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>> org.tmforum(1644248382), org(110308), >>>> org.tmforum.tip.common(442435918), >>>> org.tmforum.tip.cbe.party(-2140978021), >>>> org.tmforum.tip.cbe.problem(292836116), >>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>> org.tmforum.tip.internal.filter(-1708340282), >>>> org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), >>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>> org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), >>>> org.tmforum.tip.cbe.party.role(1514413545), >>>> org.tmforum.tip.internal.entity(-1732123599), >>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>> org.tmforum.tip.internal.exceptions(-367434926), >>>> org.tmforum.tip.cbe(1681757027), >>>> org.tmforum.tip.internal.iterator(866200892), >>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>> [2012-06-26 10:21:29.996+0200] >>>> >>>> New version og tigerstripe( Tigerstripe Core >>>> (Incubation) 0.7.0.201206181258 >>>> org.eclipse.tigerstripe.base.feature.group): >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>> 10:28:54.989+0200] >>>> >>>> So it seems that this is root cause for the missed >>>> files. >>>> I will create a bug in Tigerstripe. >>>> >>>> Regards >>>> >>>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>>> >>>> Hi >>>> From eclipse, Soap generator subversion; >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>> Revision 3453 >>>> (last change revision 3444 last commit author xrsousa) >>>> >>>> Craig >>>> >>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Hi Craig, when you talk about the updated Soap >>>> Plugin, which version (in svn url) are using?, >>>> because the two first issues seems to be solved in >>>> the trunk with the other Tigerstripe version. >>>> >>>> >>>> >>>> >>>> Regards >>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>> >>>> Hi Xose, >>>> >>>> I just updated my tigerstripe to the latest release >>>> 0.7.0.20120618258 but Ialso updated the Soap >>>> plug-in and have found multiple problems but I am >>>> not sure if they are all related to the tigerstripe >>>> upgrade or to the current state of the soap plugin. >>>> Could you build the RAM project and check the >>>> generated XSD's to see the problem. >>>> >>>> 1. when you build the RAM project there is a >>>> problem with model closure. None of the Dependency >>>> XSD's get generated in the RAM_Model project >>>> >>>> 2. TrackingRecordResultWithIterator referenced as >>>> 'problem:TrackingRecordResultWithIterator' in >>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>> is never generated. >>>> >>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>> primitive.string differently and generates type >>>> 'String' instead of 'java.lang.String' this results >>>> in type :String instead of xsd:string. I did a >>>> quick fix given in the following patch adding >>>> || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> >>>> to >>>> || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> this means that old and new versions of tigerstipe >>>> will work >>>> >>>> There is a patch below but havent checked this in >>>> because I was not sure that else you were doing to >>>> the Soap plugin >>>> >>>> Craig >>>> >>>> >>>> >>>> ### Eclipse Workspace Patch 1.0 >>>> #P TIP_Soap_Generator >>>> Index: >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> =================================================================== >>>> --- >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> (revision 3453) >>>> +++ >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> (working copy) >>>> @@ -510,8 +510,8 @@ >>>> */ >>>> if (refType.isPrimitive() >>>> || >>>> refType.getPackage().equalsIgnoreCase("primitive") >>>> - || >>>> "java.lang.String".equalsIgnoreCase(refType >>>> - .getFullyQualifiedName())) { >>>> + || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> PluginLog.logDebug("\'" + refTypeFullName >>>> + "\' is a primitive type in >>>> current TIP profile."); >>>> type = >>>> mapPrimitivesToXsdType(refType.getName(), >>>> isArray(refType), >>>> @@ -519,7 +519,7 @@ >>>> } >>>> >>>> /** >>>> - * Map datatyeps and enumerations >>>> + * Map datatypes and enumerations >>>> */ >>>> // if (refType.isDatatype() || >>>> refType.isEnum() >>>> else if (isDatatype(refType) || >>>> isEnumeration(refType)) { >>>> Index: >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> =================================================================== >>>> --- >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> (revision 3453) >>>> +++ >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> (working copy) >>>> @@ -170,8 +170,9 @@ >>>> private void addReferencedPackage(IType type) { >>>> >>>> if (type.isPrimitive() >>>> - || >>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>> - >>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>> { >>>> + || >>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>> + || >>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> //will map objectName to >>>> EntityIdentifier or ArrayOfEntityIdentifier >>>> if >>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>> PluginLog.logDebug("type \'" + type >>>> @@ -378,8 +379,8 @@ >>>> */ >>>> if (refType.isPrimitive() >>>> || >>>> refType.getPackage().equalsIgnoreCase("primitive") >>>> - || >>>> "java.lang.String".equalsIgnoreCase(refType >>>> - .getFullyQualifiedName())) { >>>> + || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> PluginLog.logDebug("\'" + typeName >>>> + "\' is a primitive type in >>>> current TIP profile."); >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Hi all. I think that I have found the error and I >>>> will try to fix it as soon as possible. There are >>>> some related issues, one error in the codification >>>> of a method and a forgetted evaluation of filtering >>>> in the velocity template and also a case related >>>> with primitive type filter not supported in the >>>> build of the closure outside the interfaces. >>>> >>>> In the interfaces build the search is performed as >>>> follows(this works fine as reported Marc): >>>> >>>> if >>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type >>>> 'objectName' defines the protocol >>>> * neutral unique name of >>>> an object. This data type will >>>> * be replaced by the >>>> generators by an EntityIdentifier >>>> */ >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type 'filter'. >>>> This data type will >>>> * be replaced by the >>>> generator to >>>> */ >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else { >>>> // XSD default namespace is >>>> enough >>>> } >>>> >>>> and in the build of the closure we have got (this >>>> fails as reported Craig): >>>> >>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>> PluginLog.logDebug("type \'" + type >>>> + "\' is an array of primitive."); >>>> addReferencedPackage(PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>> }else if >>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>> //will map to array of primitive >>>> addReferencedPackage(PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>> } else { >>>> //normal primtive like xsd:int >>>> } >>>> >>>> so the filtering never is considered. >>>> >>>> I will perform clean tests because was very >>>> difficult to find the real cause of the problem, >>>> the log file is not very clear in debug scenarios ( >>>> a lot of similar log text, no log from the >>>> templates and also cannot put the line number in >>>> the log file (tigerstripe issue)) and these >>>> problems have delayed my response. >>>> If the test go ok I will check out the changes to >>>> the trunk >>>> >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>> >>>> Best regards >>>> >>>> >>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>> >>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>> >>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>> >>>> shows an error. >>>> >>>> >>>> >>>> I think Xose is looking into it >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>> >>>> Sent: 01 June 2012 10:25 >>>> >>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>> >>>> gauthier >>>> >>>> Subject: RE: Problems with PM XSD generation >>>> >>>> >>>> >>>> Craig, >>>> >>>> >>>> >>>> There is one same filter in the getReosurceAlarms operation, filter >>>> >>>> argument. >>>> >>>> The XPathFilter is defined in the internal_filter.xsd >>>> >>>> >>>> >>>> Best regards >>>> >>>> >>>> >>>> Marc >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>> >>>> Gallen (opennms) >>>> >>>> Sent: Thursday, May 31, 2012 11:58 PM >>>> >>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>> >>>> Subject: Problems with PM XSD generation >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I have been testing the TIP_PM_Col project model and have found that the >>>> >>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>> >>>> >>>> >>>> in line 62 we have >>>> >>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>> >>>> minOccurs="0" maxOccurs="1"> >>>> >>>> >>>> >>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>> >>>> it reports this error as: >>>> >>>> >>>> >>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>> >>>> 'element'. Recorded reason: >>>> >>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>> >>>> the prefix 'filter' is not >>>> >>>> declared'. >>>> >>>> >>>> >>>> Is this a known problem or a new bug? >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>> Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions >>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>> >> >> > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions > <http://optarecoolvendor.com><http://optarecoolvendor.com> > |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-03 15:01:59
|
Hi, Some disturbing and important news. Sourceforge have just announced end of life for the hosted apps platform. This means our JOSIF Media Wiki and mantis bug tracking will need to be hosted in a different way. We have until September 1 to migrate before the hosted apps platform is turned off. Sourceforge recommend moving these apps to their Project Web platform where they will continue to host the apps for free. They are working on scripts and instructions to help with the migration. (http://sourceforge.net/apps/trac/sourceforge/wiki/Project%20web%20and%20developer%20web%20platform) But we will need to do the migration and installation which will involve some work on our part. See the email below for more details. We should discuss a plan for this this at the SII call. Cheers Craig -------- Original Message -------- Subject: Hosted Apps Retirement Date: Tue, 3 Jul 2012 14:18:51 +0000 From: SourceForge.net Team <no...@so...> To: cg...@op... In case you missed it ... We wanted to be sure you were aware of some upcoming changes to the SourceForge project hosting service. One or more of your projects use the Hosted Apps service. On September 1, 2012, the Hosted Apps service will reach the end of its life and be shut down. The reasons for this are discussed in the blog post, at http://sourceforge.net/blog/hosted-apps-retirement/ and in the wiki, at https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/ Over the coming days, we'll be publishing more documents about how to migrate your apps to your own project web space, so that none of your data is lost in this transition. We want to be sure that your project can continue to operate without interruption, so if you have any concerns, difficulty with migration, or just want to chat, please send us a note (com...@so...). Please watch the wiki page (https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/) for further updates about this process. We'll be back in touch as it gets closer to the deadline, or if anything about the plan changes. Thanks again for being part of the SourceForge community. ---------------------------------------------------------------------- SourceForge.net has made this mailing to you as a registered user of the SourceForge.net site to convey important information regarding your SourceForge.net account or your use of SourceForge.net services. We make a small number of directed mailings to registered users each year regarding their account or data, to help preserve the security of their account or prevent loss of data or service access. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-03 10:41:30
|
Hi all. I am developing a module that get the packages to perform the funcionallity desired, but in the models there are changes in the way they are instantied so a deeper revision is needed. I have got the code to obtain the packages and now we are changing the models, but has a lot of dependences in building the closure. I am trying to finish it and the publish on the sandbox area better to perform tests and avoid regression problems. Regards El 02/07/2012 15:40, Craig Gallen (opennms) escribió: > Hi Xose, > > Duncan from Tigerstripe has replied on bugzilla that we need to > uncheck the "Run All Rules as Local" > https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the > MPAC model with "Run All Rules as Local" checked and then as unchecked > to ensure that the property is correctly set in tigerstripe.xml. > However this does not appear to fix the problem. Dependencies are not > being generated by the soap plugin. Could you run the test in your > model and get back to Duncan if it is still the issue. > > Thanks > > Craig > > > > > > On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >> I have created the bug >> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >> been added to the database >> >> Email sent to: >> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >> Excluding: >> |xr...@op...| >> >> >> >> Regards >> El 28/06/2012 9:18, Flauw, Marc escribió: >>> >>> Xose, >>> >>> Send us the bug pointer and I will escalate it . >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>> *Sent:* Thursday, June 28, 2012 9:17 AM >>> *To:* Craig Gallen (opennms) >>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>> >>> Hi all. >>> I have post the problem in the user list as the bug creation >>> recommends. Nobody answer that so I am going to create the bug. I >>> have a first version of the workaround but aome problems are derived >>> in the cast operations in the src_shared classes, so I must >>> investigate deeper. If this issue is solved I can send you Craig a >>> preeliminary patch and then check the behaivour of the other >>> $allxxxx context elements. >>> >>> >>> Regards >>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>> >>> Xose & Marc, >>> >>> Is there a plan to complete primitive.url / primitive.uri in the >>> soap generator. I have support for it in the Java generators but >>> need the Soap generator working with this stereotype to test >>> this code. >>> >>> Also has a bug been raised against Tigerstripe for the >>> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >>> rather than have Xose get a work around because if this isnt >>> working, its possible other 'get all collections' of artificates >>> are not working. So this could be a general problem for the >>> other generators including Cisco's own. >>> >>> Xose, have you raised a bug report and if so what is the bug >>> number? >>> >>> Marc, when we have a bug report, can we escalate this directly >>> to the tigerstripe team because it is a show stopper for us. >>> >>> I'm afraid I cannot do any more development until this is fixed. >>> >>> Thanks for your help >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> >>> I am going to test a workaround to see if this could be >>> supported without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>> >>> Hi, >>> >>> So is there a work around or do we have to wait for >>> Tigerstripe to sort this out. >>> The old version of tigerstripe (6.9.xxx) is no longer >>> available to download. >>> >>> Craig >>> >>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>> >>> Thanks Craig. >>> I have performed some test and I can see an error in >>> the Default Velocity context contents. When the >>> $allPackage variable is used in the >>> dependencyAnalyzer.vm template, it is expected that >>> all artifacts, including the dependences, are >>> included in that collection. In my tests I've got >>> this behaivour: >>> >>> Old version of tigerstripe( Tigerstripe Core >>> (Incubation) 0.6.935.201102010903 >>> org.eclipse.tigerstripe.base.feature.group) >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633), >>> org.tmforum.tip.cbe.perf(1039318676), >>> org.tmforum.tip.common.notifications(23492680), >>> org.tmforum.tip.resource.res(1133197283), >>> org.tmforum.tip.cbe.root(1039387789), >>> org.tmforum.tip(-660924437), >>> org.tmforum.tip.cbe.root._char(-1449023596), >>> org.tmforum(1644248382), org(110308), >>> org.tmforum.tip.common(442435918), >>> org.tmforum.tip.cbe.party(-2140978021), >>> org.tmforum.tip.cbe.problem(292836116), >>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>> org.tmforum.tip.internal.filter(-1708340282), >>> org.tmforum.tip.internal.extensibility(-1665414181), >>> org.tmforum.tip.internal(1151687008), >>> org.tmforum.tip.cbe.root.tip(1325885370), >>> org.tmforum.tip.internal.notifications(-1680981798), >>> org.tmforum.tip.common.exceptions(234099364), >>> org.tmforum.tip.cbe.party.role(1514413545), >>> org.tmforum.tip.internal.entity(-1732123599), >>> org.tmforum.tip.resource.res.tip(-1716701168), >>> org.tmforum.tip.internal.exceptions(-367434926), >>> org.tmforum.tip.cbe(1681757027), >>> org.tmforum.tip.internal.iterator(866200892), >>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>> [2012-06-26 10:21:29.996+0200] >>> >>> New version og tigerstripe( Tigerstripe Core >>> (Incubation) 0.7.0.201206181258 >>> org.eclipse.tigerstripe.base.feature.group): >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>> 10:28:54.989+0200] >>> >>> So it seems that this is root cause for the missed >>> files. >>> I will create a bug in Tigerstripe. >>> >>> Regards >>> >>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi Craig, when you talk about the updated Soap >>> Plugin, which version (in svn url) are using?, >>> because the two first issues seems to be solved in >>> the trunk with the other Tigerstripe version. >>> >>> >>> >>> >>> Regards >>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>> >>> Hi Xose, >>> >>> I just updated my tigerstripe to the latest release >>> 0.7.0.20120618258 but Ialso updated the Soap plug-in >>> and have found multiple problems but I am not sure >>> if they are all related to the tigerstripe upgrade >>> or to the current state of the soap plugin. Could >>> you build the RAM project and check the generated >>> XSD's to see the problem. >>> >>> 1. when you build the RAM project there is a problem >>> with model closure. None of the Dependency XSD's >>> get generated in the RAM_Model project >>> >>> 2. TrackingRecordResultWithIterator referenced as >>> 'problem:TrackingRecordResultWithIterator' in >>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>> is never generated. >>> >>> 3. Tigerstripe 0.7.0.20120618258. handles >>> primitive.string differently and generates type >>> 'String' instead of 'java.lang.String' this results >>> in type :String instead of xsd:string. I did a >>> quick fix given in the following patch adding >>> || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> >>> to >>> || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> this means that old and new versions of tigerstipe >>> will work >>> >>> There is a patch below but havent checked this in >>> because I was not sure that else you were doing to >>> the Soap plugin >>> >>> Craig >>> >>> >>> >>> ### Eclipse Workspace Patch 1.0 >>> #P TIP_Soap_Generator >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (working copy) >>> @@ -510,8 +510,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + refTypeFullName >>> + "\' is a primitive type in >>> current TIP profile."); >>> type = >>> mapPrimitivesToXsdType(refType.getName(), >>> isArray(refType), >>> @@ -519,7 +519,7 @@ >>> } >>> >>> /** >>> - * Map datatyeps and enumerations >>> + * Map datatypes and enumerations >>> */ >>> // if (refType.isDatatype() || refType.isEnum() >>> else if (isDatatype(refType) || >>> isEnumeration(refType)) { >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (working copy) >>> @@ -170,8 +170,9 @@ >>> private void addReferencedPackage(IType type) { >>> >>> if (type.isPrimitive() >>> - || >>> "primitive".equalsIgnoreCase(type.getPackage()) || >>> - >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { >>> + || >>> "primitive".equalsIgnoreCase(type.getPackage()) >>> + || >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> //will map objectName to >>> EntityIdentifier or ArrayOfEntityIdentifier >>> if >>> ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> @@ -378,8 +379,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + typeName >>> + "\' is a primitive type in >>> current TIP profile."); >>> >>> >>> >>> >>> >>> >>> >>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi all. I think that I have found the error and I >>> will try to fix it as soon as possible. There are >>> some related issues, one error in the codification >>> of a method and a forgetted evaluation of filtering >>> in the velocity template and also a case related >>> with primitive type filter not supported in the >>> build of the closure outside the interfaces. >>> >>> In the interfaces build the search is performed as >>> follows(this works fine as reported Marc): >>> >>> if >>> ("objectName".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type >>> 'objectName' defines the protocol >>> * neutral unique name of an >>> object. This data type will >>> * be replaced by the >>> generators by an EntityIdentifier >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> ("filter".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type 'filter'. >>> This data type will >>> * be replaced by the >>> generator to >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> (XmlSchemaHelpers.isUnbounded(argType)) { >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else { >>> // XSD default namespace is >>> enough >>> } >>> >>> and in the build of the closure we have got (this >>> fails as reported Craig): >>> >>> if ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> + "\' is an array of primitive."); >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>> }else if >>> (XmlSchemaHelpers.isUnbounded(type)){ >>> //will map to array of primitive >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>> } else { >>> //normal primtive like xsd:int >>> } >>> >>> so the filtering never is considered. >>> >>> I will perform clean tests because was very >>> difficult to find the real cause of the problem, the >>> log file is not very clear in debug scenarios ( a >>> lot of similar log text, no log from the templates >>> and also cannot put the line number in the log file >>> (tigerstripe issue)) and these problems have delayed >>> my response. >>> If the test go ok I will check out the changes to >>> the trunk >>> >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> >>> Best regards >>> >>> >>> El 01/06/2012 16:58, Craig Gallen escribió: >>> >>> Hi, >>> >>> >>> >>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>> >>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>> >>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>> >>> shows an error. >>> >>> >>> >>> I think Xose is looking into it >>> >>> >>> >>> Craig >>> >>> >>> >>> -----Original Message----- >>> >>> From: Flauw, Marc [mailto:Mar...@hp...] >>> >>> Sent: 01 June 2012 10:25 >>> >>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>> >>> gauthier >>> >>> Subject: RE: Problems with PM XSD generation >>> >>> >>> >>> Craig, >>> >>> >>> >>> There is one same filter in the getReosurceAlarms operation, filter >>> >>> argument. >>> >>> The XPathFilter is defined in the internal_filter.xsd >>> >>> >>> >>> Best regards >>> >>> >>> >>> Marc >>> >>> >>> >>> -----Original Message----- >>> >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>> >>> Gallen (opennms) >>> >>> Sent: Thursday, May 31, 2012 11:58 PM >>> >>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>> >>> Subject: Problems with PM XSD generation >>> >>> >>> >>> Hi, >>> >>> >>> >>> I have been testing the TIP_PM_Col project model and have found that the >>> >>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>> >>> >>> >>> in line 62 we have >>> >>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>> >>> minOccurs="0" maxOccurs="1"> >>> >>> >>> >>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>> >>> it reports this error as: >>> >>> >>> >>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>> >>> 'element'. Recorded reason: >>> >>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>> >>> the prefix 'filter' is not >>> >>> declared'. >>> >>> >>> >>> Is this a known problem or a new bug? >>> >>> >>> >>> Craig >>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>> Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-02 14:34:22
|
I have responsed that to Duncan on Friday. I am going to send again. In the workaround I am dealing with a Proxy implementation of hte artifacts in these new version that give some problems in filter the packages among allArtifacts. I am going to resend the response to Duncan. Regards El 02/07/2012 15:40, Craig Gallen (opennms) escribió: > Hi Xose, > > Duncan from Tigerstripe has replied on bugzilla that we need to > uncheck the "Run All Rules as Local" > https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the > MPAC model with "Run All Rules as Local" checked and then as unchecked > to ensure that the property is correctly set in tigerstripe.xml. > However this does not appear to fix the problem. Dependencies are not > being generated by the soap plugin. Could you run the test in your > model and get back to Duncan if it is still the issue. > > Thanks > > Craig > > > > > > On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >> I have created the bug >> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >> been added to the database >> >> Email sent to: >> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >> Excluding: >> |xr...@op...| >> >> >> >> Regards >> El 28/06/2012 9:18, Flauw, Marc escribió: >>> >>> Xose, >>> >>> Send us the bug pointer and I will escalate it . >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>> *Sent:* Thursday, June 28, 2012 9:17 AM >>> *To:* Craig Gallen (opennms) >>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>> >>> Hi all. >>> I have post the problem in the user list as the bug creation >>> recommends. Nobody answer that so I am going to create the bug. I >>> have a first version of the workaround but aome problems are derived >>> in the cast operations in the src_shared classes, so I must >>> investigate deeper. If this issue is solved I can send you Craig a >>> preeliminary patch and then check the behaivour of the other >>> $allxxxx context elements. >>> >>> >>> Regards >>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>> >>> Xose & Marc, >>> >>> Is there a plan to complete primitive.url / primitive.uri in the >>> soap generator. I have support for it in the Java generators but >>> need the Soap generator working with this stereotype to test >>> this code. >>> >>> Also has a bug been raised against Tigerstripe for the >>> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >>> rather than have Xose get a work around because if this isnt >>> working, its possible other 'get all collections' of artificates >>> are not working. So this could be a general problem for the >>> other generators including Cisco's own. >>> >>> Xose, have you raised a bug report and if so what is the bug >>> number? >>> >>> Marc, when we have a bug report, can we escalate this directly >>> to the tigerstripe team because it is a show stopper for us. >>> >>> I'm afraid I cannot do any more development until this is fixed. >>> >>> Thanks for your help >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> >>> I am going to test a workaround to see if this could be >>> supported without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>> >>> Hi, >>> >>> So is there a work around or do we have to wait for >>> Tigerstripe to sort this out. >>> The old version of tigerstripe (6.9.xxx) is no longer >>> available to download. >>> >>> Craig >>> >>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>> >>> Thanks Craig. >>> I have performed some test and I can see an error in >>> the Default Velocity context contents. When the >>> $allPackage variable is used in the >>> dependencyAnalyzer.vm template, it is expected that >>> all artifacts, including the dependences, are >>> included in that collection. In my tests I've got >>> this behaivour: >>> >>> Old version of tigerstripe( Tigerstripe Core >>> (Incubation) 0.6.935.201102010903 >>> org.eclipse.tigerstripe.base.feature.group) >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633), >>> org.tmforum.tip.cbe.perf(1039318676), >>> org.tmforum.tip.common.notifications(23492680), >>> org.tmforum.tip.resource.res(1133197283), >>> org.tmforum.tip.cbe.root(1039387789), >>> org.tmforum.tip(-660924437), >>> org.tmforum.tip.cbe.root._char(-1449023596), >>> org.tmforum(1644248382), org(110308), >>> org.tmforum.tip.common(442435918), >>> org.tmforum.tip.cbe.party(-2140978021), >>> org.tmforum.tip.cbe.problem(292836116), >>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>> org.tmforum.tip.internal.filter(-1708340282), >>> org.tmforum.tip.internal.extensibility(-1665414181), >>> org.tmforum.tip.internal(1151687008), >>> org.tmforum.tip.cbe.root.tip(1325885370), >>> org.tmforum.tip.internal.notifications(-1680981798), >>> org.tmforum.tip.common.exceptions(234099364), >>> org.tmforum.tip.cbe.party.role(1514413545), >>> org.tmforum.tip.internal.entity(-1732123599), >>> org.tmforum.tip.resource.res.tip(-1716701168), >>> org.tmforum.tip.internal.exceptions(-367434926), >>> org.tmforum.tip.cbe(1681757027), >>> org.tmforum.tip.internal.iterator(866200892), >>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>> [2012-06-26 10:21:29.996+0200] >>> >>> New version og tigerstripe( Tigerstripe Core >>> (Incubation) 0.7.0.201206181258 >>> org.eclipse.tigerstripe.base.feature.group): >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>> 10:28:54.989+0200] >>> >>> So it seems that this is root cause for the missed >>> files. >>> I will create a bug in Tigerstripe. >>> >>> Regards >>> >>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi Craig, when you talk about the updated Soap >>> Plugin, which version (in svn url) are using?, >>> because the two first issues seems to be solved in >>> the trunk with the other Tigerstripe version. >>> >>> >>> >>> >>> Regards >>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>> >>> Hi Xose, >>> >>> I just updated my tigerstripe to the latest release >>> 0.7.0.20120618258 but Ialso updated the Soap plug-in >>> and have found multiple problems but I am not sure >>> if they are all related to the tigerstripe upgrade >>> or to the current state of the soap plugin. Could >>> you build the RAM project and check the generated >>> XSD's to see the problem. >>> >>> 1. when you build the RAM project there is a problem >>> with model closure. None of the Dependency XSD's >>> get generated in the RAM_Model project >>> >>> 2. TrackingRecordResultWithIterator referenced as >>> 'problem:TrackingRecordResultWithIterator' in >>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>> is never generated. >>> >>> 3. Tigerstripe 0.7.0.20120618258. handles >>> primitive.string differently and generates type >>> 'String' instead of 'java.lang.String' this results >>> in type :String instead of xsd:string. I did a >>> quick fix given in the following patch adding >>> || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> >>> to >>> || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> this means that old and new versions of tigerstipe >>> will work >>> >>> There is a patch below but havent checked this in >>> because I was not sure that else you were doing to >>> the Soap plugin >>> >>> Craig >>> >>> >>> >>> ### Eclipse Workspace Patch 1.0 >>> #P TIP_Soap_Generator >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (working copy) >>> @@ -510,8 +510,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + refTypeFullName >>> + "\' is a primitive type in >>> current TIP profile."); >>> type = >>> mapPrimitivesToXsdType(refType.getName(), >>> isArray(refType), >>> @@ -519,7 +519,7 @@ >>> } >>> >>> /** >>> - * Map datatyeps and enumerations >>> + * Map datatypes and enumerations >>> */ >>> // if (refType.isDatatype() || refType.isEnum() >>> else if (isDatatype(refType) || >>> isEnumeration(refType)) { >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (working copy) >>> @@ -170,8 +170,9 @@ >>> private void addReferencedPackage(IType type) { >>> >>> if (type.isPrimitive() >>> - || >>> "primitive".equalsIgnoreCase(type.getPackage()) || >>> - >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { >>> + || >>> "primitive".equalsIgnoreCase(type.getPackage()) >>> + || >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> //will map objectName to >>> EntityIdentifier or ArrayOfEntityIdentifier >>> if >>> ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> @@ -378,8 +379,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + typeName >>> + "\' is a primitive type in >>> current TIP profile."); >>> >>> >>> >>> >>> >>> >>> >>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi all. I think that I have found the error and I >>> will try to fix it as soon as possible. There are >>> some related issues, one error in the codification >>> of a method and a forgetted evaluation of filtering >>> in the velocity template and also a case related >>> with primitive type filter not supported in the >>> build of the closure outside the interfaces. >>> >>> In the interfaces build the search is performed as >>> follows(this works fine as reported Marc): >>> >>> if >>> ("objectName".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type >>> 'objectName' defines the protocol >>> * neutral unique name of an >>> object. This data type will >>> * be replaced by the >>> generators by an EntityIdentifier >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> ("filter".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type 'filter'. >>> This data type will >>> * be replaced by the >>> generator to >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> (XmlSchemaHelpers.isUnbounded(argType)) { >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else { >>> // XSD default namespace is >>> enough >>> } >>> >>> and in the build of the closure we have got (this >>> fails as reported Craig): >>> >>> if ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> + "\' is an array of primitive."); >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>> }else if >>> (XmlSchemaHelpers.isUnbounded(type)){ >>> //will map to array of primitive >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>> } else { >>> //normal primtive like xsd:int >>> } >>> >>> so the filtering never is considered. >>> >>> I will perform clean tests because was very >>> difficult to find the real cause of the problem, the >>> log file is not very clear in debug scenarios ( a >>> lot of similar log text, no log from the templates >>> and also cannot put the line number in the log file >>> (tigerstripe issue)) and these problems have delayed >>> my response. >>> If the test go ok I will check out the changes to >>> the trunk >>> >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> >>> Best regards >>> >>> >>> El 01/06/2012 16:58, Craig Gallen escribió: >>> >>> Hi, >>> >>> >>> >>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>> >>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>> >>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>> >>> shows an error. >>> >>> >>> >>> I think Xose is looking into it >>> >>> >>> >>> Craig >>> >>> >>> >>> -----Original Message----- >>> >>> From: Flauw, Marc [mailto:Mar...@hp...] >>> >>> Sent: 01 June 2012 10:25 >>> >>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>> >>> gauthier >>> >>> Subject: RE: Problems with PM XSD generation >>> >>> >>> >>> Craig, >>> >>> >>> >>> There is one same filter in the getReosurceAlarms operation, filter >>> >>> argument. >>> >>> The XPathFilter is defined in the internal_filter.xsd >>> >>> >>> >>> Best regards >>> >>> >>> >>> Marc >>> >>> >>> >>> -----Original Message----- >>> >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>> >>> Gallen (opennms) >>> >>> Sent: Thursday, May 31, 2012 11:58 PM >>> >>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>> >>> Subject: Problems with PM XSD generation >>> >>> >>> >>> Hi, >>> >>> >>> >>> I have been testing the TIP_PM_Col project model and have found that the >>> >>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>> >>> >>> >>> in line 62 we have >>> >>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>> >>> minOccurs="0" maxOccurs="1"> >>> >>> >>> >>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>> >>> it reports this error as: >>> >>> >>> >>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>> >>> 'element'. Recorded reason: >>> >>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>> >>> the prefix 'filter' is not >>> >>> declared'. >>> >>> >>> >>> Is this a known problem or a new bug? >>> >>> >>> >>> Craig >>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>> Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-02 13:40:39
|
Hi Xose, Duncan from Tigerstripe has replied on bugzilla that we need to uncheck the "Run All Rules as Local" https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the MPAC model with "Run All Rules as Local" checked and then as unchecked to ensure that the property is correctly set in tigerstripe.xml. However this does not appear to fix the problem. Dependencies are not being generated by the soap plugin. Could you run the test in your model and get back to Duncan if it is still the issue. Thanks Craig On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: > I have created the bug > Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has > been added to the database > > Email sent to: > |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| > Excluding: > |xr...@op...| > > > > Regards > El 28/06/2012 9:18, Flauw, Marc escribió: >> >> Xose, >> >> Send us the bug pointer and I will escalate it . >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* Thursday, June 28, 2012 9:17 AM >> *To:* Craig Gallen (opennms) >> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >> >> Hi all. >> I have post the problem in the user list as the bug creation >> recommends. Nobody answer that so I am going to create the bug. I >> have a first version of the workaround but aome problems are derived >> in the cast operations in the src_shared classes, so I must >> investigate deeper. If this issue is solved I can send you Craig a >> preeliminary patch and then check the behaivour of the other $allxxxx >> context elements. >> >> >> Regards >> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >> >> Xose & Marc, >> >> Is there a plan to complete primitive.url / primitive.uri in the >> soap generator. I have support for it in the Java generators but >> need the Soap generator working with this stereotype to test this >> code. >> >> Also has a bug been raised against Tigerstripe for the >> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >> rather than have Xose get a work around because if this isnt >> working, its possible other 'get all collections' of artificates >> are not working. So this could be a general problem for the other >> generators including Cisco's own. >> >> Xose, have you raised a bug report and if so what is the bug >> number? >> >> Marc, when we have a bug report, can we escalate this directly to >> the tigerstripe team because it is a show stopper for us. >> >> I'm afraid I cannot do any more development until this is fixed. >> >> Thanks for your help >> >> Craig >> >> >> >> >> >> >> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >> >> I am going to test a workaround to see if this could be >> supported without change the tigerstripe core. >> >> Regards >> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >> >> Hi, >> >> So is there a work around or do we have to wait for >> Tigerstripe to sort this out. >> The old version of tigerstripe (6.9.xxx) is no longer >> available to download. >> >> Craig >> >> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >> >> Thanks Craig. >> I have performed some test and I can see an error in >> the Default Velocity context contents. When the >> $allPackage variable is used in the >> dependencyAnalyzer.vm template, it is expected that >> all artifacts, including the dependences, are >> included in that collection. In my tests I've got >> this behaivour: >> >> Old version of tigerstripe( Tigerstripe Core >> (Incubation) 0.6.935.201102010903 >> org.eclipse.tigerstripe.base.feature.group) >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633), >> org.tmforum.tip.cbe.perf(1039318676), >> org.tmforum.tip.common.notifications(23492680), >> org.tmforum.tip.resource.res(1133197283), >> org.tmforum.tip.cbe.root(1039387789), >> org.tmforum.tip(-660924437), >> org.tmforum.tip.cbe.root._char(-1449023596), >> org.tmforum(1644248382), org(110308), >> org.tmforum.tip.common(442435918), >> org.tmforum.tip.cbe.party(-2140978021), >> org.tmforum.tip.cbe.problem(292836116), >> org.tmforum.tip.cbe.root.tip.fmk(693071952), >> org.tmforum.tip.internal.filter(-1708340282), >> org.tmforum.tip.internal.extensibility(-1665414181), >> org.tmforum.tip.internal(1151687008), >> org.tmforum.tip.cbe.root.tip(1325885370), >> org.tmforum.tip.internal.notifications(-1680981798), >> org.tmforum.tip.common.exceptions(234099364), >> org.tmforum.tip.cbe.party.role(1514413545), >> org.tmforum.tip.internal.entity(-1732123599), >> org.tmforum.tip.resource.res.tip(-1716701168), >> org.tmforum.tip.internal.exceptions(-367434926), >> org.tmforum.tip.cbe(1681757027), >> org.tmforum.tip.internal.iterator(866200892), >> org.tmforum.tip.resource.res.tip.nrb(290014272)] >> [2012-06-26 10:21:29.996+0200] >> >> New version og tigerstripe( Tigerstripe Core >> (Incubation) 0.7.0.201206181258 >> org.eclipse.tigerstripe.base.feature.group): >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633)] [2012-06-26 >> 10:28:54.989+0200] >> >> So it seems that this is root cause for the missed files. >> I will create a bug in Tigerstripe. >> >> Regards >> >> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >> >> Hi >> From eclipse, Soap generator subversion; >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >> Revision 3453 >> (last change revision 3444 last commit author xrsousa) >> >> Craig >> >> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >> >> Hi Craig, when you talk about the updated Soap >> Plugin, which version (in svn url) are using?, >> because the two first issues seems to be solved in >> the trunk with the other Tigerstripe version. >> >> >> >> >> Regards >> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >> >> Hi Xose, >> >> I just updated my tigerstripe to the latest release >> 0.7.0.20120618258 but Ialso updated the Soap plug-in >> and have found multiple problems but I am not sure if >> they are all related to the tigerstripe upgrade or to >> the current state of the soap plugin. Could you build >> the RAM project and check the generated XSD's to see >> the problem. >> >> 1. when you build the RAM project there is a problem >> with model closure. None of the Dependency XSD's get >> generated in the RAM_Model project >> >> 2. TrackingRecordResultWithIterator referenced as >> 'problem:TrackingRecordResultWithIterator' in >> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >> is never generated. >> >> 3. Tigerstripe 0.7.0.20120618258. handles >> primitive.string differently and generates type >> 'String' instead of 'java.lang.String' this results >> in type :String instead of xsd:string. I did a quick >> fix given in the following patch adding >> || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> >> to >> || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> this means that old and new versions of tigerstipe >> will work >> >> There is a patch below but havent checked this in >> because I was not sure that else you were doing to >> the Soap plugin >> >> Craig >> >> >> >> ### Eclipse Workspace Patch 1.0 >> #P TIP_Soap_Generator >> Index: >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> =================================================================== >> --- >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> (revision 3453) >> +++ >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> (working copy) >> @@ -510,8 +510,8 @@ >> */ >> if (refType.isPrimitive() >> || >> refType.getPackage().equalsIgnoreCase("primitive") >> - || >> "java.lang.String".equalsIgnoreCase(refType >> - .getFullyQualifiedName())) { >> + || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> PluginLog.logDebug("\'" + refTypeFullName >> + "\' is a primitive type in >> current TIP profile."); >> type = >> mapPrimitivesToXsdType(refType.getName(), >> isArray(refType), >> @@ -519,7 +519,7 @@ >> } >> >> /** >> - * Map datatyeps and enumerations >> + * Map datatypes and enumerations >> */ >> // if (refType.isDatatype() || refType.isEnum() >> else if (isDatatype(refType) || >> isEnumeration(refType)) { >> Index: >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> =================================================================== >> --- >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> (revision 3453) >> +++ >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> (working copy) >> @@ -170,8 +170,9 @@ >> private void addReferencedPackage(IType type) { >> >> if (type.isPrimitive() >> - || >> "primitive".equalsIgnoreCase(type.getPackage()) || >> - >> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >> { >> + || >> "primitive".equalsIgnoreCase(type.getPackage()) >> + || >> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> //will map objectName to >> EntityIdentifier or ArrayOfEntityIdentifier >> if >> ("objectName".equalsIgnoreCase(type.getName())){ >> PluginLog.logDebug("type \'" + type >> @@ -378,8 +379,8 @@ >> */ >> if (refType.isPrimitive() >> || >> refType.getPackage().equalsIgnoreCase("primitive") >> - || >> "java.lang.String".equalsIgnoreCase(refType >> - .getFullyQualifiedName())) { >> + || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> PluginLog.logDebug("\'" + typeName >> + "\' is a primitive type in >> current TIP profile."); >> >> >> >> >> >> >> >> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >> >> Hi all. I think that I have found the error and I >> will try to fix it as soon as possible. There are >> some related issues, one error in the codification of >> a method and a forgetted evaluation of filtering in >> the velocity template and also a case related with >> primitive type filter not supported in the build of >> the closure outside the interfaces. >> >> In the interfaces build the search is performed as >> follows(this works fine as reported Marc): >> >> if >> ("objectName".equalsIgnoreCase(argType.getName())) { >> /* >> * This data type >> 'objectName' defines the protocol >> * neutral unique name of an >> object. This data type will >> * be replaced by the >> generators by an EntityIdentifier >> */ >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else if >> ("filter".equalsIgnoreCase(argType.getName())) { >> /* >> * This data type 'filter'. >> This data type will >> * be replaced by the >> generator to >> */ >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else if >> (XmlSchemaHelpers.isUnbounded(argType)) { >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else { >> // XSD default namespace is >> enough >> } >> >> and in the build of the closure we have got (this >> fails as reported Craig): >> >> if ("objectName".equalsIgnoreCase(type.getName())){ >> PluginLog.logDebug("type \'" + type >> + "\' is an array of primitive."); >> addReferencedPackage(PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >> }else if >> (XmlSchemaHelpers.isUnbounded(type)){ >> //will map to array of primitive >> addReferencedPackage(PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >> } else { >> //normal primtive like xsd:int >> } >> >> so the filtering never is considered. >> >> I will perform clean tests because was very difficult >> to find the real cause of the problem, the log file >> is not very clear in debug scenarios ( a lot of >> similar log text, no log from the templates and also >> cannot put the line number in the log file >> (tigerstripe issue)) and these problems have delayed >> my response. >> If the test go ok I will check out the changes to the >> trunk >> >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >> >> Best regards >> >> >> El 01/06/2012 16:58, Craig Gallen escribió: >> >> Hi, >> >> >> >> I agree it is defined in internal_filter.xsd but it doesn't seem to be >> >> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >> >> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >> >> shows an error. >> >> >> >> I think Xose is looking into it >> >> >> >> Craig >> >> >> >> -----Original Message----- >> >> From: Flauw, Marc [mailto:Mar...@hp...] >> >> Sent: 01 June 2012 10:25 >> >> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >> >> gauthier >> >> Subject: RE: Problems with PM XSD generation >> >> >> >> Craig, >> >> >> >> There is one same filter in the getReosurceAlarms operation, filter >> >> argument. >> >> The XPathFilter is defined in the internal_filter.xsd >> >> >> >> Best regards >> >> >> >> Marc >> >> >> >> -----Original Message----- >> >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >> >> Gallen (opennms) >> >> Sent: Thursday, May 31, 2012 11:58 PM >> >> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >> >> Subject: Problems with PM XSD generation >> >> >> >> Hi, >> >> >> >> I have been testing the TIP_PM_Col project model and have found that the >> >> dep_cbe_perf_spec.xsd (attached) file is generated with errors >> >> >> >> in line 62 we have >> >> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >> >> minOccurs="0" maxOccurs="1"> >> >> >> >> filter:XPathQueryFilter is not defined and if you open the file in eclipse >> >> it reports this error as: >> >> >> >> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >> >> 'element'. Recorded reason: >> >> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >> >> the prefix 'filter' is not >> >> declared'. >> >> >> >> Is this a known problem or a new bug? >> >> >> >> Craig >> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >> Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions > <http://optarecoolvendor.com><http://optarecoolvendor.com> > |
197 messages has been excluded from this view by a project administrator.
