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
(2) |
Jun
(3) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(22) |
Sep
(13) |
Oct
(10) |
Nov
(10) |
Dec
(14) |
| 2011 |
Jan
(12) |
Feb
(30) |
Mar
(14) |
Apr
(17) |
May
(3) |
Jun
(5) |
Jul
(11) |
Aug
(30) |
Sep
(10) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2012 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(10) |
Jun
(8) |
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
| 2013 |
Jan
|
Feb
(4) |
Mar
(14) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Craig G. (opennms) <cg...@op...> - 2015-12-18 15:32:59
|
Folks, I have been talking with David Hustace about the possibility of hosting the annual OpenNMS DevJam this year in Dublin Ireland. This would allow more people from Europe to attend and give a rest to Mike who has done all the work over years organising things in Minnesota. No decisions have been made but presently I am looking into possible venues and costs before we make any decisions. However Ronny Trommer suggested I should raise this on the discuss list to gauge any reaction or suggestions. Any and All feedback very welcome Finally - may I wish you all a Merry Christmas and a happy new year. Thanks Craig |
|
From: Flauw, M. <Mar...@hp...> - 2013-04-08 09:18:30
|
Dear all,
Can you help with the problem below?
One of the attribute of the Collection Job is MonitoredObjectsCriteria which is an empty abstract class. It has 2 subclasses MonitoredObjectClass and MonitoredObjectCriteria.
When trying to create a CollectionJob, one of the input arguments is a MonitoredObjectCriteria, but for the real creation of an instance, a monitoredObjectClass needs to be provided and this fails.
This can be extended to a more general question of polymorphism on attributes.
Can you help?
Best regards
Marc
From: Stein, Yuval [mailto:Yuv...@te...]
Sent: Monday, April 08, 2013 10:54 AM
To: sam...@wi...; pga...@tm...; Flauw, Marc
Cc: yoa...@my...; vin...@wi...; san...@wi...
Subject: RE: SOAP request - PM Collection Job - createMeasurementCollectionJobRequest
Hi Sam,
You are right. I just sent a post, as we tackled the same issue while trying to test with MYCOM.
Additionally, the same issue exists for the SchedulDefinition.
Best Regards,
Yuval
From: sam...@wi...<mailto:sam...@wi...> [mailto:sam...@wi...]
Sent: Monday, April 08, 2013 11:48 AM
To: pga...@tm...<mailto:pga...@tm...>; Mar...@hp...<mailto:Mar...@hp...>; Stein, Yuval
Cc: yoa...@my...<mailto:yoa...@my...>; vin...@wi...<mailto:vin...@wi...>; san...@wi...<mailto:san...@wi...>
Subject: SOAP request - PM Collection Job - createMeasurementCollectionJobRequest
Hi Pierre/Yuval/Mark,
I am trying to generate a SOAP request for measurementcollectionjobservice#createMeasurementCollectionJobRequest. In which one of the input parameter monitoredObjectsCriteria (Type MonitoredObjectsCriteria) is defined as abstract without any methods.
Although the implementation (MonitoredClassCriteria, MonitoredInstancesCriteria) has the details like monitoredObjectClass, I am not able to pass it in SOAP request as it expects the super class (abstract) with no parameters. Please let me know the details of sample SOAP structure, also let me know if you are able successfully test the web-services interfaces at your end.
pm_cbe_perf_mon.xsd
<xsd:complexType name="MonitoredObjectsCriteria" abstract="true">
<xsd:annotation>
<xsd:documentation>
<p>A criteria for specifying what monitored objects are referenced by a PM query, both scheduled or ad-hoc.</p>
<p>This datatype is abstract</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence/>
</xsd:complexType>
Should it be as follows having the definitions in the abstract class instead of a marker abstract class?
<xsd:complexType name="MonitoredObjectsCriteria" abstract="true">
<xsd:annotation>
<xsd:documentation>
<p>A criteria for specifying what monitored objects are referenced by a PM query, both scheduled or ad-hoc.</p>
<p>This datatype is abstract</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="monitoredObjectClass" type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A monitored object class for specifying the set of instances that are referenced by a PM query.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:sequence/>
</xsd:complexType>
Current SOAP:
<soapenv:Body>
<coll:createMeasurementCollectionJobRequest>
<coll:createData>
........
........
<coll:monitoredObjectsCriteria/>....Not able to pass the sub-class here.
</coll:createData>
</coll:createMeasurementCollectionJobRequest>
</soapenv:Body>
Regards
Sam
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com<http://www.wipro.com>
Information in this e-mail and its attachments is confidential and privileged under the TEOCO confidentiality terms that can be reviewed here<http://www.teoco.com/email-disclaimer>.
|
|
From: He, Yong-J. (W. ES-Apps-GD-China-WH) <yon...@hp...> - 2013-04-08 06:42:29
|
Hi All, There is a new feature need to define an xsd for SID_Import.xml to allow validation of the syntax. So, what's the targetNamespace of sidImport.xsd should be? Best Regards Yong-Jie |
|
From: Flauw, M. <Mar...@hp...> - 2013-03-08 14:36:49
|
Pierre, In trunk Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Friday, March 08, 2013 2:57 PM To: OpenOSS discussion Cc: <sam...@wi...> Subject: Re: [Openoss-discuss] Entity Identifier updated in Internal Model Hi Marc, Do i have to pick it up from a branch or is it in trunk ? Pierre On 2013-03-08, at 8:51 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Pierre, I don't think any change is needed in Doc Generator. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...<http://tmforum.org>] Sent: Friday, March 08, 2013 2:46 PM To: OpenOSS discussion Cc: <sam...@wi...<mailto:sam...@wi...>> Subject: Re: [Openoss-discuss] Entity Identifier updated in Internal Model Ok will make the required change to SOAP and DOC On 2013-03-08, at 8:18 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Dear all, I made the changes we agreed upon in the Internal Model. It is committed in SVN. Best regards Marc ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Pierre G. <pga...@tm...> - 2013-03-08 14:12:26
|
Hi Marc, Do i have to pick it up from a branch or is it in trunk ? Pierre On 2013-03-08, at 8:51 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Pierre, I don’t think any change is needed in Doc Generator. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...<http://tmforum.org>] Sent: Friday, March 08, 2013 2:46 PM To: OpenOSS discussion Cc: <sam...@wi...<mailto:sam...@wi...>> Subject: Re: [Openoss-discuss] Entity Identifier updated in Internal Model Ok will make the required change to SOAP and DOC On 2013-03-08, at 8:18 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Dear all, I made the changes we agreed upon in the Internal Model. It is committed in SVN. Best regards Marc ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Flauw, M. <Mar...@hp...> - 2013-03-08 13:53:08
|
Pierre, I don't think any change is needed in Doc Generator. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Friday, March 08, 2013 2:46 PM To: OpenOSS discussion Cc: <sam...@wi...> Subject: Re: [Openoss-discuss] Entity Identifier updated in Internal Model Ok will make the required change to SOAP and DOC On 2013-03-08, at 8:18 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Dear all, I made the changes we agreed upon in the Internal Model. It is committed in SVN. Best regards Marc ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Pierre G. <pga...@tm...> - 2013-03-08 13:45:41
|
Ok will make the required change to SOAP and DOC On 2013-03-08, at 8:18 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Dear all, I made the changes we agreed upon in the Internal Model. It is committed in SVN. Best regards Marc ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Flauw, M. <Mar...@hp...> - 2013-03-08 13:35:43
|
Dear all, I made the changes we agreed upon in the Internal Model. It is committed in SVN. Best regards Marc |
|
From: Flauw, M. <Mar...@hp...> - 2013-03-08 13:09:46
|
Pierre, Ok. On EID, I started and I need to complete hopefully today. I have been busy on others fronts. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Friday, March 08, 2013 1:28 PM To: Flauw, Marc Cc: SB Mahapatra; Craig Gallen (opennms); Tina O Sullivan; Vai...@re...; OpenOSS discussion (ope...@li...); <xr...@op...> Sousa Vazquez Subject: Re: Maven Upgrade Hi Marc, We are not migrating for 1.2 Have you done the change to the EID in the common model ? We need to finish the coding of the SOAP and DOC generators to support this feature before we can freeze the code. Also the RI/CTK code will need to be updated. Pierre On 2013-03-08, at 3:25 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Hi SB, I think we decided not to upgrade maven for JOSIF 1.2. We need to freeze 1.2 asap Best regards Marc From: SB Mahapatra [mailto:sbm...@tm...<http://tmforum.org>] Sent: Friday, March 08, 2013 7:25 AM To: Pierre Gauthier Cc: Craig Gallen (opennms); Flauw, Marc; Tina O Sullivan; Vai...@re...<mailto:Vai...@re...> Subject: Maven Upgrade Pierre, Maven 2.2.1 need to be upgraded to 3.0.x to work with Ubuntu 12.04. The current Maven code does not work with Maven 3.0.4. The version compatibility note url is attached below, which provide an insight on compatibility known issues. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Please suggest if this project can be taken up on priority. Thanks and Regds, SB |
|
From: Pierre G. <pga...@tm...> - 2013-03-08 12:43:44
|
Hi Marc, We are not migrating for 1.2 Have you done the change to the EID in the common model ? We need to finish the coding of the SOAP and DOC generators to support this feature before we can freeze the code. Also the RI/CTK code will need to be updated. Pierre On 2013-03-08, at 3:25 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Hi SB, I think we decided not to upgrade maven for JOSIF 1.2. We need to freeze 1.2 asap Best regards Marc From: SB Mahapatra [mailto:sbm...@tm...<http://tmforum.org>] Sent: Friday, March 08, 2013 7:25 AM To: Pierre Gauthier Cc: Craig Gallen (opennms); Flauw, Marc; Tina O Sullivan; Vai...@re...<mailto:Vai...@re...> Subject: Maven Upgrade Pierre, Maven 2.2.1 need to be upgraded to 3.0.x to work with Ubuntu 12.04. The current Maven code does not work with Maven 3.0.4. The version compatibility note url is attached below, which provide an insight on compatibility known issues. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Please suggest if this project can be taken up on priority. Thanks and Regds, SB |
|
From: Craig G. (opennms) <cg...@op...> - 2013-03-08 09:19:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SB, I'm sorry, I don't understand your statement. Maven is platform independent as it is entirely Java based. If you install 2.2.1 according to the Maven web site http://maven.apache.org/download.cgi#Installation (rather than packaged distributions) there should be absolutely no constraints on use with ubuntu. In addition there are instructions and a package for installing 2.2.1 using the ubuntu-12.04 packager here; http://pkgs.org/ubuntu-12.04/ubuntu-universe-i386/maven2_2.2.1-10_all.deb.html So what is the problem :) Craig On 08/03/2013 08:25, Flauw, Marc wrote: -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJROa0CAAoJEATefL4tbU2QE9oH/j3eo+pHg5TpHAvJLpXMdReL 3tXu5RjZsWaspWuhhEkKFgJGqTvcGqZLC6vNrdMWhKW0UGjl8kaRbwhNt3ibXxOm eqKdVFd+qUh8SwwttcpQA87aZjXb6kqYJzU/Wg3bvposq0iSIurfzkNZ0EoHGbSk jHfS0O4dGcCgu5ip2rE66t2OgYmKthm0RmedLmtYtMaaBK7DheS04XZ0AtLMHroI unMJ+8PAUBjkL6MiPLTjhdi5y0O1UcO+PuKcPBAaooS2ispVkXGSnN985j2/Uwyc 5GW1dpBdfvD9Svc8xsK4oLpxArDSsLQTBrxtxn5Cc9WvhMkbapAajsfhjZ2Qk8I= =seuv -----END PGP SIGNATURE----- |
|
From: Flauw, M. <Mar...@hp...> - 2013-03-08 08:26:22
|
Hi SB, I think we decided not to upgrade maven for JOSIF 1.2. We need to freeze 1.2 asap Best regards Marc From: SB Mahapatra [mailto:sbm...@tm...] Sent: Friday, March 08, 2013 7:25 AM To: Pierre Gauthier Cc: Craig Gallen (opennms); Flauw, Marc; Tina O Sullivan; Vai...@re... Subject: Maven Upgrade Pierre, Maven 2.2.1 need to be upgraded to 3.0.x to work with Ubuntu 12.04. The current Maven code does not work with Maven 3.0.4. The version compatibility note url is attached below, which provide an insight on compatibility known issues. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Please suggest if this project can be taken up on priority. Thanks and Regds, SB |
|
From: Craig G. (opennms) <cg...@op...> - 2013-03-07 10:04:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, They didn't mention what version of subversion they are updating from. If they are moving from 1.6.x to 1.7.x then users will be required to run a new command, svn upgrade to update the metadata to the new format.This command may take a while, and for some users, it may be more practical to simply checkout a new working copy. However if it is a 1.7.x upgrade, we should have few problems. See http://subversion.apache.org/docs/release-notes/1.7.html I have been using the pure java SVNKit 1.7.5 connector within Eclipse. SVNKit is a pure Java Subversion implementation and supports 1.6 and 1.7 working copy formats. I don't expect any problems. Subversion clients are usually backwards compatible with older repository formats. Sourceforge uses Subversion 1.6.x (http://sourceforge.net/apps/trac/sourceforge/wiki/Subversion) Hope this helps Craig On 06/03/2013 07:37, Flauw, Marc wrote: > Dear all, > > How would that affect us? > Are we running this version of SVN on JOSIF? > If not, we would need to upgrade for JOSIF 1.2 as this would be needed to access the TM Forum SVN. > > Best regards > > Marc > > From: Christopher Hartley (chrhartl) [mailto:chr...@ci...] > Sent: Wednesday, March 06, 2013 6:36 AM > To: nd...@ci...; Flauw, Marc > Subject: FW: [Information Framework (SID)] Upgrade to Collaboration Online Community Project Workspace Component [#174851] > > Nigel, Marc, > > “This new version of the TeamForge environment requires a Subversion (SVN) client of 1.7.2 or later” > > This will require an update of Subversive from the version shown here http://www.tmforum.org/community/groups/information_framework_sid/wiki/installing-rsa-for-sid-use.aspx > > I have been unable to upgrade to the new subversive http://www.eclipse.org/subversive/latest-releases.php > > because I can’t work out how to remove the old version. > > > regards, Chris Hartley > Technical Leader > NMTG - XMP Model & Model Infrastructure-AU > Time zone : GMT +9:30 > ph: +61 8 8124 2211 > Internal VOIP nr : 8 618 2211 > > From: Information Framework (SID) [mailto:si...@co...] On Behalf Of Kenneth Lipnickey > Sent: Tuesday, 5 March 2013 9:12 AM > To: Christopher Hartley (chrhartl) > Subject: [Information Framework (SID)] Upgrade to Collaboration Online Community Project Workspace Component [#174851] > > This is a TM Forum Community Announcement. Please do not reply to this message. > > Kenneth Lipnickey , Director, Collaboration Project Management , TM Forum > > > Dear Collaboration Program Participant, > > > > The Project Workspace component of the Collaboration Online Community will undergo a major version upgrade beginning this Saturday March 9th at approximately 1800 GMT. The Project Workspace (PWS) contains functionality for the following items: > > - Downloads (from the Community Downloads menu item) > > - Change Requests (from the Community Change Requests menu item) > > - Contributions (from the Community Contributions menu item) > > - All the items found under the Project Workspace menu item, most notably Documents and Source Code > > > > All of these items will be inaccessible during this upgrade. Other items such as discussion posts, wikis and calendaring will be available. > > > > Although we don’t anticipate the upgrade taking the entire time, we are allocating a full day for this upgrade meaning the Project Workspace and associated fucntionality will be unavailable until Sunday at approximately 1800 GMT. > > > > Important: This new version of the TeamForge environment requires a Subversion (SVN) client of 1.7.2 or later. For those of you who are using a specific SVN client (TortoiseSVN, Subclipse, AnkhSVN) it will be necessary for you to ensure that the client you are using at a minimum is compatible with version 1.7.2 of the SVN client. > > > > We apologize for any inconvenience this may cause. > > > > Regards, > > TM Forum Collaboration Program > > Information Framework (SID) > Topics:General > > Shared In: All Communities > > View thread online<http://www.tmforum.org/community/groups/information_framework_sid/forum/p/174851/206842.aspx?utm_campaign=community&utm_medium=information_framework_sid&utm_source=alert#206842?utm_campaign=community&utm_medium=Information%20Framework%20(SID)&utm_source=alert> > > > > > Full thread available online here: http://www.tmforum.org/community/groups/information_framework_sid/forum/p/174851/206842.aspx?utm_campaign=community&utm_medium=information_framework_sid&utm_source=alert#206842<http://www.tmforum.org/community/groups/information_framework_sid/forum/p/174851/206842.aspx?utm_campaign=community&utm_medium=information_framework_sid&utm_source=alert#206842?utm_campaign=community&utm_medium=Information%20Framework%20(SID)&utm_source=alert> > > > This message was sent to chr...@ci...<mailto:chr...@ci...> and follows the subscription preferences of your membership of the Information Framework (SID) TM Forum Online Community. > > To unsubscribe immediately, please click here<http://www.tmforum.org/browse.aspx?type=3&action=9> and click "Edit Collaboration Community Notifications". You will be prompted to log in if you are not logged in already. To cut down on email volume, you may also choose to receive your discussion notifications via a daily or weekly digest email as opposed to immediate separate emails. > > TM Forum, 240 Headquarters Plaza, East Tower, 10th Floor, Morristown, NJ 07960-6628, USA. Call +1 973 944 5100. in...@tm...<mailto:in...@tm...> > > [Image removed by sender.] > > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > > > > _______________________________________________ > Openoss-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-discuss > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJROGYlAAoJEATefL4tbU2QsnwH/inVtPl2o4BEE3q9OZPhIcr5 XlSX9wx+yjcrjpS9SdGKEvdemiDIJ1zyVshd/Ab92iMKNixowoi1twh6GmEUE7b8 DDSI5Q2Sj8KQ2myHI7QK08/Q5W+m9BmOGyArd6Cz+g5CjoaYoOopNqhIKvb6O7Mc V7hD3hj/Gehsazmny2MqWx3cCxF8hl90Qym5+4BPFjlVMHZlNdiumiW66uPts9fW kMbYU3vaIH7aYzgJQvko4YWjfv904PLU7TWBufu2zb2N2DcFK8uBi4M8ar6bMNAc 6k/bY32ixknEQUrgJKgOk7/ifYU3feLfWO8XD7Tgx5hHehaFWYK9G2WzxrbNjdQ= =iDTD -----END PGP SIGNATURE----- |
|
From: Craig G. (opennms) <cg...@op...> - 2013-03-05 08:36:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suspect that these changes will be reasonably straight forward for the RI/TCK. I can make any changes needed. However I am waiting for a stable soap generator in trunk before trying anyting cheers Craig On 01/03/2013 15:29, Pierre Gauthier wrote: > Hi, > > This will make our interfaces non backward compatible. > > But I agree with the proposed changes. > > Who will make the RI /CTK changes and when ? > > Pierre > > > On Feb 28, 2013, at 9:34 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: > > Dear all, > > We had a discussion yesterday in SII meeting on EntityBase. > > Craig?s view is that changing the name of the attributes would result in a lot of work in the RI/CTK and it would be simpler to pick the existing structure and attribute names but change the datatype. > > So the proposal is the following > > EntityBase: > - Identifier: remove deprecated flag, keep datatype of EntityIdentifier > - aliasNames: remove deprecated falg, change datatype to NameValuePair[*] > - remove new attributes: id and aliasList > > Remove the new datatype SimpleEntityIdentifier > Remove existing datatypes NameValuePairCollection, CheckedCollection, Context and DistinguishedName > > EntityIdentifier: > - attribute dn, change it to name (or id) with datatype String > - attribute context, change datatype to String > > Please send feedbacks before next SII meeting on March 6. > > Best regards > > Marc > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________ > Openoss-discuss mailing list > Ope...@li...<mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/openoss-discuss > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > > _______________________________________________ > Openoss-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-discuss > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRNa6BAAoJEATefL4tbU2QAb4IAL1CQeuOTSg9S9vSFYoB6RuM 8/iE7ya4mLsYKBsrST9S882i/M9jv5AoI41evPT/rURQyR5KCENyTA5+GMVFCzmW cs6ovV+BOZjZtnOYVAbwLqEfm/Oeb/qvfyUVMXyIaHIuoggzqJqETHp2fy9GSDWM CXqN4Smm+RTiExWlpkUG8O1uT76HVn2hqPnIPRyyPvQIp3e1ZKirtmBgumD87nmI NKOV9LHR/i1OZTTLFwKq78iBNIW+zhNW1fRuO4z/iKgnC8Y2xilKAwww0IYz11Vb fCIEJ2jcNgbqrYRKiTY0e1rJO2HmABFpjzwvskomThWxiaUladQtuxRrOx3qMPU= =3ZNN -----END PGP SIGNATURE----- |
|
From: Pierre G. <pga...@tm...> - 2013-03-01 19:59:58
|
Hi, This will make our interfaces non backward compatible. But I agree with the proposed changes. Who will make the RI /CTK changes and when ? Pierre On Feb 28, 2013, at 9:34 AM, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> wrote: Dear all, We had a discussion yesterday in SII meeting on EntityBase. Craig’s view is that changing the name of the attributes would result in a lot of work in the RI/CTK and it would be simpler to pick the existing structure and attribute names but change the datatype. So the proposal is the following EntityBase: - Identifier: remove deprecated flag, keep datatype of EntityIdentifier - aliasNames: remove deprecated falg, change datatype to NameValuePair[*] - remove new attributes: id and aliasList Remove the new datatype SimpleEntityIdentifier Remove existing datatypes NameValuePairCollection, CheckedCollection, Context and DistinguishedName EntityIdentifier: - attribute dn, change it to name (or id) with datatype String - attribute context, change datatype to String Please send feedbacks before next SII meeting on March 6. Best regards Marc ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________ Openoss-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Flauw, M. <Mar...@hp...> - 2013-02-28 14:53:08
|
Dear all, We had a discussion yesterday in SII meeting on EntityBase. Craig's view is that changing the name of the attributes would result in a lot of work in the RI/CTK and it would be simpler to pick the existing structure and attribute names but change the datatype. So the proposal is the following EntityBase: - Identifier: remove deprecated flag, keep datatype of EntityIdentifier - aliasNames: remove deprecated falg, change datatype to NameValuePair[*] - remove new attributes: id and aliasList Remove the new datatype SimpleEntityIdentifier Remove existing datatypes NameValuePairCollection, CheckedCollection, Context and DistinguishedName EntityIdentifier: - attribute dn, change it to name (or id) with datatype String - attribute context, change datatype to String Please send feedbacks before next SII meeting on March 6. Best regards Marc |
|
From: Craig G. (opennms) <cg...@op...> - 2013-02-18 09:13:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This proposal seems eminently sensible Craig On 13/02/2013 14:54, Flauw, Marc wrote: > Dear all, As discussed, here is a proposal for simplifying the JIRA > projects Keep TIP_Framework as base project for JOSIF: general > issues, SID Import, SOAP, Doc, Rest generators. Keep TIP_Platform > for all implementation related issues: implementation generators, > RI/ CTK general features. Keep TIP_TestProjects for all Test > projects issues Proposed merges: > > - Common Model in TIP_Framework > > - Expedited Interfaces in TIP_Framework > > - Openoss_admin in TIP_Framework > > - Persistency in TIP_Platform > > - Regression Testing in TIP_TestProjects > > - RESTful in > TIP_Framework > > - SID xsd Generation in TIP_Framework > > - Tooling support in TIP_Framework > > - Unix version of tooling in TIP_Framework The interface > specific projects could stay separate: Customer Management API, > Inventory, PM, RAM, SPM, but they should only contain issues and > stories related to the functional part of the interface and not to > JOSIF. Best regards Marc > > > > > ------------------------------------------------------------------------------ > > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 and get > the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > > > > _______________________________________________ Openoss-discuss > mailing list Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-discuss > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRIfCfAAoJEATefL4tbU2QJw0H/igDIKbFyyGR38GQT8SRNMXe CwOian8EVqfncnvd0c8rlRSi4/HMBDWn5g7njzlalS7obsfU8QCt+Frk5EaTSp/8 alTQdOzHeCDYcG1Z51PCccUnCsicM0KJUU1BAqywBgdSKQ6zbldLlvWmOmR5yYy8 VZans2HBKJaLsOQVv37vrZLR3K169DqIgZ/jyJa3SVoah2reu3T7yapEYbcJQVuM grI3GVG8n/VUuZ8NTk0/JVuLn5SEpMpTxnBL8zy3LV8HRiP+GKMN0IyxXDoD+18E ZCLYFhfS2r0hhh9gm7kcYKywrhzLBehz3E2WZu255s4i0wu+kuvQLcvUFTWICH0= =/TtV -----END PGP SIGNATURE----- |
|
From: Flauw, M. <Mar...@hp...> - 2013-02-13 14:55:12
|
Dear all, As discussed, here is a proposal for simplifying the JIRA projects Keep TIP_Framework as base project for JOSIF: general issues, SID Import, SOAP, Doc, Rest generators. Keep TIP_Platform for all implementation related issues: implementation generators, RI/ CTK general features. Keep TIP_TestProjects for all Test projects issues Proposed merges: - Common Model in TIP_Framework - Expedited Interfaces in TIP_Framework - Openoss_admin in TIP_Framework - Persistency in TIP_Platform - Regression Testing in TIP_TestProjects - RESTful in TIP_Framework - SID xsd Generation in TIP_Framework - Tooling support in TIP_Framework - Unix version of tooling in TIP_Framework The interface specific projects could stay separate: Customer Management API, Inventory, PM, RAM, SPM, but they should only contain issues and stories related to the functional part of the interface and not to JOSIF. Best regards Marc |
|
From: Flauw, M. <Mar...@hp...> - 2012-12-17 08:04:57
|
Dear all, I have updated to V1.2 TIP Profile, Common Model and Internal Generator Model. I checked this model using RAM. You will need to change in the TIP_SOAP_Generator settings (part of tigerstripe.xml) the variable COMMON_MODEL_VER to 1.2. I have also aligned the Common Model to lastest SID 12.5. The 2 changes are in NRB: new ResourceFulfillmentState enum and change to the State enum to remove duplicates. Best regards Marc |
|
From: Flauw, M. <Mar...@hp...> - 2012-12-12 15:56:53
|
Dear all, For the Common and Internal Models, most of it is using 1.2.0 tags and pom version, but the Tigerstripe version is still 1.1. I am planning to upgrade to 1.2 before doing updates to the Common Model to reflect changes in SID 12.5 Best regards Marc |
|
From: Flauw, M. <Mar...@hp...> - 2012-12-12 08:16:29
|
Dear all, Trying to create a new environment for PM Thresholding with the new project creator 1.2.0, I had some troubles, one of them due to the fact it was expecting a common model 1.2. So this raises the question of when do we want to switch all our generators and models (common + internal) to 1.2? Is it something we can discuss in the call today? Thanks Marc |
|
From: Flauw, M. <Mar...@hp...> - 2012-09-24 13:37:14
|
Dear all, Short notes of our meeting: - Presents: Bill Semper, Craig Gallen, SB, Xose Ramon Sousa Xose is still investigating the association bug that might be in the generator code or in the Tigerstripe API. Marc created bug #522 for it. Kumar has prepared a version of the workbench installer that he will make available for testing. Best regards Marc |
|
From: Flauw, M. <Mar...@hp...> - 2012-08-29 06:46:57
|
Dear all, The draft Release Notes for JOSIF Rel 1.1.2 are available at the following location: https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Framework_BaseProject/trunk/TIP_Framework_BaseProject/src/main/resources Please check if all the new features are present. I considered tipDataTransfer as not complete for 1.1.2 as not all generators support it. Also should we now consider the implementation generators as officially supported? They were not in rel 1.1.1 Last point, I think it will be good to ship the Common Model IA in the Installer and to reference it in the kit. The file is too big to attach to this mail. Best regards Marc |
|
From: Pierre g. <pie...@os...> - 2012-07-20 12:29:48
|
Ok Thanks We already designed a solution to support this. Do we need that for 12.5 ? Pierre Envoyé de mon iPhone Le 2012-07-20 à 6:28, "Flauw, Marc" <Mar...@hp...> a écrit : > Pierre, > > > > This is one of the NGCOR requirements that I attach below. If you think our current solution addresses it, then I would change to compliant: > > > > REQ-GEN (1) Compatible > > > > It must be possible to implement a new version of an interface specification at one of the communication partners while the other communication partners still use an old version of the interface specification. This “mixed versions” of interface implementations can be used without any impact on the communication partners or the interface implementations of the communication partners. The standard interface specification must enable this capability. > > · The implementation of the new interface version at one of the communication partners must ensure the compatibility with the former version of the interface specification. > > · This will allow to implement new interface versions in a productive environment without the cost and effort to upgrade all other communication partners (a real business need might lead to the upgrade sooner or later, but this can be decided by the owner of the “old” communication partner itself. Immediate upgrades are often difficult or simply impossible). > > · (See also TMForum TR 146 Lifecycle Compatibility Release 1-0[1] chapter 3.2.2 : consideration of the approach to the requirements in TR146 chapter 3.2.2 may help to refine and better understand this requirement ) > > > > Priority: Essential > > > > I was not sure we had the right versioning support today, like at namespace level based on the version. > > > > Best regards > > > > Marc > > > > From: Pierre Gauthier [mailto:pga...@tm...] > Sent: Thursday, July 19, 2012 11:56 PM > To: OpenOSS discussion > Cc: OpenOSS discussion (ope...@li...) > Subject: Re: [Openoss-discuss] Updates to tipProfile > > > > Hi Marc, > > > > Thanks for this. > > > > You mentioned something abiut the need to support versioning today can you elaborate ? > > Pierre > > > Le 2012-07-19 à 16:42, "Flauw, Marc" <Mar...@hp...> a écrit : > > Dear all, > > > > As discussed during the SII meetings today, I have updated the tipProfile with 2 new stereotypes: > > - tipDataTransfer for File Transfer support > > - tipGenericQuery for the generic polymorphic query pattern. > > > > Pierre, the descriptions are not filled as agreed. > > > > 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-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-discuss > > ------------------------------------------------------------------------------ > 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-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openoss-discuss |
|
From: Flauw, M. <Mar...@hp...> - 2012-07-20 10:29:45
|
Pierre, This is one of the NGCOR requirements that I attach below. If you think our current solution addresses it, then I would change to compliant: REQ-GEN (1) Compatible It must be possible to implement a new version of an interface specification at one of the communication partners while the other communication partners still use an old version of the interface specification. This "mixed versions" of interface implementations can be used without any impact on the communication partners or the interface implementations of the communication partners. The standard interface specification must enable this capability. · The implementation of the new interface version at one of the communication partners must ensure the compatibility with the former version of the interface specification. · This will allow to implement new interface versions in a productive environment without the cost and effort to upgrade all other communication partners (a real business need might lead to the upgrade sooner or later, but this can be decided by the owner of the "old" communication partner itself. Immediate upgrades are often difficult or simply impossible). · (See also TMForum TR 146 Lifecycle Compatibility Release 1-0[1] chapter 3.2.2 : consideration of the approach to the requirements in TR146 chapter 3.2.2 may help to refine and better understand this requirement ) Priority: Essential I was not sure we had the right versioning support today, like at namespace level based on the version. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Thursday, July 19, 2012 11:56 PM To: OpenOSS discussion Cc: OpenOSS discussion (ope...@li...) Subject: Re: [Openoss-discuss] Updates to tipProfile Hi Marc, Thanks for this. You mentioned something abiut the need to support versioning today can you elaborate ? Pierre Le 2012-07-19 à 16:42, "Flauw, Marc" <Mar...@hp...<mailto:Mar...@hp...>> a écrit : Dear all, As discussed during the SII meetings today, I have updated the tipProfile with 2 new stereotypes: - tipDataTransfer for File Transfer support - tipGenericQuery for the generic polymorphic query pattern. Pierre, the descriptions are not filled as agreed. 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-discuss mailing list Ope...@li...<mailto:Ope...@li...> https://lists.sourceforge.net/lists/listinfo/openoss-discuss |